Why does AI-generated code pass review but still fail in production?

Treat AI-generated code like code from an unfamiliar developer: read it line by line and make sure you understand how it executes. Tests should cover negative cases, invalid input, retries, timeouts, empty data, and other failure paths—not just the successful flow. Writing the tests first, or at least defining the expected behavior before asking for code, makes it harder for subtle assumptions to slip through.

Replay sanitized production traffic against the candidate build before merging or deploying. Even a few hours of representative requests can expose unusual state transitions, unexpected data shapes, and performance problems that unit tests miss. For anything that still gets through, use structured logs, metrics, tracing, profiling, and feature flags so you can canary the change, detect abnormal behavior quickly, and roll it back without debugging blindly in production.

Make sure the safety net is actually running. A large test suite is useless if a dependency or configuration change causes the test runner to collect zero tests. Treat zero collected tests, skipped suites, type-check failures, and coverage drops as build failures rather than harmless warnings. Also verify production-like checks such as CSP, because a development server can hide issues that appear during the real build and deployment process.

A lot of production-only failures are really environment mismatches. Check configuration and secrets, case-sensitive file paths, real data sizes, null values, missing indexes, time zones, concurrency, connection limits, latency, and network failures. Use the production build locally or in staging, seed it with messy data, run in UTC, and keep the staging database shaped like production. The closer the environment is to reality, the more of these bugs appear before release.