AI-generated code velocity mismatch creating high blast radius production incidents, and why review burden should increase not decrease with AI assistance
The Blast Radius Problem Nobody Wants to Talk About
Amazon is holding mandatory meetings. The internal briefing describes a trend of production incidents caused by “Gen-AI assisted changes” with what it calls “high blast radius.” And buried in that same briefing is a phrase that should make every engineering leader sit up straight: “best practices and safeguards are not yet established.”
That last sentence is the most honest thing I’ve seen a major tech company say about AI tooling in months. Most orgs skip that part entirely.
The Velocity Trap
Here is what I watch happening on teams right now. Engineers adopt AI coding assistants fast, often faster than any review process adapts to them. The AI writes confident, fluent code. It looks right. It compiles. Tests pass. The engineer, now operating at a pace they weren’t operating at six months ago, approves the PR with less scrutiny than they would have given their own handwritten work.
The merge goes through. Something breaks at scale. Users hit it. Alerts fire.
This is not a model quality problem. The model did exactly what it was asked to do. The problem is that velocity and scrutiny decoupled, and nobody noticed until the incident.
Why AI Code Is Specifically Dangerous at Review
Human-written code carries implicit signals. You can see the author’s reasoning in how they structured a function, what they chose to comment, where they left a TODO. You can ask them why they made a choice and get a real answer.
AI-generated code is optimized to look correct. It matches patterns from training data. It is grammatically right and stylistically clean. But it does not carry intent. The engineer who hits “accept” becomes the de facto author, responsible for intent they may not have fully examined.
The blast radius expands because AI lets you move fast across a wide surface. One session can produce hundreds of lines touching authentication, data access, and network configuration simultaneously. A human writing that same code over three days would naturally pause, second-guess, maybe talk to a teammate. The AI produces it in four minutes and asks if you want it refactored.
🔥 What the Amazon Situation Actually Signals
The fact that Amazon, with the engineering depth it has, is running mandatory briefings because its own teams generated high-blast-radius incidents from AI-assisted changes should land hard. This is not a startup that moved fast and broke things. This is an organization with formal change management, extensive on-call culture, and institutional memory about production risk.
If the safeguards are “not yet established” there, they are certainly not established at the median engineering org.
Claude just shipped a code review feature where it dispatches agents to hunt for bugs when a PR opens (https://x.com/claudeai/status/2031088171262554195). That is a useful tool. I am not dismissing it. But automated review catching bugs is a different problem from humans understanding what they are shipping and why. Those are not the same thing, and conflating them makes the blast radius problem worse, not better.
The Review Burden Should Go Up
The counterintuitive take, and the one I think is correct, is that AI assistance should increase review burden, not reduce it.
More code produced per unit time means more surface area to review. More confident-looking code means reviewers need to slow down rather than trust the fluency. More engineers operating near the edge of their own understanding means more need for a second set of eyes that genuinely interrogates the change.
The correct response to AI-assisted development is not to reduce PR friction because the AI already checked it. It is to treat every AI-assisted PR as carrying an invisible label that says “author may not fully understand all of this.”
That is not an insult to engineers. It is just true, and honoring it is what keeps blast radius small.
What I’d Actually Do
Require explicit annotation of AI-assisted changes in PRs so reviewers know to apply extra scrutiny. Invest in production blast radius estimation before merge, not just test coverage. Run tabletop exercises specifically around AI-generated code failures so teams have muscle memory before an incident happens.
And stop treating AI tooling adoption as purely a velocity story. Velocity is only valuable if the thing you shipped doesn’t take down a critical path at 2am on a Saturday.
The tools are moving fast. The practices need to catch up, and that catching up is not automatic.
Sources & Further Reading
#AIEngineering #SoftwareEngineering #DevOps #AIRisk #CodeReview #ProductionEngineering
