Engineering practice
Vibe coding finds the shape. Agentic coding earns the merge.
The important difference is not how much code AI writes. It is whether the work is guided by taste alone or by an explicit contract, real tools, and evidence.
Vibe coding and agentic coding can use the same model, the same editor, and even the same prompt. What separates them is the feedback loop around the model—and the standard used to stop.
In a vibe-coding session, I describe an intention, look at the result, and keep steering until the software feels close to the idea in my head. That is a productive way to discover a design. It is also a weak way to decide whether a change is safe to merge, because “looks right” says very little about behavior outside the happy path.
Agentic coding changes the contract. The model can inspect the repository, choose and call tools, modify files, observe test or browser output, and revise its work. The human still defines the outcome and the risk boundary. The agent gets more freedom over execution, but less freedom to declare success without proof.
The same intelligence, under different contracts
“Vibe coding” began as a deliberately playful description of building small software by talking to a model, running what it produced, and reacting to what appeared. The phrase comes from Andrej Karpathy’s original post. Its appeal is real: natural language keeps the loop fast, and the cost of trying another direction can become very low.
“Agentic coding” is a wider and more operational idea. Anthropic’s guide to building effective agents distinguishes an agent from a fixed workflow by whether the model can dynamically direct its own process and tool use. OpenAI describes the same core mechanism in its explanation of the Codex agent loop: the model requests a tool action, receives the result, and uses that new evidence in the next inference. The generated code is only one intermediate artifact in that loop.
Vibe coding asks, “Does this feel like the thing?” Agentic coding asks, “Can we show that this change satisfies the contract?”
These are working definitions, not a universal industry taxonomy. I find them useful because they locate the difference in process rather than in branding. An autocomplete tool can support disciplined engineering. A sophisticated coding agent can still be used as a slot machine if the goal, context, and verification are vague.
- 01Input
Vibe coding starts with an intention. Agentic coding starts with an outcome, constraints, and acceptance criteria.
- 02Context
Vibe coding leans on the conversation. Agentic coding also reads the repository, architecture, conventions, and current state.
- 03Feedback
Vibe coding uses human reaction. Agentic coding adds executable signals from tests, builds, browsers, linters, logs, and diffs.
- 04Stopping rule
Vibe coding stops when the result feels useful. Agentic coding stops when named checks pass and remaining uncertainty is visible.
Vibe coding is a discovery mode
The strongest case for vibe coding appears when the central question is still “What should this be?” A rough interface can expose a broken product assumption faster than a long specification. A disposable script can reveal whether an API contains the data needed for an idea. A generated interaction can help a team compare two directions while both are still cheap to abandon.
In this mode, speed is not a shortcut around engineering; it is a way to buy information. The output is not just code. It is a clearer understanding of the desired behavior, the awkward edge cases, and the parts of the experience that actually matter. A good exploratory session should leave behind a better specification even if none of its code survives.
The prototype cliff
A prototype quietly changes category when someone depends on it. Authentication, private data, money, irreversible actions, shared interfaces, and operational ownership all raise the cost of being wrong. At that point, taste is still useful—but it is no longer an adequate acceptance test.
The mistake is not vibe coding. The mistake is allowing discovery-mode evidence to authorize production-mode responsibility. A demo that survived five clicks has not established what happens on the sixth, under concurrency, after a dependency failure, or during recovery.
Agentic coding is a delivery loop
An effective coding agent does more than return a larger answer. It operates inside a prepared environment: repository access, project instructions, appropriate tools, bounded permissions, and commands that can judge the result. The loop matters because each observation can change the next action.
The agent might discover that the requested component already exists, that a route is statically generated, or that the apparent bug is a failing contract upstream. It can adjust before editing more code. After the change, it can run the relevant checks, inspect failures, revise, and report what remains uncertain. That is qualitatively different from generating a code block and asking the human to become the execution harness.
- 01Explicit objective
Describe the user-visible outcome and the invariants that must remain true.
- 02Bounded context
Give the agent the repository rules, architecture, relevant source, and only the external access the task needs.
- 03Useful tools
Let it inspect, edit, execute, and observe instead of forcing every action through prose.
- 04Executable feedback
Tests, type checks, builds, screenshots, and focused diagnostics convert opinions into signals the loop can use.
- 05Reviewable finish
Require a narrow diff, verification results, assumptions, and a clear account of anything not checked.
More autonomy is not automatically better. Anthropic’s guidance on building agents recommends starting with the simplest adequate solution because agentic systems trade additional latency and cost for flexibility. A deterministic formatter does not need an agent. A tiny throwaway experiment may not need a full test harness. The process should be proportional to the consequence of a wrong answer.
Turn the vibe into a contract
I prefer a three-stage handoff: explore, distill, then delegate. Explore freely enough to find the shape. Distill the useful discoveries into behavior and constraints. Delegate the implementation only after the agent has something falsifiable to work against.
The handoff does not require a giant specification. A compact task contract is often enough:
Goal
What should change for the user or system?
Constraints
Which architecture, compatibility, security, or scope boundaries apply?
Acceptance criteria
What observable behaviors must be true, including important failure paths?
Verification
Which tests, builds, browser checks, or measurements should prove the change?
Stop conditions
When should the agent pause for a decision instead of guessing?This format does two jobs. It gives the agent a better target, and it exposes where my own thinking is incomplete. If I cannot say what evidence would change my mind, I am probably still exploring. That is useful information; it means the task should remain cheap and reversible for a little longer.
A passing build is evidence, not a verdict
Agentic coding is often described through autonomy, but verifiability is the more important property. The right evidence depends on the failure cost. A copy change may need a build and a narrow visual check. A data migration may need fixtures, reconciliation queries, a rollback path, and observation in a production-like environment. Neither checklist can be inferred from “make it work.”
A 2026 Anthropic study of roughly 400,000 Claude Code sessions observed a useful division of labor: people made about 70% of planning decisions, while the agent made about 80% of execution decisions. The study also found that task-specific domain expertise helped users frame directions, request verification, and recover from misunderstandings.
That is evidence from one product and one observed population, not proof that every agentic workflow produces good software. Still, it supports a practical model: the human contributes most by defining what matters and recognizing invalid results; the agent contributes most by carrying out and iterating through the implementation. The better the contract, the more safely execution can be delegated.
The tool can act; responsibility remains
An agent can misunderstand intent, pass incomplete tests, or make a locally sensible change that violates a business rule it never saw. Tool access also creates real operational risk. Sandboxes, scoped network access, approvals for consequential actions, and activity logs are not ceremony around the work; they are part of the engineering system that makes delegated execution governable. OpenAI’s account of running Codex safely shows these controls operating together rather than as isolated product settings.
Human review therefore does not disappear. It moves upward: from typing every line to shaping the problem, designing the environment, deciding what must be proven, and accepting responsibility for deployment. Reading code still matters, but so do reading diffs, interrogating test boundaries, and noticing which claim has no evidence beside it.
Choose the mode by the cost of being wrong, not by the novelty of the tool.
Vibe coding is excellent at turning an uncertain idea into something concrete enough to judge. Agentic coding is better at turning a defined change into a body of work that can be inspected, tested, and reviewed. Mature AI-assisted development needs both—and a deliberate moment when the first becomes the second.