Vibe Coding Killed Production. Here's the Autopsy.

Vibe coding in 2026 — the data is in and it’s contradictory:

74% of developers report productivity increases
63% spent more time debugging AI-generated code than writing it themselves
92% of US developers use AI coding tools daily
1.7x more “major” issues in AI co-authored code vs human-written (Red Hat analysis)
Amazon lost 6.3 million orders from AI-assisted code changes in March

Andrej Karpathy — who coined the term — now wants to retire it in favor of “agentic engineering.” Gene Kim wrote an entire book about it. Red Hat published “The Uncomfortable Truth.” It has its own Wikipedia page.

Vibe coding is great. Vibe coding in production is arson. The line between them is more important than the technique itself.

Where Vibe Coding Works

The common thread: low blast radius. If it breaks, nobody cares.

Prototypes and MVPs — speed matters, bugs are cheap
Internal tools nobody outside the team touches
CRUD-heavy applications with well-understood patterns
Solo projects where you’re the only user
Exploring a new library or API — learning, not shipping
Throwaway scripts — automation, data munging, one-time jobs

In these contexts, vibe coding is genuinely transformative. I use it daily. The ability to describe what I want and have an AI agent produce working code in seconds has compressed weeks of prototyping into hours.

Where Vibe Coding Kills

The common thread: high blast radius. If it breaks, people get hurt.

Production systems serving real users
Financial transactions (ask Amazon about their 6.3M lost orders)
Authentication and authorization — security bugs aren’t like other bugs
Data migrations — corrupted data propagates silently
Infrastructure changes — one bad Terraform apply and you’re paging the team at 3am
Anything touching PII — regulatory exposure compounds the technical risk

Amazon’s March 2026 disaster is the canonical example. Their Kiro AI coding tool was given unsupervised production access. In one incident, Kiro decided the optimal fix was to “delete and recreate the environment.” Nobody reviewed the decision before it executed. The result: 6.3 million lost orders, a 90-day safety reset, and mandatory senior engineer sign-off on all code changes.

The Spectrum

The mistake is treating this as binary — “vibe coding good” or “vibe coding bad.” It’s neither. It’s a spectrum, and the discipline is knowing where you are on it.

Prototype phase: Full vibe. Let AI generate freely. Ship fast. Don’t review every line. If it works, it works. Speed is the priority. Correctness is negotiable.

Validation phase: Start reviewing AI output more carefully. Add tests for critical paths. Check auth logic manually. Still fast, but with guardrails emerging.

Production phase: Every AI-generated change gets human review. Tests required for all new code paths. Canary deployments for anything touching user-facing systems. The AI writes the first draft — you ensure it won’t break things.

The discipline isn’t “never vibe code.” It’s being honest about which phase you’re in and applying the appropriate level of rigor.

The Data Behind the Danger

Red Hat published “The Uncomfortable Truth About Vibe Coding” with hard numbers: code co-authored by generative AI contains approximately 1.7x more “major” issues compared to human-written code, with elevated rates of security vulnerabilities.

Forrester analyst Andrew Cornwall put it plainly: “Vibe coding is great for prototypes but not wonderful for brownfield or production code.”

The 63% statistic deserves unpacking. Nearly two-thirds of developers have, at least once, spent more time debugging AI-generated code than it would have taken to write the code manually. This doesn’t mean AI coding is net negative — the 74% productivity increase is real. It means the productivity gains are unevenly distributed across task types.

AI excels at greenfield work where there are no existing conventions to violate. It struggles with brownfield work where understanding context matters as much as generating code.

The Missing Piece: Structured Prompting

Most vibe coding failures trace back to vague prompts producing vague output producing vague understanding of what the code does.

Before asking AI to build anything production-grade, I use what I call prompt contracts:

GOAL — what exactly should this code do?
CONSTRAINTS — what libraries, patterns, and conventions must be followed?
FORMAT — what should the output structure look like?
FAILURE CONDITIONS — what would make this implementation wrong?

This takes vibes and turns them into specifications. The AI produces dramatically better code because it has better constraints. And when something goes wrong, you can trace the failure back to a specific gap in the contract — not a vague “the AI messed up.”

What Amazon Should Have Done

Amazon’s post-mortem tells the story: they’re now requiring “controlled friction” in critical systems. That’s the right instinct. Here’s what controlled friction looks like in practice:

Classify every code change by blast radius. Low-risk changes (formatting, docs, tests) get lighter review. High-risk changes (auth, payments, infrastructure) get full review regardless of whether AI wrote them.
Automated quality gates. CI/CD pipelines that run security scans, test coverage checks, and performance benchmarks on every PR — human or AI-authored.
Canary deployments. Roll changes to 1% of traffic first. Monitor for anomalies. Expand gradually. This catches silent failures before they reach 6.3 million orders.
Kill switches. Feature flags that can instantly disable any AI-generated code path. Not rollback — instant disable. The difference matters at scale.
Agent review, not just code review. When an AI agent makes a multi-step decision (like Kiro’s “delete and recreate”), each step should be logged and reviewable. The decision chain matters as much as the final code.

The Evolution of the Term

Karpathy wants to call it “agentic engineering.” Gene Kim wrote a book embracing the original term. The industry hasn’t settled on language yet — and that’s actually the problem.

“Vibe coding” sounds fun. It sounds casual. It sounds like something you do on a Saturday afternoon.

“Agentic engineering” sounds disciplined. It sounds like something with processes, review gates, and accountability.

The work is the same. The framing determines how seriously people take the guardrails.

I don’t care what we call it. I care that the line between prototype and production is respected. Call it vibe coding on the left side of that line and engineering on the right side. The name doesn’t matter. The discipline does.