Code Without a Signature

Code Without a Signature

If the era of “move fast and break things” had an official ending, it might have been the moment Amazon called a mandatory engineering meeting after a series of outages that took down its retail site and app. Including a six-hour crash that left millions of users unable to see prices, unable to check out, and unable to access their accounts.

In the internal briefing, the incidents were described as having a “high blast radius" and were linked to “Gen-AI assisted changes”. This story isn’t only about Amazon. It’s about every organization that has started integrating AI coding tools into the software development flow without first building the system around them. The problem isn’t AI. It’s the metrics.

When the KPI is “usage,” the outcome gets lost

Amazon set a target of 80% daily usage for AI coding tools among its engineers — at the same time as layoffs of 16,000 employees in January and $200 billion in capex for this year. The equation is simple: fewer engineers, more AI-generated code, faster deployment.

The problem is that the “usage” metric doesn’t measure outcomes. It measures participation. And that distinction is costly when the organization rewards tool usage instead of the quality of the outcome.

When the goal is “use the tool” and not “build something that works”, the engineer has no incentive to question the output. They have an incentive to ship it. That’s exactly what current and former Amazon engineers describe on Reddit: delivery mattered most, not functionality.

• The KPI focuses on compliance (usage) rather than reliability (outcomes).
• Review becomes procedural rather than substantive when speed is the priority.
• In incidents, accountability shifts to the tool instead of returning to engineering judgment and process.

Someone mentioned engineers using AI tools to fight other AI tools in a “proxy war of blame” during on-call incidents. It sounds absurd. It isn’t.

The verbose code problem — and why we don’t talk about it enough

There’s also a more technical, less discussed problem with AI coding tools. The code produced by LLMs tends to be significantly more verbose than it needs to be. It works — until it doesn’t.

And when something goes wrong, the person who has to read the code is faced with a codebase that doesn’t resemble anything familiar. It doesn’t follow the conventions of an established project, it doesn’t have the fingerprint of a senior developer, and it wasn’t written by anyone who can explain why they made those choices. Documentation often becomes “AI output of AI output.”

The response: safeguards, sign-off, and yet another outage

Amazon reacted quickly: Senior VP Dave Treadwell acknowledged that the “best practices and safeguards” around AI coding tools have not yet been fully defined. Junior and mid-level engineers now need senior sign-off for any change involving AI-assisted code.

At the same time, AWS suffered a separate 13-hour outage in December after its own AI tool, Kiro, deleted and recreated an entire coding environment. The message is clear: automation without proper guardrails doesn’t “accelerate” — it shifts risk to a larger scale.

Tool or system? The question we avoid

As The Primeagen and AI researcher Demetri Spanos pointed out, the models are smart — but not as smart as we treat them when we put them into production without guardrails. The tool is not a strategy. It’s a component.

Progress since December 2025 didn’t come from improving the raw models. It came from the maturation of agent loops and the team workflows around them. The AI coding tool alone isn’t enough — it needs the system around it.

1. Clear outcomes instead of “usage”: reliability, latency, incident rate, change failure rate.
2. Review culture that evaluates intent, trade-offs, and compatibility with conventions.
3. Guardrails in CI/CD: tests, policy checks, staged rollouts, observability.
4. Ownership: a human signs off on the choices and can explain them.

What this means for us

Amazon will find its solution. It has the resources, the engineers, and now the political will to do it. But this story is about every organization that measures “how many times AI was used” instead of “what got better because we used it.”

The speed you gain from AI coding tools means nothing if you can’t trust the outcome. And trust isn’t built with usage dashboards. It’s built with processes, review culture, and an understanding that AI is a multiplier — not a replacement for judgment.