In February 2025, Andrej Karpathy posted a short tweet that named something a lot of people were already doing. He called it vibe coding. The post was about a weekend project, a voice memo tool, where he stopped reading the code the model was producing and started accepting it on vibe. “I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works.”
Two years later, vibe coding is a real category of work. It has a defensible use case, a marketing-driven overreach, and a toolchain that changes every few months. Here is what is actually true and what is hype.
What vibe coding actually is
Vibe coding is software development where the human contributes intent and judgment, the model contributes code, and the human accepts most of what the model produces without line-by-line review. The defining characteristic is acceptance without review, not use of AI.
Most engineers use AI assistance now. Copilot-style autocomplete, Cursor-style code generation, Claude-style whole-file edits. That is not vibe coding. Vibe coding is when you stop reading the diff.
The pattern works in a narrow band of conditions. The code is throwaway. The user is the only person who sees it. The failure mode is acceptable. The system has no security boundary, no shared state, and no real users. A weekend project. An internal demo. A sketch for a meeting tomorrow. A personal portfolio piece. In that band, vibe coding is fast, fun, and honestly one of the best productivity tools of the last decade.
Where it stops working
The moment the code has to be correct, secure, or maintained by someone other than the author, vibe coding breaks. The reasons are not subtle.
Models are confidently wrong in ways that are not visible at the call site. A type annotation that compiles, an authentication check that looks right but is bypassed, a database query that runs without parameterization. The code reads as plausible. The defects are silent. Without review, you ship plausible defects.
There is also a compounding problem. Each unvibed feature is technically correct in isolation. The interactions between unvibed features are not. A 2,000-line codebase that is “mostly right” is harder to debug than a 200-line codebase that is reviewed. The complexity tax is real, and the model does not pay it for you.
This is not a problem AI will solve next year. It is a property of how the models work. They generate the most likely next token. They do not generate the most correct next token. Sometimes those are the same thing. Often they are not.
The numbers
What does the data say about productivity? Less than the marketing.
The most-cited study is a controlled experiment by METR in 2024, which found experienced developers using AI were actually slower, by about 20 percent, on the specific task they were given. The sample was small (16 developers) and the task was a specific class of bug-fix in a large open-source repo. The result is real but not generalizable.
GitHub’s own data, and the more recent data from Cursor, suggests a 30 to 55 percent speedup on greenfield work, and a much smaller or zero speedup on existing codebases. The shape of the gain is real, but the size depends entirely on what you are doing.
Stack Overflow’s 2024 developer survey put AI tool usage at 76 percent of professional developers. The same survey found that “trust in AI tools” was the most-cited problem. The two numbers are not contradictory. Developers use the tools. They do not fully trust the output.
What good teams do
The pattern that actually works in production is not vibe coding. It is assisted coding with strict review. The human writes the design, the tests, and the failure-mode analysis. The model writes the boilerplate, the documentation, and the first draft of the routine code. The human reviews what matters and accepts the rest consciously.
Three practices show up in every team I have seen do this well.
Tests first, code second. Write the test for what the code should do. Let the model write the code. The test is the contract. The human owns the contract, not the implementation.
Small, reviewable changes. The model produces a 200-line diff, not a 2,000-line diff. The human reviews the 200 lines. The next change is also 200 lines. This sounds slow. It is faster than debugging the 2,000-line change later.
Real production gates. Type checking, lint, tests, security scanning, code review. None of these are skipped because the model produced the code. The gates are how the team catches what the model got wrong. If a gate is bypassable, it is not a gate.
The honest assessment
Vibe coding is a tool. It is a great tool for the work it is good at, which is throwaway software, sketches, and personal projects. It is a bad tool for the work it is being marketed for, which is production systems and team software.
The next time someone tells you AI can replace a junior developer, ask them what they think the junior developer was for. The answer is usually the same: to learn how the system works by writing the boring parts. The model can write the boring parts faster. It cannot learn from writing them.
That is the actual limit. Not capability. Cost of error. Not safety. Judgment.