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 sits as 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, plausible defects ship.
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 kind of work is being done.
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 serves as 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 get skipped because the model produced the code. The gates are how the developer 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 runs as the actual limit. Not capability. Cost of error. Not safety. Judgment.
The bottom line
The patterns this piece covers have been showing up in production long enough to have names, failures, mitigations, gaps. The work security, engineering, and operations are quietly doing today is the work that decides whether vibe coding lands as a tool that ships or a liability that follows. Use the practice in the band where it works. Run a real review process everywhere else. Keep a human in the loop on every change that touches a security boundary.
Related from Human Required. For a deeper look at reviewing AI generated code in production, see AI generated Code Is Now in Your Production Stack. Here’s How to Review It..
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
