Agents

Alex Wauters built a browser game. You get sixty seconds and a stream of simulated permission requests from a coding agent, and you approve or deny. Forty thousand runs later, across roughly 409,000 commands, the results are in and they are not flattering.

Players approved about a third of the malicious requests. Scope violations — the agent reaching for AWS credentials or Kubernetes config when it had no business there — were missed 35% of the time, the worst category. The single most-approved dangerous command was npm run analyze, waved through nearly 65% of the time, because it looks like something you have typed a thousand times and you cannot see what is in the script without going and looking.

The commands people caught reliably were the theatrical ones. rm -rf / gets denied. Of course it does. It looks like what it is.

The number that should worry you is not from the game at all. Wauters cites Anthropic's own telemetry: users approve around 93% of permission prompts. That is the whole problem in one figure. A control that is exercised 93% of the time in one direction is not a control, it is a formality with a keystroke attached. And the more prompts you see, the less each one means — which makes the safety mechanism degrade precisely as the thing it guards gets busier.

This is the sharpest evidence yet for something I keep going on about here. We have told ourselves that the human in the loop is the answer to agents doing alarming things. This measures what that human actually does, at speed, under volume, and the answer is: clicks yes. Not because anyone is careless — the conditions guarantee it. Time pressure, thin context, and no way to check what a script contains without stopping to read it, which is the one thing the workflow is designed to stop you doing.

A game is not a workplace, and forty thousand self-selected players are not a sample of professional practice. But it is pointing at the right thing, and the direction of the error is the one that costs you.

Two years of enforcing stacked pull requests capped at a few hundred lines, and Rootly has dropped the rule. Their reasoning, via CTO Quentin Rousseau and written up by Matt Saunders: agents now produce whole features, and splitting a coherent feature into artificial slices makes it harder to review, not easier.

The line worth keeping is this one:

AI bugs are context bugs. The code works, but it is applied to the wrong thing.

That is the most economical statement of the problem I have read this year. The small-PR rule was never really about size. It was a proxy for reviewability, and it worked because a human writing three hundred lines had to understand them first. Take away that guarantee and the proxy stops measuring anything. You can read every line of a four-hundred-line diff, find nothing wrong with any of them, and still miss that the whole thing is solving a problem the system does not have.

So Rootly replaced size with blast radius: feature flags, progressive rollout, and the ability to undo. They also built an internal reviewer that assesses risk profile and conformance to standards rather than reading the diff the way you would read a colleague's.

I am half-convinced. Moving the safety boundary from review-time to runtime is a genuine answer to a real change, and "can we turn it off quickly" is a better question than "is it under three hundred lines". But it is also a quiet concession that the diff is no longer where the defect lives, and rollback only helps for failures loud enough to notice. The context bugs Rousseau is describing are frequently the quiet kind — right code, wrong assumption, no alarm.

Still: a team saying out loud that a practice they enforced for two years has stopped working is worth more than another vendor post about velocity.

Jo Kelly-Fenton and Aleksandar Mitic at QCon London on Honk, the agent Spotify built to do fleet-wide migrations across thousands of codebases.

The numbers are the kind that make executives forward the slide deck. A migration that reached 70% adoption in nearly a year, with the last 30% never finishing — the long tail everyone has and nobody talks about. With fleet tooling, under a week. With Honk reachable from Slack, they went from a thousand merged pull requests in three months to the same volume in ten days.

Take that seriously. This is the strongest case for coding agents I have seen presented with real figures attached: not novel feature work, but the enormous volume of unglamorous maintenance that never gets done because no one can justify a quarter of dependency bumps. That work is real, it is expensive to neglect, and it is close to ideal for an agent — mechanical, verifiable, and boring enough that no one's craft is offended.

Then, in the lessons, this:

PR review is now the bottleneck, not code generation.

They moved it. They know they moved it. They are up front that standardisation was the biggest lever, that summarising build failures with a model beat parsing output, and — the detail I respect most — that skipping integration tests early on left validation gaps.

A thousand pull requests in ten days is a triumph of generation and a verification bill someone is paying. Spotify have the monorepo, the golden standards and the CI to absorb it, which is exactly DORA's point about AI amplifying whatever system it lands in. Run Honk against an estate without those and you would not get ten days of migrations. You would get a thousand pull requests nobody can review, which is what open source maintainers have been describing all year, only with a budget behind it.

Worth watching in full if you are anywhere near a large migration.

Hanqing Zhao and the Systems Software & Security Lab at Georgia Tech have been running a project called Vibe Security Radar since May 2025: take public vulnerability advisories, trace the fix backwards to the commit that introduced the bug, and check whether an AI coding tool left fingerprints on it.

The trend line is the story. Six CVEs attributed to AI-generated code in January 2026, fifteen in February, thirty-five in March. Seventy-four confirmed cases in total across roughly fifty tools tracked. The researchers reckon the real number is five to ten times what they can detect — four to seven hundred across open source — because most AI-written code does not announce itself.

One finding needs handling with care, and the coverage mostly did not handle it carefully. Claude Code accounts for the largest share of attributed flaws, and the researchers say that is partly because it leaves identifiable signatures. That is a detection artefact, not a quality ranking. A tool that stamps its commits is a tool you can measure; a tool that does not is a tool that vanishes from your dataset. If you take that chart as a league table of which assistant writes the least safe code, you have read it exactly backwards — you are looking at a map of which vendors are legible to researchers.

The genuinely alarming number is buried in the middle: Claude Code alone touched more than four percent of public GitHub commits last month. Whatever the per-commit defect rate turns out to be, it is now multiplied by a denominator that did not exist two years ago.

Methodology this transparent is rare in this corner of the discourse. Most "AI code is insecure" statistics you will see quoted this year come from vendors selling scanners. This one comes from a lab publishing its method, and it is correspondingly less dramatic and more useful.

This is from February and I keep coming back to it, because the quotes have aged better than the proposals have. GitHub PM Camilla Moraes opened a community discussion on maintainers "dedicating substantial time to reviewing contributions that do not meet project quality standards" — the options on the table included letting maintainers disable pull requests outright, restrict them to collaborators, delete them from the interface, and attach some kind of attribution when a tool wrote the code.

The line worth stealing is Jiaxiao Zhou's:

Review trust model is broken: reviewers can no longer assume authors understand or wrote the code they submit.

That is the actual problem, stated in one sentence, and it is not a spam problem. Code review has always run on an unwritten assumption: whatever else is wrong with this patch, there is a human on the other end who can explain it. Take that away and review stops being a conversation and becomes an inspection. The economics get ugly fast, because inspection does not compress the way conversation does.

Xavier Portilla Edo's estimate — "1 out of 10 PRs created with AI is legitimate" — is the kind of number I would normally push back on, since it is one maintainer's gut feel rather than a measurement. But nobody in that thread disputed the order of magnitude, and the people in that thread do this all day.

GitHub's own Matthew Isabel pushed back on counting AI-generated PRs at all: "A bad or off-topic PR is a bad PR, regardless of where it came from." He is right in principle and wrong in practice. Provenance was never worth tracking when writing a bad patch cost the sender an afternoon. It is worth tracking now that it costs them ninety seconds, because the cost asymmetry between sender and reviewer is the whole ballgame.