Vibe coding
Last verified: June 2026· definition
The term, coined by Andrej Karpathy in early 2025, describes a way of working where you describe what you want, let the model write it, and iterate on the result by feel rather than by reading every line. Tools like Lovable, Bolt, v0, and Replit Agent made it accessible to people who never wrote code professionally.
It is genuinely useful for prototypes, internal tools, and proving an idea in a weekend. The trouble starts when a vibe-coded prototype meets production: no one on the team can explain the auth model, the database has no row-level security, secrets are in the client bundle, there are no tests, and the cost of a bad change is suddenly real.
Vibe coding is not the opposite of engineering — it is a fast first draft. The work of turning that draft into something a business can depend on (auth, data boundaries, tests, evals, observability, cost control) is a separate, well-understood discipline.
What it is good for, honestly
Vibe coding is genuinely effective for exploration: proving an idea works, building something disposable, prototyping an interface to react to, or getting a first version of a script whose failure costs nothing. In those settings not reading the code is a reasonable trade, because the artefact is not going to be maintained and correctness is judged by whether it does the thing. The problems begin when something built under those assumptions acquires users.
The gap is the system, not the code
When a prototype needs to become a product, the instinct is to rewrite the generated code. That is usually the wrong call and the expensive one. What is actually missing is everything the demo never needed: real authentication and roles, database-level access control, migrations, backups with a tested restore, rate limits, idempotency on writes, observability, environment separation, and a security review. The code is frequently serviceable; the surrounding system does not exist.
Unreviewed code becomes unowned code
The durable cost is not defects but comprehension. Software nobody has read is software nobody can confidently change, and that becomes acute at exactly the wrong moment — during an incident, or when a subtle behaviour change is needed. This is why the practice scales poorly with team size and time: the person who prompted it moves on, and what remains is a codebase with no author.
The distinction that matters
Vibe coding is defined by not reviewing the output, not by using AI to write code. Using an agent to produce code you then read, test, and understand is ordinary AI-assisted development and carries none of the same problems. Conflating the two makes the conversation unnecessarily polarised — the question is never whether AI wrote it, but whether anyone has read it.
Common misconceptions
MythVibe coding means using AI to write code.
RealityIt specifically means accepting output without closely reviewing it. AI-assisted development where the code is read, tested, and understood is a different practice with a different risk profile.
MythVibe-coded prototypes need rewriting for production.
RealityUsually not. The generated code is often serviceable; what is missing is auth, access control, migrations, observability, and security work that no prototype includes.
MythIt is always a bad idea.
RealityFor throwaway exploration and prototypes it is an efficient trade. The failure is not the practice but carrying its assumptions into something that acquires real users.
Frequently asked questions
Is vibe coding bad practice?
It depends entirely on what happens to the result. For exploration, prototypes, and disposable scripts it is an efficient way to work, and reading every line would be wasted effort. It becomes a problem when the output acquires users, because you then have software in production that nobody has read and therefore nobody can confidently change or debug. The practice is fine; inheriting its assumptions is not.
How do I take a vibe-coded prototype to production?
Start with data access control, since permissive database rules are the most common serious flaw and the one with the worst consequences. Then secrets handling, real authentication and roles, migrations and backups, rate limits and idempotency, observability, and environment separation. Resist rewriting the generated code as an opening move — assess first, because in most cases the code is adequate and the surrounding system is what is absent.
How is this different from ordinary AI-assisted development?
Review. In AI-assisted development the engineer reads what was produced, understands it, and takes responsibility for it, so the usual quality controls still apply. Vibe coding skips that step deliberately in exchange for speed. The distinction is not about how the code was generated but about whether anyone can answer questions about it afterwards.