When AI writes the code, who checks that it works?

At Anthropic, artificial intelligence now writes about 90 percent of the code for Claude Code. That has forced the company to rethink how software is built and quality-checked. Its answer is a system where AI agents check other AI agents, while people focus on the decisions that really need human judgment.

On October 15, 2026, Anthropic published an article in which Addy Osmani, Morgan Westlee Lunt and Qing Wang from the Claude Code team explain how they have changed the way they review and quality-check code.

The background is simple. AI agents such as Claude Code, OpenAI Codex and Cursor can now write, change and test software in a fraction of the time it used to take a developer. That creates a new problem. When AI produces code faster than people can check it, how do you make sure the result actually works?

Anthropic has chosen to automate large parts of the checking as well.

According to the company, the number of code changes merged into Claude Code more than doubled from June to September 2026. At the same time, the share of changes that later had to be rolled back fell by more than 40 percent.

The numbers are reported by Anthropic itself and show the trend in its own team. On their own, they don't show how much of the improvement comes from the new review process. Still, the company's account gives a concrete look at how software development is changing.

From checking code to checking results

Traditionally, software development has been organized around people who write and check code.

A developer writes a new feature or fixes a bug. Then a colleague goes through the changes, looks for problems and suggests improvements. Only when that check is done does the change become part of the program.

This process is called code review.

When AI agents write large parts of the code, this way of working gets harder to keep up. A developer can set several agents to work at the same time, and each agent can produce substantial code changes in a short time.

The number of changes can then grow much faster than the capacity of the people who have to check them.

So Anthropic thinks you have to change the question itself.

The most important thing is no longer whether a person has read every single line of code. The most important thing is which errors can occur, how they can be found, and which checks are best suited to finding them.

Some problems are best caught by automated tests. Others need a security review, while some decisions still have to be made by people.

The AI agent has to prove the job was done right

One of the most important changes at Anthropic happens before the code change is even sent on for review.

When Claude has finished a task, it isn't enough to report that the job is done. The agent has to run relevant tests and show the results.

Imagine that an AI agent is asked to improve the photo gallery on a website.

It can write new code that changes how the photos are shown, but that doesn't necessarily mean the solution works. The photos may look right on a large screen but overlap each other on a phone. A change can also affect other parts of the website.

Instead of trusting the agent's own judgment, the system can require it to open the website, test different screen sizes and document the result with screenshots and test logs.

This is the difference between an AI agent saying that something works and showing evidence that it works.

Anthropic also has a separate AI agent review the code change with what it calls fresh context, meaning without the full conversation history of the agent that wrote the code.

The idea is that an independent agent can more easily spot problems the original agent has missed.

Several AI agents check each other's findings

When a code change is ready, a pull request is usually created, often shortened to PR.

A PR is a proposal to add new or changed code to the main version of a program. Before the change is approved, it can be reviewed and tested without affecting the existing version.

At Anthropic, every PR is checked by AI before a person may look at it.

What's special is that the company doesn't use just one review agent. Several AI agents examine the change in parallel to find possible errors. Then a separate group of agents assesses the findings and decides which ones are well founded enough to be reported.

So if one agent thinks it has found a problem, that doesn't automatically mean the code has to change. Other agents first check whether the problem really exists.

This is needed because AI agents can be wrong too. For example, they can report problems that don't exist.

Such mistaken alerts are called false positives, or false alarms.

So Anthropic tries to remove unnecessary alerts before they reach the developer. The goal is for people to spend their time on real problems instead of looking into large numbers of mistaken warnings.

Errors that were already in the code before, on the other hand, are real errors. They are marked separately, so they aren't pinned on the person who made the change.

When the company introduced this kind of AI code review internally, the share of PRs that got substantive comments rose from 16 to 54 percent. That shows the system flagged more issues that deserved attention, but not necessarily that every comment was an error that would have hit users.

Security and automated tests are separate layers of checks

The AI code review is only one part of the system.

Anthropic also has its own security checks that examine whether the changes introduce vulnerabilities. That could be, for example, flaws in access control, exposure of sensitive information or other security problems.

On top of that, traditional automated tests check that the program still works.

These tests can check whether the code has technical errors, whether different components work together, and whether the change has broken existing features.

It's important to keep the different checks apart.

A website can work perfectly well for the user and still have a serious security hole. A program can also be technically correct and secure but behave differently than the user expects.

That's why no single test or single review agent is enough.

At Anthropic, findings from both the code review and the security check have to be handled before a change can be approved. The problems either have to be fixed or closed with a reason if they turn out to be mistaken.

How many people have to approve the change?

Anthropic has also changed the rules for human approval.

In the past, it was common for one or more developers to have to approve code changes regardless of how big or small they were.

Now the company assesses changes by risk.

An automated assessment sets the risk level based on what has actually changed. Some especially sensitive parts of the system always require human review, and the simplest approval rules apply only to trusted developers.

That means a simple text change can go through the whole process without manual approval, while changes to billing, sign-in and the update system always need a person.

There is also a clear limit. An AI agent's approval never counts as a human approval when the system requires a person to make the decision.

In this way, Anthropic tries to spend human time where the risk is greatest, instead of treating all code changes the same.

