Vibe Coding vs Agentic Engineering: Where the Line Really Is (and Why It's Blurring)
The short answer
The line between vibe coding and agentic engineering is not the tool: both use the same AI agents. It's your relationship to responsibility for the shipped code. You're vibe coding when you accept the AI's output without necessarily reading or understanding it — it's quality-agnostic, you steer by feel and by results. You're doing agentic engineering when you stay accountable for every line that reaches production: you review diffs, you test, you understand the architecture, you answer for the bugs. Same keyboard, same model, two different relationships to risk.
And that line is blurring. Simon Willison observes (May 2026) that as agents become reliable, even pros stop reviewing every line. He calls it a normalization of deviance: every time you skip review and nothing breaks, skipping review becomes the new normal — until the day it breaks. Staying on the right side doesn't mean rejecting AI or reading every character: it means calibrating review to the actual risk of what you ship. A throwaway prototype and a payment service don't deserve the same vigilance. The rest of this piece lays down the definitions, the boundary, and a simple method to keep from sliding across it without noticing.
Defining both terms, without contempt
This debate carries a lot of class contempt: the "real" dev versus the "tourist" who just prompts. Let's skip that, because it's both wrong and useless.
Vibe coding: you describe an intent, the AI generates, you check whether "it works," you iterate. You don't necessarily read the code; sometimes you don't read it at all. It's quality-agnostic by definition — internal quality isn't the criterion, the visible result is. And that's perfectly legitimate for a prototype, a personal script, a throwaway, a weekend demo.
Agentic engineering: you use exactly the same agents, but you keep your hands on what matters. You read the diffs, you write or demand tests, you watch the architecture, you can explain what each piece does and why. AI speeds you up; it doesn't offload the responsibility.
So the distinction is neither the developer's skill level nor how much code was typed by hand. It's the question: do I answer for this code?
Where the line actually falls
One test reveals it: could you defend this code in review, and are you willing to answer for it in production? If yes, you're on the engineering side, even if the agent typed all of it. If you couldn't explain what the code does — and that doesn't bother you — you're vibe coding.
| Vibe coding | Agentic engineering | |
|---|---|---|
| Goal | A result that works, fast | A system you own and maintain |
| Relation to code | Quality-agnostic: review optional | Accountable for every shipped line |
| Review | By feel, often none | Calibrated to risk |
| Who answers for bugs | The AI, luck, nobody | You |
| Right terrain | Prototype, throwaway, personal, demo | Prod, team, real data, money |
Neither column is "bad." The problem only appears when you run the left column on the right column's terrain — shipping code you don't understand into a system handling real users, real data, real payments.
Why the boundary is blurring (Simon Willison's point)
Here's the observation that makes this urgent in 2026. Simon Willison notes (May 2026) that the boundary is blurring not because beginners are leveling up, but because experts are lowering their guard. Agents have gotten good enough that reviewing every line feels like a waste of time most of the time.
The mechanism he names, normalization of deviance, is borrowed from the sociology of industrial accidents: a rule-bend that causes no incident stops being perceived as a rule-bend at all. Applied to our craft:
- You accept a diff without reading it. Nothing breaks.
- You do it again. Still nothing.
- After fifty times, "accept without reading" is no longer an owned exception — it's your default process.
- On the fifty-first, the agent introduces a silent flaw, a subtle regression, a leak. And nobody saw it go by.
The trap is nasty because the reinforcement is positive in the short term: skipping review is rewarded (faster, it works) right up until it isn't. That's why you can drift from the good side to the bad one without ever deciding to.
How to stay on the right side without becoming unbearable
The wrong answer would be "always review everything." Nobody will, and it isn't even rational. The right answer is to make review proportional to the blast radius of the code. Concretely:
- Sort by risk zone. A throwaway display helper ≠ an auth middleware ≠ a database migration ≠ billing logic. The bigger the blast radius, the tighter the review. Zero review is a valid choice — on zero-radius zones.
- Lock tests where it counts. A failing test is a review that doesn't depend on your alertness that day. It's the best guard against normalization of deviance, because it doesn't wear off.
- Name the moment you skip review. The danger isn't skipping review, it's doing it without knowing. "I'm merging this without reading, it's a throwaway" is healthy. Silent auto-merge on production code is not.
- Keep the ability to explain. If you couldn't tell a colleague what this module does and why, you've already crossed the line — regardless of your skill level.
- Make review a gate, not a courtesy. On critical zones, a human who answers for the code must have understood it before merge — agent or no agent.
None of these rules requires giving up agents or slowing down on low-stakes code. They just move the effort to where it pays off.
The real takeaway
The line is not an identity ("I'm a real dev / I'm a vibecoder"), it's a stance you choose, file by file. The same developer vibe-codes their config script in the morning and does rigorous agentic engineering on the payment service in the afternoon — and that's fine. What damages production isn't vibe coding: it's vibe coding applied by default, unnoticed, where engineering was needed. The only discipline that holds up in 2026 is knowing which side you're on the moment you hit "merge."
FAQ
Is vibe coding bad? No. For a prototype, a throwaway, a personal script or a demo, it's actually the optimal use of agents. The problem isn't vibe coding: it's applying it, without deciding to, to production code you don't understand.
How do I know which side of the line I'm on? Ask yourself one question: "Could I explain what this code does, and would I answer for it in review and in production?" If yes, you're doing engineering, even if the agent wrote all of it. If no, and that doesn't bother you, you're vibe coding.
If agents are reliable, isn't review a waste of time? That's exactly the trap Simon Willison describes (May 2026): normalization of deviance. Reliability rewards skipping review… until the incident nobody saw coming. The fix isn't reviewing everything, but calibrating review to the code's blast radius.