Vibe coding is an informal AI-assisted coding style in which I steer by natural-language intent and accept generated code with little direct inspection, useful for throwaway exploration and prototypes but risky to carry into production without the review, tests, and validators a production system needs.

How it works

In vibe coding the developer prompts the model, runs whatever comes back, and re-prompts on feel, judging the result by whether it seems to work rather than by reading and verifying it. The loop is intent, generate, glance, where a disciplined workflow would make it intent, generate, verify. Andrej Karpathy named the style in early 2025, and it is now widely recognized, though its meaning is still drifting between his original sense of accepting unreviewed output and a broader label for prompt-driven AI coding. What defines it is not that an AI wrote the code but that little of the output is inspected or checked before it is accepted, which is exactly what makes it fast.

Why it matters

Vibe coding is genuinely useful for spikes, prototypes, and learning, where speed matters and the cost of a wrong line is small because the artifact is disposable. A common failure mode is silent promotion, when code produced this way slides into a system where correctness now matters and no verification was ever added, though skill atrophy and code no one understands well enough to maintain are real costs too. The honest complication is that the line between vibe coding and disciplined, agentic development, where a human still owns the goal, the review, and the checks the work must pass, is blurring as agents grow more reliable, so it reads better as a point on a trust-and-review spectrum than as a hard category. An experienced team may even ship low-inspection code into production on purpose when the change is small, reversible, and bounded, because the assurance matched the blast radius rather than because low inspection is safe. The distinction that survives is not whether an AI wrote the code but who owns verifying it and how credible that verification is, since vibe coding leaves the step out and a production practice puts a real one back. Naming the style is useful precisely because it marks the mode you should not be in when the stakes rise.

In practice

A prototype gets built quickly by vibe coding, the developer prompting and accepting until the demo works, and then it ships more or less unchanged because it already seems to do the job. Weeks later a bug surfaces that no one would have caught, because no one read the code closely enough or wrote a check it had to pass. The failure was not that an AI wrote it but that the verification step a production system needs was never added when the prototype crossed into production. What was missing was the owned check, not a better prompt.

Practical considerations

Vibe coding fits throwaway work, spikes, and learning a new tool, where the output is not load-bearing and speed is the whole point. The danger sign is promotion without hardening, when something built on feel starts taking real traffic or real data while still carrying no tests, no review, and no validators. A workflow leaves vibe coding behind not the moment it adds one check but as a person comes to own meaningful review, tests, and checks that exercise the failure modes rather than only the happy path, since a shallow gate or one the same model wrote is a green light without assurance. Treat that shift as a decision to make on purpose rather than one that happens by drift.

Related standards and prior art

Defined by Ready Solutions AI