Vibe Coding vs Engineers: The Difference Is Still Judgement
The real debate is not whether AI replaces engineers. It is what engineers actually do that AI still cannot, and why those skills are quietly becoming more valuable, not less.
Every few months someone publishes a confident piece arguing that engineers are obsolete, AI will write all the code, and the only useful skill left is knowing which prompts to type. Every few months someone else publishes an equally confident piece arguing that AI cannot really code at all, the whole thing is a bubble, and nothing important has changed.
Neither is right, and the framing of "vibe coders versus engineers" misses what actually differentiates the two in practice. It is not who types the code. It is who understands what the code needs to do, why, and what happens when it does not. This post sits alongside our honest take on what vibe coding actually is and what happens when vibe-coded software reaches production.
What Engineers Actually Do
A common mistake when reasoning about AI replacing engineers is to assume that engineering is primarily typing. It is not. Typing is the visible part, which is why it is the part that looks like it can be automated, but it is not where the work lives.
Engineers spend most of their time doing things that are hard to prompt for.
Reading code. Genuinely understanding what an existing system does — not just locally, but in the context of everything else it connects to — is a significant portion of the work. A model can summarise a function. It cannot tell you that the function only gets called from one place, and that place has a bug that would be exposed if you changed it.
Making trade-offs. Every decision in software is a trade-off between competing concerns: speed against clarity, flexibility against simplicity, correctness against shipping on time. The right choice depends on context a model does not have — team skills, business priorities, existing commitments, future plans. You can describe all of that in a prompt, but doing so is often more work than making the decision yourself.
Knowing what not to build. The most expensive code in any system is the code that should not have been written. Engineers with judgement recognise when a feature is solving the wrong problem, when a proposed abstraction is premature, when a refactor is picking a fight that is not worth the cost. A model asked to implement a thing will implement the thing.
Debugging by building a mental model. Finding a non-trivial bug requires forming a hypothesis about how the system behaves, testing it against evidence, and updating the model. Models can suggest plausible-sounding fixes, but the work of actually understanding what is wrong is still fundamentally a human activity, because the context needed is larger than any prompt.
What Vibe Coding Is Genuinely Good At
None of this means vibe coding is useless. Dismissing it as a fad is as wrong as the obsolescence argument.
Velocity on scoped, reversible work. If the task is small, the stakes are low, and you can easily revert if it goes wrong, vibe coding is faster than writing the code yourself. This adds up: dozens of small improvements a week that would previously have been deferred because the friction was not worth it.
Breaking through blank-page paralysis. Starting from an empty file is often the hardest part of any piece of work. A generated first draft gives you something to react to, and reacting is easier than creating.
Rapid iteration on self-contained ideas. Prototypes, sketches, proof-of-concept demos. Anywhere the value is in finding out whether something works before committing to it.
Writing the tedious and unavoidable. Test fixtures, migration scaffolds, type definitions that map one shape to another. The work that has to be done and that nobody has ever enjoyed doing.
What is striking about all of these is that they are things engineers already did — they just took longer. The impact of vibe coding on good engineers has been to compress those activities, not to replace the work underneath them.
What the Research Is Saying
The empirical picture is more nuanced than either side of the debate admits.
METR's 2025 study on the impact of AI tools on experienced open-source developers found that engineers using AI tools actually completed tasks more slowly than those without them, despite believing they were faster. The subjective experience of productivity diverged sharply from the measured reality.
Stack Overflow's annual Developer Survey has tracked rising AI adoption alongside falling trust in AI-generated code. Adoption and scepticism are growing together, which suggests engineers are using these tools while remaining critical of their output — roughly the position we would argue is correct.
The DORA State of DevOps research has reported that AI tool adoption correlates with increased software delivery throughput but also with higher rates of rework. Teams ship more, and they also break more, and the net effect depends entirely on how the tools are being used.
None of this paints a picture of AI replacing engineers. It paints a picture of AI changing the shape of what engineers do, with highly variable outcomes depending on practice.
The Frontier That Actually Matters
The interesting comparison is not vibe coders versus engineers. It is engineers who use vibe coding well versus engineers who refuse to touch it.
Both failure modes are real. The engineer who will not use AI tools under any circumstances is leaving value on the table: slower than they need to be on the work where these tools genuinely help, and increasingly out of step with teams they need to work with. The engineer who uses them indiscriminately is shipping bugs and building codebases that degrade over time, and they often cannot tell that is what is happening.
The engineer who thrives is the one who can move fluidly between modes. Pure vibe for exploration and throwaway work. Assisted writing for most day-to-day code, with critical review. Hand-written, carefully reasoned code for the parts of the system where correctness matters more than velocity. And, crucially, a reliable sense of which is which.
Judgement is harder to automate than typing, and it has always been the scarcer resource. Vibe coding has not changed that. It has just made it more obvious.
Thinking about how to structure an engineering team in this environment? Get in touch — or see our AI & Automation services for how we apply this in practice.