Vibe Coding: Speed Is Not a Reason to Skip Verification
The Term Was Never Meant to Be So Grand
In February 2025, Andrej Karpathy used “vibe coding” to describe a very particular state of mind: surrendering to the flow, barely reading the code, pasting errors back into the model, and asking for changes until the program appears to work.
The phrase was soon treated as a new programming paradigm, sometimes even as proof that code no longer matters. But Karpathy's original example was a disposable weekend project.
That qualification matters. A game that will be abandoned tonight and a change to a payment system, access-control layer, or database schema should not be built under the same engineering standard.
Generating Code and Owning the Outcome Are Different Things
AI has made code generation cheap. Work that once required searching documentation, wiring APIs together, and writing boilerplate can now take only a few rounds of conversation. People can build useful software without typing every line themselves.
But who generated the code and who is responsible for the result are separate questions.
When I accept code I have not read, I am making a trade: I gain speed by giving up some understanding, and I accept the risk of errors hidden inside. That trade is not always unreasonable. What matters is whether a failure will be easy to detect, whether it can be reversed, and who it might harm.
| Scenario | Cost of failure | Appropriate approach |
|---|---|---|
| Disposable demo or personal utility | Low; it can usually be discarded | Following the vibe may be perfectly reasonable |
| Internal team tool | Moderate; it may affect data or workflows | Inspect critical changes and add tests and a rollback path |
| User-facing production feature | High; it can damage trust and the business | Review, testing, monitoring, and clear ownership |
| Payments, permissions, security, or data migrations | Extreme; failures may be hard to undo | Do not accept blindly; understand and verify the change |
Vibe coding is not an identity that is either right or wrong. It is a risk posture.
Does AI Actually Make Developers Faster?
The available evidence does not give us one answer that applies to everyone.
In a controlled GitHub study, 202 developers were asked to complete an API endpoint task. Participants using Copilot performed better on some measures of functionality, readability, and code quality. The result suggests that AI can help with bounded tasks, but it was vendor research and covered only one kind of work.
METR ran a different randomized controlled trial with 16 experienced developers working on real tasks in large open-source repositories they already knew well. With early-2025 AI tools, the participants took 19% longer on average—even though they believed the tools had made them faster.
The findings are not necessarily contradictory. A small unfamiliar task and a familiar mature codebase impose different costs, as do novice and expert workflows, code generation and context reconstruction. Turning either number into “AI always improves productivity” or “AI only slows people down” goes beyond the evidence.
AI's value depends on the task and on how much work it takes to verify the result.
How I Use AI for Programming Now
I ask less often whether I wrote the code myself. I ask what evidence I have that it works.
A simple process is enough:
- State the goal, the boundaries, and the behavior that must not change.
- Ask the AI for small, reviewable changes.
- Read the diff instead of checking only whether the final page opens.
- Use type checks, tests, static analysis, and security scanning to verify critical assumptions.
- For high-risk changes, know how to roll back a failure.
None of this eliminates mistakes; hand-written code cannot promise that either. What it does is replace “it feels like it works” with evidence that can be checked again.
AI programming tools are moving in the same direction, automatically running tests, static analysis, and security checks after generating code. Mature AI-assisted engineering is not about forcing people to inspect every character forever. It is about automating generation and verification together.
Closing Thoughts
The appeal of vibe coding is that it brings an idea closer to a working object than ever before. Someone with little programming experience can build something interactive in a few hours. That freedom is worth protecting.
But not all software can be shipped under the standards of a weekend experiment. A prototype exists to test an idea; a production system exists to keep a promise. The first may let us ignore why the code works. The second will eventually require someone to answer that question.
More and more code may be generated by AI. Engineering responsibility does not disappear with it.
Speed should come from removing low-value manual work, not from skipping necessary verification.