The rise of coffee machine devs

At the multi-billion-dollar company where I work, I review pull requests every day from senior engineers that contain no architecture and no plan. An AI coding assistant produced a working diff before their espresso cooled down, the description reads smoothly, and the happy-path checks are green. When you ask how the change behaves under load or how it fits next quarter's roadmap, nobody on the review thread has thought that far ahead.

Software development used to be treated as an artisanal craft, even when the daily reality meant gathering scattered context, shipping under tight deadlines, fixing bugs, and dealing with stakeholders who change their minds by the hour. Today code is turning into a commodity, much like coffee went from a luxury import in Renaissance Europe to basic fuel in every office kitchen. That shift puts a blunt question in front of every working programmer: when you sit down at the keyboard, are you working like a barista who understands the roast, the grind, and the extraction, or are you pressing the button on the office Keurig machine?

How engineering intuition gets built

Most programmers mature through two distinct phases. The first phase is coding to specifications. We start our careers doing small refactors, fixing isolated bugs, learning how forms work, structuring database queries, and wiring state management while absorbing a business domain. With enough repetition, those mechanics become automatic, much like shifting gears and hitting the turn signal once you know how to drive. Given clear requirements, both a junior engineer and a language model handle this phase well.

As engineers grow into mid-level roles, they take on larger features, plan ahead for upcoming requirements, and work independently. Companies like Meta already claim that AI systems have reached this level of output. Moving into senior, staff, and principal roles requires a second phase of growth: engineering intuition. At that level you own CI/CD pipelines, plan the architecture of entire projects, and train other engineers in sound practices. When you read a short feature request, you immediately sense where the design will buckle under scale or where an unstated security flaw sits between two services.

Some developers write code for a decade and stay at an intermediate level, while others reach staff or principal roles in a few years because they learned to trace how a local decision ripples across an entire system. Even accounting for title inflation, you know this kind of engineer when you work with one. They do not run the show to feed their ego or hide behind 100% test coverage. They can move mountains in a codebase when speed matters, and they will deliberately slow the team down when the foundation needs solid work. You do not meet many of them across a career, and they tend to gravitate toward companies whose engineering problems actually matter to them.

Where the training loop breaks

AI coding assistants excel at the exact tasks that used to build that intuition. They generate repetitive boilerplate, search across large repositories, go from point A to point B on a tightly specified ticket, and summon syntax patterns from the whole corpus of public code. Where they fall apart is understanding a brand-new domain outside their training data, planning an architecture that will survive next year's requirements, and stepping back to question whether a ticket should be built at all.

The catch is that junior developers become senior engineers by grinding through the repetitive work until those patterns solidify into systems thinking. When developers hand their reasoning process over to the prompt box on every ticket, they cut out the struggle that builds judgment.

I use Cursor heavily every day, and I have no desire to type boilerplate by hand. The difference is that every prompt I send comes from a plan I wrote myself after reading the codebase and testing the concept on a small slice. Stepping back from the prompt box to think critically about generated code is what keeps you in the driver's seat. If engineers stop exercising that judgment, we hand executives the exact justification they want to treat engineering teams as interchangeable and lay off huge chunks of their workforce.

Three habits to keep your intuition sharp

Take full days off from AI

Take one to three days a week where you write code without opening a prompt box or querying a RAG system. Read the repository files directly, trace the execution path in your head, and write out your implementation plan slowly before touching the code. The prompt-and-reprompt loop nudges you into guessing until the compiler stops complaining; slowing down a few days each week forces you to own every line you ship.

Build a personal project for ten real users

Button-pushing developers lose ground every time a stronger model lands. In a large company, layers of product managers and customer support agents insulate you from the cost and friction of your own code. When you run a small side project with even ten real users, you feel the hosting bill, the release velocity, and the user frustration directly. Caring about your own users and your own stack forces you to notice edge cases and domain tradeoffs that an LLM never considers, and you bring that sharper eye back to your day job.

Read the research instead of the social feed

X and LinkedIn reward outrage and cherry-picked demos, while actual AI research is far more uneven. Devin launched to viral threads claiming autonomous software engineering had arrived, and independent evaluations quickly showed it struggling on basic repository tasks. OpenAI's GPT-4 can solve hard math problems while burning more energy than a Hummer from a 2002 hip-hop video. Reading the primary evaluation papers yourself cuts through the marketing noise and gives you the breathing room to learn new tools deliberately instead of chasing every release cycle.