When AI builds itself

# Anthropic asked for a pause button. The number to focus on is 80%.

Anthropic published a piece this week, signed by Marina Favaro and Jack Clark, arguing that the industry needs a coordinated, verifiable way for frontier labs to slow down or stop together if AI development outruns alignment work. The argument is careful, the language is technical, and the headline most outlets are pulling is the pause itself. The headline I am pulling is the merge stat.

More than 80% of the code merged into Anthropic's production codebase is now written by Claude.

That is a single number, in one paragraph, from one lab. It will define this year of the conversation more than any other datum.

## Why this number matters more than the policy ask

I have been reading every framing of recursive self-improvement for two years. Most of them share one weakness: they treat the threshold as a future event. "When models can fully design their successors." "When training loops are autonomous." The framings are all in the future tense. The decision the framing implies is the decision we will make when we get there.

Anthropic's contribution is to put a present-tense number on the table. 80% is not the full thing. It is not autonomous training, it is not autonomous research, and the paper does not claim it is. But it is enough to start asking a sharper question: what fraction of the work that produces the next model is being done by the current one, and is that fraction monotonically increasing?

If yes, the pause argument is not about a future cliff. It is about a present ramp.

## The pause is not the headline either

The policy ask in the piece is a credible, verifiable coordination mechanism. Two things make it interesting.

First, it is not unilateral. The authors are explicit that a pause by one lab in one country is theatre. The only pause that does anything is one US and Chinese frontier labs commit to together, with verification that outsiders can run. That is a hard technical and political problem, and the piece does not pretend otherwise.

Second, it is not always on. The piece proposes the pause as a tool that should exist and be possible to deploy, not as a default state. That is a more useful contribution than another open letter. Tools that exist can be picked up. Open letters require people to agree first.

I am not endorsing the framework. I am noting that the framework moves the conversation from "should we pause" to "could we pause." Those are different questions, and the second one is the one engineers can work on.

## What I am doing with this in my own work

Three things.

One: pulling the merge stat for every team I advise. If you are not measuring what fraction of your shipped code was written by a model, start. The number itself is less interesting than its derivative. A team going from 30% to 50% in a quarter is making a different bet than a team that has been steady at 40% for a year. Both are valid. Neither is visible until you measure.

Two: re-reading our own approval gates. The eight-tier review structure I have written about before was designed for a world where humans wrote the code and models wrote drafts. If the ratio inverts, the gates have to move. The right place to put a human in the loop is upstream of the merge, not downstream. I had a draft post about this that I was going to ship next month. This piece moved it up.

Three: changing what I look for in a system card. Most cards still treat the model as a stationary artefact. If the model is being used to build its successor, the card has to disclose the loop, not just the model. I expect the better cards by year end will include a "delegated development" section, the way good security cards now include a supply chain section. The labs that get there first will set the norm.

## A small ask

If you run a frontier or near-frontier model and you have your own merge stat, send it. I am collecting them. Public or private, attributed or not. I would rather have ten data points than one.

If you write a system card, consider adding a delegated-development section in the next revision. Three paragraphs is enough. The number you put in it is the part that matters.

If you read the original piece, read it before you read the takes. I include myself in the takes.

https://www.anthropic.com/institute/recursive-self-improvement