The Rise of the Coffee Machine Developer

Today we are talking about how AI changes us for better and for worse. Software developers are often described as craftspeople or artisans. The craft is not always an easy one - we need to acquire context, ship fast, fix bugs and, worst of all, deal with stakeholders changing ideas by the hour.

But this craft is a beautiful one. You sometimes make a tangible difference in people's lives (and billionaires' bottom lines). This craft was, until recently, highly valued. It still is the case in many companies, but gradually we are shifting towards code becoming a commodity.

A bit like how coffee went from a luxury import in Renaissance Europe to now fueling nearly every worker in the modern world. So I ask you this question: if code is akin to coffee, you as a developer, do you think of yourself as a barista in a fancy coffee shop or are you the office automatic coffee machine?

Let me explain

I will take a detour but bear with me - we need to establish context before deciding if we are baristas or a Keurig machine.

A Senior or Staff level engineer typically will be able to handle a big variety of tasks, from simple to complicated. Generally, our careers start with simple refactoring, bug fixes, and gaining context about business domains.

As we mature into mid-level engineers, we will work on features requiring bigger changes, plan ahead for future features, and work more independently. The claim from companies like Meta is that we have reached AI systems able to now perform this level of work.

As we grow later into senior and eventually staff/principal level, we generally own vast swaths of responsibilities from CI/CD pipelines, architecture planning of entire projects, and even training engineers in good practices.

The maturing process as a developer unfolds in two distinct phases. The first phase is learning patterns - what I call "coding to specifications." This is where we build our technical foundation. You learn how forms work, how to structure database queries, how to handle state management. These are the building blocks that, with practice, become second nature. It's like learning to drive - at first, you consciously think about every gear shift and turn signal, but eventually, these actions become automatic. This is the phase where both junior engineers and AI can excel, given clear requirements.

The second phase is where things get interesting - it's about developing what I call "engineering intuition." This goes beyond knowing how to code; it's about understanding why we code things in certain ways. It's the ability to look at a feature request and immediately sense potential scalability issues, or spot hidden security concerns that weren't mentioned in the requirements. This intuition isn't just about technical knowledge - it's about understanding the ripple effects of technical decisions across an entire system. This explains why some developers, despite years of coding, remain at an intermediate level, while others reach staff/principal levels relatively quickly - they've developed this deeper understanding of systems thinking.

While I fully understand title inflation is a thing, you can feel who I'm talking about. And I'm not talking about the kind of engineer who runs the whole show for their own ego or hides behind 100% test coverage. I'm talking about the engineer who can move mountains in the codebase but will shift to a slower pace when the team needs to build solid bases.

You won't find a lot of them in your career; they gravitate towards companies with engineering missions that matter to them.

Crossroads

Now that we have established how one gradually reaches this level of mastery, let's take a step back and see what AI coding systems are good at and what they have issues with.

AI is awesome at:

AI can't yet perform:

As developers, we develop our intuition by doing exactly what AI is so good at. We move from junior to intermediate and then to senior by repeating these tasks until they solidify into a higher understanding. So now let me go back to the original question: "Are you a barista or a Keurig machine of a coder?"

I see more and more developers abdicating their own reasoning process to AI systems and it worries me. It worries me that while working at a company valued in the billions, I review code each day containing no architecture or plans from senior developers.

I rely vastly myself on AI tools like Cursor, but I use them as a barista tuning their sophisticated coffee machine. Each prompt sent to an LLM is part of a plan I write myself and analyzed by reading the codebase and experimenting first with the concept. The absence of critical thinking about AI code is a big deal.

I am an optimist by nature, but if individual developers do not keep their own intuition sharp, we are playing directly into the hands of executives happy to lay off vast chunks of their workforce and giving them a reason to.

I encourage you to take a step back the next time you pick up a ticket and reflect on what makes you human and where you are better than AI code. Next, I'll share a few actionable steps to reclaim your ownership of code and ensure you are not becoming a Keurig machine.

Becoming the Maestro

Suggestion 1: Take Days Off from AI

The first suggestion is taking full days away from your prompt box. Take 1 to 3 days a week where you take the time to write your code yourself. Read the codebase without a RAG system and plan your implementation slowly before writing it.

You will have to reflect on your code and on the decisions you are taking. The prompting and reprompting workflow leads to a disconnect from your strategy. Slowing down a few days a week keeps your intuition muscles sharp.

Suggestion 2: Work on a Personal Project and Get Users!

This one is a classic one but it's even more important. Keurig machine developers are losing value each time a better model or tool is released. The ability to really understand users, business domains, and such is what will give you critical thinking about your work.

This cannot be replicated by AI (yet?!). In big companies, you have a level of disconnect from business needs and user needs. If you do it on your own small project of even 10 users, you have to consider cost, satisfaction, velocity, and everything you did not care about when a corporate entity shields you with their customer service agents.

Caring is learning. If you care about your side project technology, you learn valuable net new skills, and if you care about your users, you will uncover issues at work an LLM could not care less about.

Suggestion 3: Read the Research and Moderate Social Media Usage

X and LinkedIn are weird places. They are driven by algorithms that trigger reactions. However, the reality of AI research and advancement is much more nuanced than posts let on. Devin the coding agent, while great, was proven to struggle with even basic tasks.

OpenAI GPT-4 slays at math but burns more energy than a Hummer from a 2002 hip-hop video. Reading the firsthand information is a great way to learn how to leverage AI yourself without giving in to the hype. This will remind you that every technological shift is accompanied by mountains of noise.

Not flocking to the newest tool each time affords you the time you need to learn and use it better without becoming a slave to the tool.

Conclusion

I don't want to scare people with this post. Instead, my goal is to encourage you to love your craft. It is changing quickly, but do not succumb to giving away what makes us different from machines. Take time to code once in a while and enjoy doing it! You will only become a better user of AI.