Anthropic warns AI could start improving itself, developers react

Anthropic published a post on June 4 about recursive self-improvement, the idea that AI systems could eventually help design and build their own successors.

This can sound like science fiction. And Anthropic is careful not to claim that this is happening today in its full form. But the post still has a practical point for developers: Claude is already doing a lot of the work inside Anthropic's own engineering and research process.

Anthropic said

As of May 2026, more than 80% of the code merged into Anthropic's codebase was authored by Claude.

They also mentioned

The typical Anthropic engineer was merging about 8x as much code per day in the second quarter of 2026 as they were in 2024.

Reuters covered the post as a warning about what AI labs may need to do if systems start improving faster than people can safely manage. That is the big policy question. For developers, the smaller question is easier to feel: what happens when AI is no longer just helping write code, but also helping build the next AI system?

Claude authors 80% of Anthropic's code, but that is not the whole story

You should not read this as “Claude replaced Anthropic engineers.” Anthropic is not saying that. Humans still decide what should be built, set the goal, check the output, and review what gets merged. The post also says that lines of code are an imperfect measure. More code does not automatically mean better code.

Still, it would be too easy to wave the number away. Anthropic says Claude is writing and editing entire files, running code, debugging failures, and taking on longer tasks. It also says the length of tasks AI systems can handle on their own has been doubling roughly every four months.

So the useful reading is not that engineers disappear. It is that the job starts moving. Less time goes into getting a first version on the screen. More time goes into review, taste, tests, and deciding whether the generated work should exist in the first place.

Faster coding loops are already changing AI research

Recursive self-improvement usually brings up a very dramatic picture. An AI gets better, then uses that improvement to build its next, more powerful version, and the cycle keeps going. That is not exactly what Anthropic is saying has happened.

The version in the post is more normal, almost annoyingly normal. Claude helps write code. It helps clean up files. It also runs experiments, reviews changes, and helps debug things that fail. A researcher or engineer is still deciding what matters.

This is not minor. A lot of software work is just repeated loops. You change something, run it, and read the result. If it broke something, you fix it and do it again. AI research has its own version of the same loop.

If Claude can make those loops faster, the lab moves faster. That can happen well before an AI system is able to run the whole process by itself.

Developers are asking who reviews all this AI-written code

The post reached the front page of Hacker News, where the discussion quickly moved past the headline phrase. Some people focused on the 80% coding claim. Others were not convinced that this should be called recursive self-improvement yet.

If you have used coding agents on real code, you may agree with some of the reactions in the comments. Agents can generate patches much faster than a person can comfortably review them. The patch count goes up, but someone still has to review those patches.

Anthropic's own post points to the same problem. If human review becomes the bottleneck, teams have only a few choices. Slow down, automate parts of the review, or accept more risk. None of those choices are simple when the code being changed belongs to a frontier AI lab.

This is where the safety question becomes more concrete. If AI systems help build AI systems, the checks cannot wait until release time. They should show up in code review, experiment selection, infrastructure access, evaluation design, and pause decisions.

Anthropic says recursive self-improvement is not inevitable. But its own numbers show that a limited version of the feedback loop is already here.

For developers using AI coding tools, this is the part worth watching. Faster code is nice. Faster review is harder. We made a similar point in our earlier article on why AI-native development is changing the two-week sprint: when implementation gets cheaper, clarity, validation, and review become the real constraint. If the review process does not improve, the bottleneck just moves somewhere else.