Andrej Karpathy coined the term in February 2025, and the developer internet lost its mind.
The pitch: let the AI write the code, accept its changes without reading them, and just describe what you want. Karpathy called it “a new kind of coding where you fully give in to the vibes.”
That framing has been quoted tens of thousands of times approvingly. It has been turned into courses, YouTube channels, and a minor genre of newsletter content.
It has been positioned as the future of software development.
The enthusiasm is understandable. The conclusion is wrong.
The Mainstream View (And Why It Falls Short)
The mainstream case for vibe coding is that it removes friction from software creation, letting more people build more software faster, regardless of technical background. The problem is that it conflates creation with maintenance, and the latter is where software actually lives.
Karpathy’s position, and that of most vibe coding advocates, is essentially democratisation: if AI can write the code, anyone can build software.
Simon Willison, who has written thoughtfully about AI-assisted development, argues that vibe coding tools let developers prototype faster than ever and that the output is often good enough to ship.
Both arguments are correct about creation. Neither addresses what happens six months after you ship.
The missing piece in the vibe coding argument is that software is not a one-time act. It is an ongoing responsibility. The code you ship is code you maintain, debug, extend, and hand to other people.
When you vibe code and accept changes without reading them, you are creating a codebase you cannot reason about. That is not a workflow. It is a liability.
What the Numbers Show
The evidence against vibe coding as a general methodology is not philosophical. It is structural. Software maintenance accounts for 60-80% of total lifecycle cost according to IEEE Software research on software evolution. Vibe coding optimises the wrong end of that equation by design.
Here is the concrete version of this. A developer uses a vibe coding workflow to build a user authentication system. The AI writes the code, the tests pass, it ships. Six months later, a security researcher finds a vulnerability.
The developer opens the file and sees 400 lines of code they have never meaningfully read.
This is not hypothetical. It is the pattern that emerges from any process that optimises for creation speed at the expense of comprehension.
The code works until it does not, and when it does not, the person responsible for fixing it does not understand it.
The framing of vibe coding as a skill you can learn and apply broadly, rather than a process you choose for specific contexts, is where the real damage happens.
Developers who adopt vibe coding as an identity, rather than as a tool for appropriate use cases, are trading long-term capability for short-term output.
What I have noticed watching this play out in developer communities: the same people most enthusiastic about vibe coding are often the least experienced with maintaining complex systems.
The enthusiasm is coming from the people who have not yet encountered the specific kind of technical debt that vibe coding creates.
The Part Nobody Wants to Admit
The part nobody wants to admit is that vibe coding is optimised for demos and prototypes, not production systems. The developer community has convinced itself otherwise because the prototype works and the future maintenance cost is invisible at shipping time.
Prototyping speed is real. If you need a proof-of-concept in 48 hours, vibe coding can genuinely compress that timeline. That is a legitimate use case.
The problem is that prototypes get promoted to production. Demos become features. We will clean up the code later is the most expensive sentence in software development history, and vibe coding industrialises this pattern at scale.
There is a real difference between AI-assisted development, where you understand what the AI wrote, and AI-replaced development, where you do not.
The tools that actually move development workflows forward are the ones that keep developers in the reasoning loop, not the ones that let them exit it. Vibe coding as an ideology pushes toward the latter.
The developer community’s reluctance to say this clearly comes from the fact that vibe coding demos look impressive. A non-developer building a working app in an afternoon is genuinely interesting.
What nobody films is the same non-developer trying to fix a bug in that app three months later.
Hot Take
Vibe coding will produce the worst generation of codebases in software history, and the developers who built them will not be able to fix the bugs. The 2027-2028 hiring market will be shaped by companies paying senior engineers to clean up vibe-coded systems that juniors built, shipped, and can no longer explain. The revolution will have a very expensive second act, and the people who wrote the breathless newsletter posts about vibe coding will be very quiet about it.
