Quick answer
- Vibe coding
- Prompt, accept the diffs, ship the prototype (Karpathy, Feb 2025)
- Agentic engineering
- Same agents under specs, gates, isolation, and review (Karpathy, early 2026)
- The dividing question
- Will anyone have to maintain this code?
- Karpathy's framing
- Vibe coding raises the floor, agentic engineering raises the ceiling (Ascent, April 2026)
Two Terms, One Coiner
Vibe coding is Andrej Karpathy's February 2025 coinage for a way of building with AI where you give in to the vibes: prompt the model, accept the diffs without really reading them, and keep going, an approach he explicitly framed as fine for throwaway projects. The term escaped its origin, became shorthand for unreviewed AI-generated code in general, and was named Collins Dictionary's Word of the Year for 2025.
Agentic engineering is the successor term Karpathy proposed in early 2026, declaring his own coinage passé. It names the same activity, directing AI agents that write and run code, done with real engineering controls: a written spec before code, a human approval gate, isolated branches per task, verification against acceptance criteria, and PR review. The full definition and its six practices are covered in what is agentic engineering.
Because one person named both eras, this is not a turf war between camps. At Sequoia's Ascent event in April 2026, Karpathy framed the relationship himself: vibe coding raises the floor, agentic engineering raises the ceiling. The rest of this page is about the practical question that framing leaves open: which one should you be doing, on which work, today?
The Comparison, Dimension by Dimension
The table below is the whole argument in compressed form. Note the last two rows: both approaches have a real failure mode, and both have work they are genuinely right for.
| Dimension | Vibe coding | Agentic engineering |
|---|---|---|
| Intent | Prototype: prove the idea fast | Production: software you must maintain |
| Code review | Skipped, diffs accepted unread | Gated, every change is a reviewed PR |
| Specs | None, the prompt is the plan | Written and enforced before code starts |
| Failure mode | An unmaintainable app nobody understands | Process overhead on trivial tasks |
| When it's right | Weekend project, demo, one-off script | Anything maintained, shared, or shipped |
The dividing question is not tool quality or model choice, both columns can run the exact same Claude Code session. It is: will anyone have to maintain this code? If no, review is ceremony and you should skip it. If yes, every unread diff is a small loan against the future, and the workflow that pays those loans on time is the one described in engineering with AI agents.
Ship your first agent today
Download AIDEN free and point it at your existing Claude Code or Codex setup. No credit card, running in minutes.
Download AIDEN freeFree to start · macOS 12+ · No credit card required
When Vibe Coding Is the Right Call
A comparison page written by a company that sells discipline should be honest about this: vibe coding is often correct, and pretending otherwise is how methodology content loses your trust. Skipping specs and review is a rational trade whenever the cost of a latent defect rounds to zero.
Throwaway prototypes
Demos and spikes
Personal tools with one user
Learning a new stack
The Graduation Path: Prototype to Production
The most useful question is not “which side are you on” but “how does work cross the line.” A vibecoded prototype that earned real users does not need to be apologized for, it needs to graduate. The path that works treats the prototype as a requirements document, not a foundation:
- 1
Freeze the prototype as the reference
Stop adding features to the unreviewed codebase. Its remaining job is to demonstrate the behavior you want, which is the one thing vibecoded software is verifiably good at. - 2
Spec the rewrite, module by module
Turn each behavior into a written spec: scope, files, acceptance criteria, exclusions. The prototype makes this unusually easy because you can describe what already exists instead of imagining it. The format is covered in spec-driven AI development. - 3
Gate the agents
From here, no agent codes without an approved spec, and every task runs on its own branch or worktree. The same agents that built the prototype now work under supervision, and the difference shows up in the diffs. - 4
Verify and review every change
Agents run tests against the acceptance criteria before handing off; you review each PR against its spec. Once a module passes review, it is production code, and the prototype's version of it is dead weight you delete.
Teams that skip the graduation and keep prompting against the prototype usually rediscover why: unreviewed code on top of unreviewed code compounds, and the eventual forced rewrite costs more than the deliberate one would have.
Where AIDEN Sits
AIDEN is built for the right-hand column of the table and for the graduation path. It is a macOS desktop app that orchestrates your local Claude Code and Codex CLIs on a kanban board, and its defining choice is an enforced spec gate: AIDEN drafts a spec from your story and its codebase analysis, and no agent starts coding until you approve it. Each story then runs in its own git worktree and lands as a PR with the spec attached, which is the loop described in Claude Code orchestration, made non-optional.
That makes AIDEN a poor vibe coding tool on purpose. If you are prototyping, a raw agent in a terminal is the right amount of process. The moment the work has to be maintained, the gate stops being friction and starts being the point. It is free for one project, so the graduation path above is cheap to trial on one real module.