When the AI agents started checking each other in an endless loop

One of the most interesting experiences Anthropic describes is what happened when it let AI agents review and fix code over and over.

In one case, a code change went through more than 50 rounds of review and fixes in a single night before the person behind the change stopped it.

A review agent found a problem. The coding agent made a change. The review agent looked at the code again and found yet another problem. And so the process went on.

When the engineers looked into what had happened, they found that about 59 percent of the code that kept being flagged had already been there during the first review round.

So the review agent rarely found new errors. It found a few more of the old errors in each round.

This illustrates a challenge with autonomous AI systems. The agents can keep carrying out tasks and using resources without getting closer to a finished result.

So Anthropic introduced clearer stopping rules.

After three review rounds, the review agent asks the one who wrote the code to step back and rethink the approach. Later reviews are limited more to new changes, and the system is not supposed to report the same problems again.

It shows that more automation doesn't necessarily mean better results. The agents need clear goals, limits and rules for when a task should stop or be reconsidered.

Even approved code can contain errors

No review system is flawless, not even when several AI agents go through each other's code.

That's why Anthropic puts a lot of weight on being able to find problems quickly and roll back the changes that cause them.

Before a change becomes part of the main version, the system also runs tests that check that it works together with other new changes.

That matters because two code changes can each work on their own but cause problems when they are combined.

The company also uses what are called feature flags. A feature flag is a switch inside the program. The new feature is finished and sits in the code, but nobody sees it until someone turns the switch on. If it does harm, it can be turned off again at once, without the team having to build a new version of the program.

New features are often available to employees first, before they are gradually rolled out to more users.

If something still goes wrong, it should be easy to go back to an earlier working version. This is called a rollback.

The idea isn't to eliminate every chance of error, which is hardly realistic. The goal is to reduce the likelihood of errors, catch them early and limit the consequences when they happen.

The errors are also used to improve the review agents

Anthropic uses past problems as a basis for improving the AI review itself.

When a code change leads to an error, the company can keep information about what went wrong, why the review system didn't catch the problem, and how the error was fixed.

These examples then become part of a test set used to assess the review agents.

In AI development, such systematic tests are often called evaluations, or evals.

If a review agent is updated with new instructions, tools or a new AI model, it can be tested against previously known errors. That lets the developers check whether the new version actually finds more real problems, or just produces more alerts.

That's an important difference.

A system that reports many possible errors isn't necessarily better than one that reports fewer. What matters is how well it finds real problems without creating unnecessary extra work.

What should people do when AI takes over so much of the checking?

Anthropic stresses that people still have a central role. But the role is changing.

When AI can both write and check large amounts of code, it makes less sense to spend human capacity on reviewing every detail.

Instead, the engineers focus on judging which features should be built, reviewing risky code and architecture that others will copy, and taking responsibility for the result.

They also have to understand what the tests actually document, and what they haven't checked.

Another interesting point is how the developers keep track of ever larger codebases.

Anthropic writes that no one on the team has a full picture of all of Claude Code in their head, and that no one needs to. When an engineer needs to understand a specific part of the system, Claude can examine the relevant code and explain how it works.

Some also use AI to build small visualizations that show and explain how a specific part of the code works.

In this way, AI is used not just to write code but also to help developers understand the software they are responsible for.

Still, there is a big difference between getting an explanation from AI and having verified that the explanation is correct. People still have to be able to assess documentation, spot weaknesses and take responsibility for the consequences of the changes.

A new way to organize software development

What Anthropic describes is more than a new method for checking code.

It shows how software development can be organized when AI agents take over more and more of the practical tasks.

One agent can be put in charge of building a feature. Other agents can review the result, find errors and examine security. Automated tests can check that the program works, while an overarching system decides which tasks have to go back to the agents and which need human approval.

People then move from necessarily doing all the tasks themselves toward defining the goals, setting the review rules, assessing the risk and taking responsibility for the result.

This isn't limited to Anthropic or Claude Code. The same principles can be used in development processes with other AI coding agents, provided the necessary tools, tests and safety mechanisms are in place.

Nor does it mean that everyone should automate the whole process. More agents mean more coordination, more resource use and new ways for things to go wrong. How much should be automated depends on the size, complexity and risk of the project.

So what's interesting about Anthropic's approach isn't just that AI writes about 90 percent of the code for Claude Code.

It's that the company has started to organize quality assurance around the same technology.

When AI agents can produce large amounts of code, the ability to check, document and take responsibility for the results becomes at least as important as the ability to write the code.

That may become one of the most important changes in how software is built in the years ahead.

Key takeaways

• At Anthropic, AI writes about 90 percent of the code for Claude Code, and AI agents also check much of the code before a person may look at it.
• The AI agent that wrote the code has to show test results, and several review agents assess each other's findings before they are reported.
• How many people have to approve a change depends on the risk, and an AI agent's approval never counts as a human approval.
• The agents need clear stopping rules, and tests, switches that can turn off a new feature (feature flags) and the ability to roll back changes limit the consequences when errors get through.
• People judge which features should be built, review risky code and take responsibility for the result.
• The numbers are Anthropic's own and don't show, on their own, how much of the improvement comes from the new review process.

Sources and further reading