Skip to content

Back to Blog

8 min read ·

Who signs the diff?

In March, the Financial Times reported that Amazon would make junior and mid-level engineers get a senior's sign-off on AI-assisted code changes. Amazon says that's false. I don't need to know who's right to see what the story got right: code got cheap to write, it stayed expensive to understand, and the bill lands on whoever signs.

I run coding agents every working day. They earn their place. I also read every diff they write before it merges, and that reading is now the slowest part of my day.


Here's what was reported. In early March, Amazon's retail site had four high-severity incidents in a single week, and one of them locked shoppers out of checkout, prices and account pages for about six hours, according to Fortune. Dave Treadwell, a senior vice president, wrote to staff that "the availability of the site and related infrastructure has not been good recently," in an email the FT obtained, as summarized by The Decoder. A briefing for Amazon's weekly operations meeting described a "trend of incidents" with a "high blast radius" and named "Gen-AI assisted changes" among the causes. The FT, which saw two versions of that document, says the AI line was deleted before the meeting. And junior and mid-level engineers would now need a senior engineer's approval on AI-assisted changes.

Amazon's own correction tells a smaller story. "Only one of the incidents involved AI-assisted tooling," and it came down to "an engineer following inaccurate advice that an AI tool inferred from an outdated internal wiki." None of the incidents involved AI-written code. As for reports of new approval requirements for engineers working with AI tools: "That is false."

Fine. Take Amazon at its word.

The one incident it admits to is still the whole problem in miniature. A tool read a stale page, produced a wrong answer, and a person acted on it. Nobody wrote bad code. Somebody accepted a bad answer.

And look at the fix everyone found believable. The FT's version wasn't a better model or a bigger test suite. It was a person who knows the system well enough to be blamed for it. Whether or not Amazon ever adopted that rule, every engineering lead who read the headline nodded along, because that's the fix they'd reach for too.

A signature is worth exactly what the signer understands.


A diff is the list of lines a change adds and removes. It's the thing a reviewer reads before clicking Approve. For most of software's history, writing a diff and reading one were the same kind of effort done by the same kind of person. The author understood the change because they'd sweated it out. The reviewer only had to check their work.

Agents broke that symmetry. A 600-line pull request, the bundle of changes a reviewer is asked to approve, now costs a prompt and a coffee. Understanding it costs what it always cost: somebody who knows why the retry loop is there, which table is shared with billing, and what happened the last time anyone touched that config flag.

I call the gap review debt: the difference between what a team merges and what it understands.

Like any debt, it's invisible until it's called. The pile grows quietly, and a team pays it down in senior hours or in incidents. There's also a way that feels like paying and isn't. Picture a Friday afternoon: an agent's 900-line refactor, a reshuffle that is supposed to change nothing, every test green, and a reviewer with four other pull requests waiting. "LGTM" (looks good to me) takes two seconds to type.

Nothing in that approval says anyone understood the change. The merge button only records that somebody let the code in.

lgtmagentin at machine speedunread diffsout at human speedsenior reviewmerged
One reviewer can't drain the pile as fast as the agent fills it, so the pressure finds the lane around them. Every diff that takes the LGTM lane lands in the merged branch unread, and that is review debt.

The productivity research found the same gap, between how fast the work felt and how fast it was. In July 2025, METR ran a randomized trial with 16 experienced open-source developers on 246 real issues. With AI tools they took 19% longer. They had expected a 24% speedup, and afterwards they still believed AI had sped them up by 20%.

In February, METR tried again with a new design. It now thinks developers are probably faster, but it calls its own new data "an unreliable signal," because 30% to 50% of developers said they were choosing not to submit some tasks they didn't want to do without AI. One of them put it plainly: "I avoid issues like AI can finish things in just 2 hours, but I have to spend 20 hours."

That developer knows what the 20 hours look like, because they've done them. That's exactly who you want signing an agent's diff. It's also exactly the experience an agent now saves the next person from getting.

Google's DORA team, which surveys engineering organizations every year, sees the same shape at company scale. Its 2025 report describes AI's primary role "as an amplifier, magnifying an organization's existing strengths and weaknesses." AI adoption is now linked to higher delivery throughput, says Google's write-up, while "the ongoing challenge remains of ensuring software works as intended before it's delivered to users."

Amplify a team where three people understand the checkout path, and you get more changes to the checkout path and the same three people.


Some mistakes never show up in a diff.

On March 31, a security researcher found that version 2.1.88 of Claude Code, Anthropic's coding agent, had shipped to the public npm registry with a source map inside, a debugging file that led anyone curious to the full, readable source. InfoQ notes that Claude Code uses the Bun runtime, "which generates source maps by default unless you explicitly disable them." Anthropic told CNBC it was "a release packaging issue caused by human error, not a security breach."

I'm not dunking on Anthropic. The point is the kind of mistake it was: a default that nobody turned off. A line nobody wrote never shows up in a diff. No reviewer spots an absence by reading what's on the screen.

You catch it because you once shipped something you shouldn't have, and now you check the file list before every publish without thinking about it. No model has that habit. You have it in your gut, as scar tissue.

Scar tissue comes from being a junior: shipping the thing that breaks, and sitting next to someone who's seen it before. Last August a Stanford team, working from payroll records at ADP, found a double-digit relative decline in employment for 22-to-25-year-olds in the most AI-exposed jobs, software developers among them, while experienced workers in the same jobs held steady or grew. The paper calls itself a canary, not proof of cause. The hiring side has its own post, so here's the short version. The industry wants a licensed driver in every passenger seat, and it's rationing learner's permits.

Demanding senior sign-off while you cut the junior class is freeloading. You're counting on some other company to spend years turning a graduate into the person who signs your diffs, so you can hire them away.


My own rules for agent code are boring.

If I can't explain a diff, I don't merge it. Not "it looks fine." Explain: what changed, why, and what else it touches. If I need the agent's help to explain it, the agent goes back to work and the diff waits.

Before an agent changes behavior I care about, I pin the current behavior with tests. Engineers call these characterization tests: they don't say what the code should do, only what it does today. Then "looks right" turns into "still does what it did," and a machine checks it instead of my Friday attention span.

Those two rules are what let me sign for agent code. They teach nobody which behavior is worth pinning. That takes years of being wrong near someone who can tell you so.

The best counterargument is that agents will soon review agents and pay down their own debt. Maybe. Somebody still has to decide which reviewer to trust, and sign for that.

Every system you gate on a senior's signature will need a senior in five years. How many juniors did you hire this year?