When AI-written code breaks production: the postmortem pattern

The first time an AI-written change breaks production, the incident review has a mood the previous hundred incidents did not. Someone has a screenshot of the diff. Someone wants to know which tool generated it. Someone senior says the word ban. This note is about running that postmortem honestly, because the finding is almost always the same: the agent wrote the bug, and the process approved it. The tool did not merge anything on its own.

That sentence is not a deflection; it is the whole analysis. An AI code incident in production means the change passed the same road as everything else you ship. Some review, some tests, some pipeline, some deploy gate said yes. The interesting question is which one, and why.

Blameless, extended to agents

Blameless postmortems exist because asking who screwed up produces hiding, while asking what allowed this produces fixes. The discipline extends cleanly to agents. As a root cause, "the agent wrote a bug" has exactly the value of "the intern wrote a bug", which is none. Models produce plausible, wrong code at a rate that is known and not zero. That rate is an input to your system design, like human fatigue or flaky infrastructure. The postmortem question is unchanged: which gate should have caught this class of failure, and why did it not.

What AI code incidents keep revealing

Run the analysis honestly and a familiar list appears.

The diff was too big to review. A 900-line PR got a twenty-minute approval. A review process built for human-speed output rubber-stamps under agent volume: the approval was real, the reading was not.

The changed path had no test. The agent iterated until the suite was green, and green did not include the behavior that broke. The test suite is the leash; an untested path is delegation without one.

The gate was advisory. A warning that has been ignored for a year, a coverage check disabled "temporarily" in March. Guardrails that can be skipped are suggestions, and volume finds every suggestion.

The prototype got promoted. Something built in exploration mode shipped to a production path without a hardening pass, because it worked in the demo and the sprint was ending.

The context lied. The agent followed a stale runbook or context file, faithfully, into a wall. Documentation an agent reads is now an input to production and has to be maintained like one.

Fix the gate, not the authorship

The fixes fall out of the findings, and none of them mention the tool: diff size limits, coverage requirements on changed lines, review depth routed by risk (authentication, payments, data deletion get the slow look no matter who wrote the code), and deploy gates that shrink the blast radius (canary releases, feature flags, one-command rollback). Notice the shape of that list. These are the controls you arguably wanted before agents existed. Agent volume did not create the weakness; it removed the slack that let you live with it.

Two responses that make it worse

The ban feels decisive and reduces nothing. Engineers keep using the tools on personal accounts, invisibly, with none of your guardrails attached. You keep the entire risk and lose the visibility, the worst position available.

The blanket rule ("AI-generated code requires double review") fails differently. It is unenforceable, because in an agentic workflow authorship is mixed and mostly unknowable. And it points at the wrong axis: risk should route review depth, not authorship. A human-typed migration on the billing database deserves far more scrutiny than an agent-written test file, and a policy that says otherwise trains people to route around it.

The questions to put on the postmortem template

• Which gate should have caught this failure, and was it missing, advisory, or bypassed?
• Would this change have merged if a human had typed it, identically? If yes, the finding is about process, full stop.
• Was review depth chosen by risk, or by queue pressure that day?
• Did the task given to the agent state the invariant that ended up broken?
• What would have limited the blast radius at deploy time, and does it exist now?

Teams that run this postmortem well come out with a stronger pipeline and, counterintuitively, more delegation, because trust in the gates is what makes delegation safe. The gates can also be built before an incident forces the question; that is where an agentic engineering engagement usually starts. The postmortem is just the most expensive way to schedule the same work.