Is AI-written code safe for production?

The short answer

AI-written code is safe for production only if a human (or another rigorous system) reviews it before it ships. The code is not inherently dangerous; the workflow around it often is. The most-cited summary of the problem comes from the CEO of Cursor, who said publicly that "unreviewed AI code builds shaky foundations." The same rule applies to Claude Code, Copilot, Cursor, Devin, and every agent that writes code without a gate.

What "safe for production" actually means

A useful definition: code is production-safe if it meets the same bar as any other code you ship — it passes tests, it's been reviewed, it rolls back cleanly if it breaks, and its failures are observable. None of that is about who wrote it. All of it is about what happens after the code is written.

AI-written code fails this bar most often at the review step, because the natural pattern with agent-style tools is "ask for code, take the code, run the code." There is no pause. There is no read. There is no "does this actually do what I meant."

That gap is where the production incidents come from. A widely-reported 2025 case involved Replit's AI agent deleting a production database mid-session, triggering industry-wide scrutiny of unsupervised AI actions. Independent testing of Devin showed it succeeding on 15% of real tasks — the rest of the time it either produced unusable code or "got stuck in technical dead-ends" (Answer.AI independent test, cited in our pain-points research).

What a production-grade AI code review actually includes

If you're running AI-generated code into production, the review has to catch specific failure modes that AI writers produce more frequently than humans.

Security

SQL injection — AI writers sometimes concatenate strings into queries when they could use parameters. Every query needs a grep.
Auth bypass — missing guards on new endpoints. AI writers often miss tenant isolation; they assume the caller is already authorized.
Secret leakage — hardcoded keys, tokens pasted from an example in training data. Always a pre-commit scan.
XSS / CSRF — AI writers happily render user input into HTML without sanitization unless the framework enforces it.

Correctness

Off-by-one on pagination, loops, and dates. AI writers are confident and wrong here often.
Race conditions on shared state. AI does not reliably reason about concurrency.
Silent error swallowing. AI often writes try { ... } catch (e) {} to make a test pass.

Architecture

Wrong module / wrong layer. AI writers put business logic in controllers, data access in routes, and side-effects in pure functions, because they're writing locally without knowing the system's conventions.
Duplication. An AI asked to write a feature will happily re-write a helper that already exists 30 lines up.
Wrong abstraction level. AI will produce a 400-line single function where three 50-line functions would be clearer.

Tests

Tests that pass trivially. expect(true).toBe(true) — we have seen it. AI is very good at producing green tests; it is worse at producing tests that assert the actual behavior.
Missing edge cases. The AI-written happy path is usually fine. The error path, the empty state, the concurrent modification case — those get skipped.

Observability

No spans, no metrics, no structured logs. AI writers produce plain code. Observability is the first thing they drop when not explicitly asked.

What "18 review skills" means in our pipeline

Because the human review step is slow and expensive, we built a pipeline of automated reviewers. Each review skill is a focused agent that reads the diff with one question in mind, then passes or fails it. The full list lives in our repo, but the top-level groups are:

Security review — SQL injection, auth, CSRF, secret scanning.
Tenant isolation review — every query scoped to the right tenant.
Spec adherence review — does the code actually do what the brief said?
Telemetry review — metrics, spans, and logs tied to the feature flag.
Performance review — N+1 queries, missing indexes, blocking async.
Architecture review — module boundaries, dependency direction.
Quality review — dead code, naming, complexity.
Test review — coverage, edge cases, assertion strength.

That's eight. The full set is 18 — the rest handle observability completeness, rollback compatibility, tenant quotas, and narrower domain checks. Each one is a specific, bounded question a reviewer can answer.

This pattern — narrow reviewers, each with one job — is the scalable version of what a senior human does during a code review. A senior reads a diff and simultaneously checks for 30 things. The AI pipeline splits those 30 things into 18 reviewers who each check one thing rigorously.

How to run this if you don't have a pipeline

Even without our pipeline, you can move the bar significantly by adopting three rules.

1. No AI-written code merges without a human reading it

Not "skimming." Reading. The diff should be small enough that a human can read every line. AI-generated 2,000-line PRs are the hardest category; break them up before merge.

2. All AI-generated code ships behind a feature flag

Every new AI-written feature goes behind a flag that defaults off for real users. Turn it on for yourself. Watch. Expand. Roll back instantly if anything goes wrong. This is the single biggest-return rule — see the Lovable 70% wall guide for why the last 30% matters and how flags let you ship the first 70% without betting the whole system on it.

3. Run a security scanner on every commit

semgrep, gitleaks, and the GitHub Advanced Security suite catch a meaningful fraction of the mistakes AI writers make. Add one; keep it green.

When AI-written code is actually safer than human-written code

Worth naming the other side. AI writers do some things well:

Boilerplate. CRUD endpoints, data access layers, test scaffolds. These are mechanical. AI does them faster and with fewer typos.
Style consistency. AI writers follow your lint rules once they know them. Human writers sometimes do not.
Documentation. AI will write a docstring for every function; many humans will not.

The gap is not in the writing — it is in the judgment. AI writers do not know what they don't know. Human review exists to close that gap.

What would make this guide wrong

A qualitatively better AI coding model ships. Progress has been steady; a step-change in autonomy (a Devin that actually hits 80% instead of 15%) would reduce the need for review. As of April 2026, no such model has shipped.
Your production environment is sandbox-only. If "production" is a demo for one internal user, the stakes are different. Run what you want.
You consider the AI writer part of your team, not a tool. Some teams pair-program with AI all day and review in tight loops continuously. Under that model, the "did anyone read this" rule is already being enforced implicitly.

Changed since last time

2026-04-21 — First published.

Sources

"Unreviewed AI code builds shaky foundations" — Cursor CEO, quoted in Fortune. Cited in softwaremovers/marketing/pain-points-research/04-pain-themes.md.
Devin 15% success rate — Answer.AI independent test, via same file.
Replit AI deleting production data: widely reported mid-2025; see coverage in The Register and Hacker News discussion.
Our 18-review-skill pipeline: .claude/skills/review-* in the modernizer repo; full list at .claude/agents/modernizer.agent.md.

If you want a pipeline that reviews every AI-written change before it ships, see pricing or start with a $299 legacy audit. Our retainer includes the review pipeline — you do not run it; we do.