Agentic Engineering vs Vibe Coding: Where the Line Is
In short
Both terms come from the same person. Andrej Karpathy coined "vibe coding" in February 2025 for the workflow where you describe what you want, accept the diff without reading it, and paste errors back until it runs — explicitly scoped to throwaway weekend projects. In his Sequoia Ascent 2026 summary, published 30 April 2026, he named the other half: "Vibe coding raises the floor... Agentic engineering raises the ceiling. It is the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability." The line is not the tool, the model, or the size of the codebase. It is whether a human is accountable for a reviewable artifact before the agent runs and a machine-checkable gate after it. Same agent, same prompt, same repo — the difference is three questions you can answer yes or no. Discipline is not free: specs cost tokens, wall-clock time and attention, and on a prototype that is pure waste.
Two answers to the same question
Both terms answer one question: what is my job now that the agent writes the code?
Vibe coding says: your job is to describe and react. Karpathy's original framing was to "fully give in to the vibes, embrace exponentials, and forget that the code even exists" — accept all diffs, do not read them, paste errors back without investigating. He was clear this was for throwaway projects, not production.
Simon Willison tightened the definition a year later: vibe coding is "building software with an LLM without reviewing the code it writes". His argument is that responsible AI-assisted programming — reviewing, testing, being able to explain how it works — is simply software development. The term is about the review step, not the amount of AI involved.
Agentic engineering says: your job is to specify, delegate and verify. In Karpathy's 2026 framing the unit of work moved from the line to the "macro action" — implement this feature, refactor this subsystem, fix this failing suite — leaving the engineer spec design, code review, testing and the quality bar.
Meanwhile the vocabulary went mainstream: Collins named "vibe coding" its Word of the Year 2025, roughly the point where a term stops meaning one thing. For the plain-English version, see our guide to what vibe coding actually is.
Where the line actually falls
Most comparison posts draw the line at tools (Cursor = vibe, spec-kit = agentic), at model quality, or at project size. All three are wrong. You can vibe code inside a spec-driven framework by approving every generated document unread, and you can do real agentic engineering in a plain chat window with a scratch file and a test command.
Here is a test you can apply to the session you are in right now:
- Is there an artifact the agent will be judged against, written before it runs? A spec file, a failing test, an issue with acceptance criteria. Not "make the login better" in chat.
- Did a human read it and change something? An LLM-generated spec that you approved without editing is not oversight. It is a longer prompt.
- Is there a check that fails without a human opinion? Tests, types, a linter, a smoke test in CI. Something that returns a non-zero exit code when the agent is wrong.
Three yeses is agentic engineering. Three noes is vibe coding, a legitimate mode for the right work. One or two yeses is the dangerous middle: enough ceremony to feel safe, not enough to catch anything. That middle is why "we do spec-driven development" and "we keep shipping regressions" coexist so comfortably.
The two workflows side by side
| Vibe coding | Agentic engineering | |
|---|---|---|
| Input to the agent | A sentence in chat | A spec, a failing test, or an issue with acceptance criteria |
| Human reads the diff | No — that is the definition | Yes, or a reviewer does |
| Verification | "It runs on my machine" | Tests, types, lint, CI — exit codes, not vibes |
| Context artifacts | None; context dies with the session | CLAUDE.md / AGENTS.md, spec files, ADRs in the repo |
| Failure mode | Silent breakage found by users | Slow delivery, spec theatre, token bills |
| Recovery when it goes wrong | Regenerate and hope | git revert, then fix the spec |
| Cost profile | Cheapest per attempt | 2–4× the tokens per feature, plus your review time |
| Fits | Prototypes, spikes, throwaway tools, learning | Anything with users, money, data or a second maintainer |
| Ceiling | Falls apart when you cannot hold the system in your head | Falls apart later, at repo-wide complexity |
The row that matters most is recovery. In vibe mode you cannot revert to a known-good state because you never established one — there is no commit whose contents you understood. That is a state-management problem, not a code-quality one, and it is why vibe-coded projects tend to die suddenly rather than gradually.
What the discipline actually costs
The honest part, which the tooling vendors skip.
Tokens and wall clock. A spec-driven run does more model calls: a spec pass, a plan pass, a task breakdown, then implementation, then review. On a small feature that is often slower end to end than just asking. If you are watching a bill, our breakdown of what this costs per month has the arithmetic.
Spec theatre. The dominant failure of spec-driven development is a beautiful generated requirements.md nobody read, then design.md generated from it, then tasks.md from that — a chain whose only human input was five approvals. You paid the full price of the discipline and got none of it. If you approve a generated spec without editing a word, either edit it or drop the ceremony.
A ceiling that discipline moves but does not remove. Specs, tests and CI keep an agent honest per change. They do not stop a repository from becoming something no agent can navigate. The gates make the wall visible earlier; they do not delete it.
Tooling prices, as of July 2026. Kiro, Amazon's spec-driven IDE, generates requirements.md, design.md and tasks.md per feature; its free tier gives 50 credits a month and Pro is $20/month. GitHub's spec-kit is MIT-licensed and free — 124k stars since August 2025 — and drives the same constitution → specify → plan → tasks → implement loop across 30+ agents. And you can get most of the benefit for nothing: Claude Code's plan mode proposes a plan and touches no files until you approve, which covers rule 1 and rule 2 of the test above.
Moving from one to the other
You do not need to adopt a framework on Monday. Add the gates in the order of how much they save you per hour spent.
First, a verification gate. One command that must pass before you accept anything: npm test && npm run typecheck, or your equivalent. Put it in your agent instructions file with the words "run this before you claim done". That single change turns the largest category of agent failure — confident completion of work that does not work — into a loud one. We wrote a whole piece on it: when the AI says done but it isn't.
Second, plan before edit. Turn on plan mode, or ask for the plan as a message and read it. Ten seconds catches "I'll refactor the auth module while I'm in there" before it happens.
Third, a written artifact for anything over an hour. A markdown file with the goal, the constraints, what is out of scope, and how you will know it worked. Edit it yourself, hand it to the agent, keep it in the repo — the next session, human or agent, will need to know why.
Fourth, only if the first three stuck: a framework. spec-kit or Kiro give you templates and command scaffolding. They accelerate a habit you already have; they do not create one. Sharper prompts help throughout — our prompting guide covers the technique.
And keep vibe coding in the toolbox. Exploring an unfamiliar API, testing whether an idea is worth specifying, building something you delete on Friday — writing a spec first is the expensive mistake there. The skill is knowing which mode you are in, and never drifting between them without noticing.
FAQ
What is agentic engineering?
It is the practice of directing AI coding agents against a written spec with human review and machine-checkable verification, so the output can go into production. Karpathy defines it as "the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability". In day-to-day terms: you write or edit the spec, the agent implements, tests and CI decide whether it worked, and you stay accountable for the result.
Is vibe coding the same as AI-assisted coding?
No, and the distinction is the whole point. Vibe coding, in Simon Willison's tightening of the term, is building software with an LLM without reviewing the code it writes. If you read the diff, run the tests and can explain how the thing works, you are doing software development that happens to use an AI. Using Copilot or Claude Code all day does not make you a vibe coder; skipping the review does.
Is spec-driven development the same as agentic engineering?
Spec-driven development is one implementation of it — usually the one with formal artifacts like requirements.md, design.md and tasks.md. Agentic engineering is the broader stance: a reviewable artifact before the run, a machine-checkable gate after it. A failing test plus a CI pipeline satisfies that without a single spec document. Conversely, a full spec chain that nobody edited satisfies the paperwork and none of the substance.
When should I just vibe code?
When the cost of being wrong is near zero and the cost of specifying is not: throwaway scripts, spikes to test feasibility, personal tools with one user, learning an unfamiliar library. The honest test is whether you would be comfortable deleting the whole thing and starting over. If yes, skip the ceremony. If it touches user data, money, auth, or anyone else's workflow, it fails that test.
Does agentic engineering actually take longer?
Per feature, usually yes — more model calls, more reading time. Across a project, that is the wrong unit. What matters is total time including debugging things you never reviewed, plus the rewrite when the codebase becomes unnavigable. On a two-day prototype the overhead is pure loss; on anything with a second maintainer it is the cheaper path — but claim that from your own delivery data, not a vendor's chart.