Vibe Coding Versus Agentic Engineering

Both approaches have an LLM write the code. What separates them is who decides the code is acceptable, and where correctness is pinned down — in a person’s head, or in a file that can be re-run.

1.1 Definitions used in this series

Vibe coding means asking an AI to write code and judging the result by eye and by feel: run it, and if it looks about right, move on. The specification lives in the head of whoever asked. Review is a quick read. Nothing is recorded for next time. It is very fast, and it suits prototypes, one-off scripts, and finding out whether an idea is even possible.

Agentic engineering means building a system where the agent works in a loop whose success condition is machine-readable. The person moves from “the one who types code” to “the one who designs the spec, the acceptance criteria and the boundaries”, while the agent writes, runs, reads errors, fixes and re-runs until it passes or hits a ceiling.

The one sentence that separates them

Vibe coding: “The AI writes the code, and I look at whether it seems fine.”

Agentic engineering: “I write the definition of fine, and the AI works until the machine says it is.”

1.2 Comparison

Dimension	Vibe Coding	Agentic Engineering
The AI’s input	Conversational prompts building on chat memory	Spec files, project rules, and failing tests
Definition of success	In someone’s head, changeable at any moment	In verify.sh or CI — deterministic and repeatable
Who judges correctness	The LLM plus human eyes	Compiler, test runner, linter, type checker
Session length	Long, accumulating context until it is muddy	Short and disposable; state lives in files, not context
What remains afterwards	Code, and nothing else	Code, tests, spec, ADRs, and rules the next agent can read
When the AI gets it wrong	You find out when a user does	You find out when a gate turns red, before commit
Repeatability	Doing it again gives a different result	Running the same pipeline gives a comparable result
Up-front cost	Almost none	High — one to three days investing in the rules
Cost at month six	Very high: code nobody understands, where each fix breaks something else	Flat: new people and new agents can pick it up
Suits	Prototypes, spikes, one-off work, learning	Systems with real users, real money, real data, a team

A caution

Agentic engineering is not automatically better. It costs more at the start. If the question is “can I find out in two hours whether this idea is viable”, building a full gate is wasted time. A simple test: if this code will still exist in three months, invest in the system. If not, let it vibe.

1.3 The same task, done both ways

The task: add discount coupons to an existing checkout API.

The vibe version

Person: "Add coupons to checkout. Support percentage and fixed-amount discounts."
AI:     [writes coupon.py, 180 lines, and edits checkout.py]
Person: [runs it, fires one request in Postman, gets 200 OK] "Fine, works"
Person: git commit -m "add coupon"

What remains unknown:

Question	Status
Can an expired coupon still be used?	Nobody tried
Two coupons at once?	Nobody tried
A discount larger than the total, going negative?	Nobody tried
Race condition on a limited-quantity coupon?	Nobody tried
Percentage coupon versus tax — which is applied first?	The AI guessed; nobody confirmed

The agentic version

1. A person writes docs/specs/coupon.md in about 15 minutes: six business rules including the tax ordering, four cases that must be rejected with their error codes, and what is explicitly out of scope — v1 does not support stacking.

2. A person or the agent writes tests from the spec first. They must all fail.

$ pytest tests/test_coupon.py
14 failed        [RED]

3. The agent works the loop: read the spec, write an implementation, run verify.sh, read the errors, fix, run again.

round 1: 9 failed
round 2: 3 failed
round 3: 0 failed

4. The gate runs the full set: format, lint, types, unit, property, integration, coverage diff.

$ ./scripts/verify.sh
ALL GATES PASSED    [GREEN]

5. A person reviews three things, not every line: does the spec match what the business wanted; do the tests cover genuinely dangerous cases or merely describe what the code does; and did a dependency, migration or breaking change slip in.

6. Merge after a 5% canary held for 24 hours, watching the guardrail metrics.

The time difference is roughly 40 minutes against three hours for the first feature. But for features 2 through 20 in the same project, the agentic path is faster, because the spec template, test fixtures, gate and the rules in AGENTS.md are all reusable. The vibe path gets steadily slower, as untested code accumulates until touching anything breaks something.

1.4 Where vibe code breaks as a system grows

Symptom	Structural cause
Fixing here breaks there	No regression tests; every change is a guess that nothing depended on the old behaviour
The AI overwrites what exists	No rules file describing the existing structure, so the agent invents a new pattern each time
Three styles in one file	Each session had different context, and no convention is machine-enforced
Nobody dares refactor	No criterion confirms that behaviour is unchanged afterwards
New people cannot be onboarded	The reasoning behind decisions lives in a chat that is gone, not in the repository
Frequent production bugs	The passing criterion was “looks about right”, which does not catch edge cases

The observation worth keeping

None of these six problems comes from the AI being bad at writing code. They come from the system having no permanent place to keep knowledge. The remedy is therefore not a smarter model, but moving knowledge out of the context window and into files.

What this chapter settles

The difference is not the tool. It is where the definition of “passing” is written down. Keep it in someone’s head and the system cannot grow. Put it in a file that can be re-run, and the agent can work on its own while people review only what matters.

The next chapter covers the five principles behind this way of working, and the anatomy of a single loop.