Vibe Coding to Agentic Engineering: Kill the Bug Spike

Ninety-two percent of US developers now reach for an AI coding tool before they reach for the docs. Only 29% trust what those tools hand back. That gap is not a mood. It is a measurement: one study of roughly 800 developers found bug rates climbed 41% after AI tools were adopted. Teams didn’t get worse at engineering. They got faster at generating code than they got at reviewing it.

If you’ve shipped anything real in the last year, you already feel this. The AI writes a plausible function in four seconds. It has tests. It has comments. It looks like it was written by someone who cared. Then it fails in production on the one code path nobody prompted for. This piece is about the workflow shift that closes that gap — moving from vibe coding to what people are now calling agentic engineering — and the practice that actually does the work: context engineering.

Abstract split visual contrasting a chaotic tangle of code with a bounded, ordered structure — Same model, two disciplines: unbounded guessing on the left, bounded context on the right.

Vibe coding was never the villain

Andrej Karpathy coined “vibe coding” in early 2025 to describe a specific, honest thing: you throw natural-language prompts at a model, accept the output without reading it closely, and paste error messages back in until it works. It’s fun. It’s fast. For a weekend prototype or a throwaway internal tool, it’s genuinely the right call.

The problem is that vibe coding quietly walked into production. In February 2026, Karpathy himself called the term “passé” and offered a replacement — agentic engineering — noting that the new default is that you’re not writing the code directly 99% of the time; you’re orchestrating agents that do, “except with more oversight and scrutiny.” His framing is worth keeping: vibe coding raises the floor. Agentic engineering preserves the ceiling.

Simon Willison drew the same line in his own terms. He calls vibe coding “fantastic” for personal tools where a bug only hurts you, and “grossly irresponsible” for software other people depend on. The failure mode isn’t the model. It’s using a prototype technique on a system with real users, real data, and real blast radius.

What actually changed: the model got a job, not a personality

Here’s the distinction that matters when you’re staring at a PR at 6pm. Vibe coding operates on vibes. No plan, no system context, no contract for what “done” means. The model guesses your intent from a sentence and fills the rest with the statistical average of the internet. Which is fine, until the average is wrong for your codebase specifically.

Agentic engineering gives the model a bounded job inside real context: your API contracts, your data models, your architecture, your conventions, your test suite. It works in a sandbox, it can run and read its own errors, and it operates under review discipline you actually enforce. Same model. Radically different failure surface.

	Vibe coding	Agentic engineering
Context	A prompt. The model infers the rest.	API contracts, data models, architecture, conventions — supplied deliberately.
Planning	None. Prompt → output → iterate on errors.	Plan first, scoped task, defined “done” and acceptance criteria.
Review	You skim it, or you don’t read it at all.	Bounded diff you can actually review; agent runs its own tests first.
Best use	Prototypes, spikes, UI exploration, throwaway tools.	Production changes inside an existing system.
Failure mode	Silent breakage on the path nobody prompted for.	Caught in review or CI, because there’s a contract to check against.

The same model, governed by two different disciplines, produces two different risk profiles.

Context engineering is the actual skill

Prompt engineering was about phrasing one request well. Context engineering is about reliably maintaining and updating the project context the agent works inside, as the work progresses. It’s the difference between telling a new hire “build the checkout flow” and handing them the schema, the payment contract, the error conventions, and the three edge cases that bit you last quarter.

This is where the 41% bug spike actually gets fixed — not by trusting the model more, but by shrinking what it has to guess. A CodeRabbit analysis of 470 pull requests found AI-coauthored code carried 1.7x more major issues, with logic flaws up 75%. Logic flaws are almost always context flaws. The model didn’t know the invariant because nothing told it.

A minimal, durable setup looks like this — a rules file the agent reads on every task, checked into the repo next to the code it governs:

## Project context
- Stack: TypeScript, Postgres, Next.js. No new deps without approval.
- Money is stored in integer cents. Never floats. Ever.
- All DB writes go through the repository layer, never raw SQL in handlers.

## Definition of done
- Types pass, tests pass, no console.log left behind.
- New behavior has a test that fails without the change.

## When unsure
- Stop and ask. Do not invent an API that isn't in /contracts.

It’s boring on purpose. Boring context is what keeps the agent from getting creative in the exact places you don’t want creativity — like deciding, on its own, that floats are fine for money this one time.

A central rules file feeding structured context streams into a coding agent — Context engineering: shrink what the agent has to guess, and the logic flaws shrink with it.

A workflow you can run on Monday

You don’t need a platform team to adopt this. You need five habits.

Plan before you generate. Make the agent write the plan first — files it will touch, the approach, the risks. Read that. A wrong plan is cheap to fix; wrong code with passing tests is expensive.
Feed it the contracts, not vibes. Point it at the actual schema, the API spec, the existing patterns. If the context lives only in your head, the model can’t use it.
Bound the task. “Add rate limiting to the login endpoint” beats “make auth better.” Small scope means a reviewable diff, and reviewable is the whole game.
Make it run its own tests. An agent that executes code and reads its own errors catches its own dumb mistakes before you ever see them. This is the single highest-leverage habit.
Review like it’s a stranger’s code. Because it is. Documentation and tests no longer signal care — they’re free now. Read the logic, not the packaging.

That fifth point is the one people skip, and it’s the one the data punishes. Willison admits he’s stopped reviewing every line as models improved — and openly wonders whether that’s responsible for production. Notice the tension. The better the tools get, the more tempting it is to drop the discipline, and the more it costs when you do.

Engineer’s note: [Add your story here — e.g., the time AI-written code passed review and broke in prod, and what you changed after.]

Why the tool you pick matters less than the discipline around it

For what it’s worth, the tools have opinions about this too. In the Pragmatic Engineer’s early-2026 survey of 906 engineers, Claude Code was the most-loved coding agent at 46%, ahead of Cursor at 19% and GitHub Copilot at 9% — and the tools winning are the ones built around agentic loops and project context, not autocomplete. That’s not an accident. The market moved the same direction the failure data did.

But don’t over-index on the logo. A great agent with no context and no review still ships the 41% spike. A mediocre agent with a solid rules file, bounded tasks, and honest review will out-ship it every time. The differentiator was never the model. It’s whether you built the review discipline before you scaled the generation.

The honest summary

Vibe coding isn’t dead. It’s demoted — back to the prototypes and spikes where it always belonged. For real systems, the move is agentic engineering: bounded autonomy, deep context, and review you actually do. The 41% number isn’t a reason to distrust AI. It’s a reason to distrust AI without a plan, without context, and without reading the diff. Give the agent a job description instead of a vibe, and the spike stops being your problem.