Vibe coding is legitimate in exactly one context: when you are building a prototype you intend to throw away.
The problem is that most vibe-coded systems do not get thrown away. They run. They accumulate users. They become the system that must be maintained, extended, and debugged by people who did not write it and cannot ask the AI to explain its decisions in context. The codebase does not know it was supposed to be temporary.
This is not a critique of using AI to generate code quickly. It is a description of what happens when you apply a prototype strategy to a production environment.
What Vibe Coding Actually Is
Vibe coding is generating code by describing intent, accepting what looks right, iterating until something works, without reading every line or understanding every decision. The feedback loop is: does it run, does it look right, does the feature work in the happy path. When the answer is yes, the code ships.
This approach is genuinely useful for specific purposes. A proof-of-concept for stakeholder alignment. A design spike to test whether an API is usable before committing to integration. A throwaway exploration of a framework you have never touched. Generating boilerplate that will be reviewed line by line before any of it reaches production.
In all of these cases, the artifact is a communication tool or a learning device, not a production system. The exit condition is “this is good enough to have the conversation,” not “this is ready for users.”
When vibe-coded systems enter production without that distinction being made explicitly, they carry debt that compounds. The decisions that were never made consciously become constraints the next engineer inherits. The edge cases that were never considered become the bugs that appear at 2 AM.
The Jagged Edge Problem at Scale
AI coding agents are not uniformly capable. They excel in well-trodden patterns: CRUD endpoints, UI components, data transformation, boilerplate configuration. They fail unpredictably on novel architecture decisions, cross-system state management, security edge cases, performance characteristics at scale, and domain-specific correctness.
This unevenness is the jagged edge. The agent’s confidence is uniform even when its reliability is not. It writes security-adjacent code with the same tone it uses to write a utility function. It handles a novel concurrency pattern with the same apparent certainty it brings to writing a for-loop.
Vibe coding amplifies the jagged edge at scale. A system grows in the directions the agent handles well, which are also the directions that feel smooth and fast, until it hits a boundary the agent cannot navigate. By that point, the boundary is embedded in production, surrounded by code that built on the agent’s confident but incorrect assumptions.
The jagged edge is not a reason to avoid AI coding tools. It is a reason to maintain human oversight at the specific points where agent reliability drops: security decisions, performance-critical paths, novel domain logic, cross-system state.
The Agentic Paradigm and Its Discipline
Software has been described in terms of successive programming paradigms. The first: explicit instructions written by humans for deterministic execution. The second, described by Karpathy as Software 2.0: behavior compiled into neural network weights from data and objectives, where the program is in the weights, not in human-written code.
The third, what has been called the agentic paradigm, extends this further: systems where the program is increasingly in the prompt, the context, and the tools, with a language model as runtime. The codebase is still code, but the behavior of the system is shaped by context as much as by instructions.
Vibe coding is this paradigm without discipline. The prompt replaces the specification. The LLM replaces the architect. The feeling of “it works” replaces the test suite.
Agentic engineering applies discipline to the same paradigm: explicit spec before generation, verifiable acceptance criteria, test coverage owned by humans not delegated to the agent’s judgment, observability before go-live, human review gates at architectural decision points.
The discipline does not slow the paradigm down. It is what makes the paradigm trustworthy at production scale.
What Agentic Engineering Adds
Agentic engineering is not faster vibe coding. It is the same AI-assisted code generation with the elements that vibe coding skips applied deliberately.
Scope definition: what the agent will build, what it will not build, what files it will and will not touch. This boundary prevents the sprawl that makes vibe-coded systems unmaintainable.
Assumption surfacing: the agent states its interpretation before implementing it. A thirty-second clarification before the first code block prevents a two-hour rework after.
Worktree isolation: the agent works in a branch, not on main. The diff is visible and reviewable before any human accepts it.
Test-first discipline: the acceptance test is defined before implementation begins. The test is the contract between what was requested and what was delivered.
Adversarial review before merge: a second pass, before the change reaches production, on what could go wrong. Not a bureaucratic gate. A structured search for the failure mode nobody thought of in the planning phase.
Observability from day one: logs and alerts are instrumented before the feature goes live, not added when the first bug report arrives.
Rollback plan: before deployment, there is an explicit answer to “what do we do if this fails in production?”
Teams practicing agentic engineering ship faster than vibe coders at month two, month three, and beyond. Not because agentic engineering produces more code per hour. Because it produces less rework per month.
When Vibe Coding Is the Right Tool
The legitimate uses are real and worth naming.
Design spike: you need to know if a technical approach is feasible before investing in it. Vibe-code a prototype, observe the result, throw it away or extract the learnings.
Throwaway demo: you need to show a stakeholder what a feature could look like. The demo is not the product.
Learning exploration: you are getting familiar with an API, a framework, or a domain you have not worked in. The output is knowledge, not production software.
Boilerplate scaffolding: the generated code will be reviewed line by line before any of it touches production.
The exit condition for vibe-coded code entering production is explicit: architecture review to confirm it matches system conventions, security check for injection points or exposed credentials or auth gaps, test coverage from a human-written suite that validates the behavior, observability to confirm what the code does in production is visible.
A practical heuristic: if you cannot describe to a colleague what a vibe-coded function does and why it works the way it does, it is not ready for production. The inability to explain it is not a sign that the code is too complex. It is a sign that decisions were made without being understood.
The Real Productivity Gain Is in Specification Quality
The teams that win with AI-assisted coding are not the ones who write the least code. They are the ones who write the best specifications.
AI coding tools compress the gap between specification and running code. They do not eliminate the requirement for a good specification. A well-specified task, handed to an agent operating under guardrails, produces production-ready code fast. A poorly specified task, handed to the same agent, produces confident code that needs to be rewritten.
The specification includes what the component does, what it does not do, what inputs it handles, what failure modes exist, and how success is measured. This is not documentation overhead. It is the information the agent needs to produce correct output on the first pass rather than the third.
Teams investing in specification quality get compounding returns from AI coding. Teams vibe-coding get compounding debt. Both look like productivity in month one. By month six, the difference is visible in the cycle time between requirement and production, in the size of the backlog that is actually rework, and in the confidence of the engineers who work in the codebase.
The shift in the engineer’s role is real: from typist to specifier, reviewer, and domain expert who knows when to override the agent. The engineers who make that shift are faster. The ones who treat AI coding as faster typing are working harder to stay in place.
The question is not whether to use AI to generate code. It is whether the specification exists, the tests are human-owned, and the production checklist runs before deployment.
Related: Claude Code Is Not a Copilot. It Is a Delivery System. and The Four Guardrails That Separate AI Coding from AI Shipping