All posts

The Engineer's Job With Coding Agents Is Saying No

Anthropic's Scion team says Claude writes better code than they do. Their job became saying no and reviewing intent. How to make that work outside a lab.

Misha Druzhinin
Diagram of an agent proposing changes and an engineer applying three kinds of no: system constraints, reviewer trust model, and change intent, before code merges.

On October 13, 2026, Anthropic published Redesigning source control at Anthropic. The headline is that Anthropic moved its monorepo off git to an in-house system called Scion. The more useful part for most teams is the section titled “What we learned building Scion.” It describes how seven engineers worked while Claude wrote much of the code.

Every engineer on that team now rates Claude as better at writing code than they are. Yet the team says it still needed them, often for one job: telling Claude “no.” Our read is that this is where software teams are heading. Frontier labs get there first because they have early model access and few token limits. The rest of us can copy the habits now, without copying the infrastructure.

Key Takeaways

  • A seven-person Anthropic team built Scion, a code review tool, and about six related systems in five months, with Claude writing much of the code.
  • The engineers’ main contribution was design judgment: saying no when Claude broke system constraints or over-engineered in response to adversarial review.
  • The team still reviews every change, but reads the intent of the change rather than every line.
  • Our read: intent review works there because the codebase also has heavy verification, including hermetic simulations, fuzzing, and rate limiting.
  • To copy this, turn your senior engineers’ “no” into checks, reviewer instructions, and intent statements that agents and CI can see.

What Anthropic built, briefly

By September 2026, Anthropic was merging more than 30,000 changes a day into a monorepo whose main-branch history is almost 100 GB. Git’s model, where every clone is a full offline repository, stopped scaling. Scion keeps the repository on the server, gives agents and CI jobs thin always-online clients, and answers history questions through an API. Google described similar monorepo pressure for its Piper system back in 2016, and Anthropic credits Piper and Meta’s Sapling as prior art. Anthropic says Scion is not a general git replacement, so we’ll leave the architecture there.

Why the engineers still mattered

The interesting claim is about people, not storage. Anthropic writes that seven people built Scion and Antique, the new code review tool, plus “half a dozen related systems.” They finished the migration in five months while daily merge volume grew 10x. In the past, the post says, a project like this would have taken years and many more engineers.

Then comes the line most teams should read twice. The team writes that “very often” the engineers’ role “was to tell Claude ‘no.’” The engineers supplied what the model lacked: an understanding of how the systems fit together, and judgment about design trade-offs at the scale they needed.

That isn’t a romantic defense of human coding. Coding skill stopped being the scarce input. Knowing which constraints matter, and which concerns are imaginary, did not.

The two kinds of no

The Anthropic post gives two examples. They describe different failure modes, and they need different fixes.

Where an engineer's no should live An agent's proposed change passes three checkpoints before merge. First, system constraints encoded as checks catch changes that break architecture rules. Second, a reviewer trust model filters adversarial review findings that guard against hypothetical risks. Third, an intent statement lets a human approve what the change is for. Approved changes merge. Where an engineer's "no" should live Agent proposes change 1. Constraints architecture rules as tests and lints 2. Trust model what reviewers may assume 3. Intent human approves the purpose Blocks: reading the commit log instead of asking the review tool Blocks: extra validation against a trusted internal service Blocks: a correct change that solves the wrong problem Backed by verification: simulations, fuzzing, CI
Our framing of the two failure modes Anthropic describes, plus intent review. Examples from Anthropic, "Redesigning source control at Anthropic," October 2026.

No to breaking system constraints

The first failure is an agent satisfying a local pattern while breaking a global rule. Anthropic says agents “will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place.” This happened often during the migration.

Their example is specific. Several systems tried to find when a change merged to main by reading the commit log linearly. The right answer was to ask the code review tool. A linear scan works fine in a test. At 30,000 merges a day, it becomes a bottleneck.

Our read: the agent wasn’t careless. The constraint probably lived in engineers’ heads, and the existing code showed a pattern that should never have been allowed. Agents copy what the codebase shows them. If the codebase contains a bad pattern, the agent will spread it.

The fix is to make the constraint visible to the agent and enforceable by CI. A senior engineer saying no in review works once. A check says no every time. An illustrative rule: “the merge time of a change comes from the review service, never from history.” Turn it into an architecture test that fails on direct log scans. Put the rule and its reason in your agent context files as well.

No to over-engineering from adversarial review

The second failure comes from a practice that mostly works. Anthropic makes extensive use of adversarial review. The team calls it “incredibly effective in many ways” but also “myopic.”

The example: one review was overly defensive about trusting another internal service. Claude responded by adding excessive validation and complexity. Skilled engineers had to steer it away from hardening the system against hypothetical concerns.

We think this failure is structural. When the reviewer is an agent, it is rewarded for finding problems, and a hypothetical risk costs nothing to raise. If the author agent fixes every finding by default, each round adds defensive code. Nobody is there to say “we trust that service, by design.” The system grows harder to read without becoming safer. We’ve written about a related pattern in why complexity is easy and reliability takes design.

The fix is to give reviewers the trust model the engineers carry in their heads. Write down which services are trusted and which inputs are already validated upstream. Require every finding to name a concrete failure scenario. A finding with no plausible scenario gets dropped, not fixed. Capping review rounds helps too, as we covered in reviewing AI-written code by risk.

What intent review looks like for agent changes

Anthropic’s team still reviews every change request to Scion. But they “now examine the intent of the change as opposed to reading every line of code.” This is the shift most engineering leaders will need to plan for.

Intent review asks different questions than line review:

Line review asks Intent review asks
Is this loop correct? Is this the change we wanted?
Is this variable named well? Which system constraints does it touch?
Did the author handle this edge case? What did the author choose not to do, and why?
Does this match our style? What evidence shows it works?

Intent review only works if the agent states its intent. Most pull request templates ask for a summary and a test plan. For agent-written changes, ask for four things instead:

  1. The goal, in one sentence.
  2. The constraints the change touches.
  3. What was deliberately left out, and why.
  4. A link to the evidence that it works.

There’s an important condition here. Our read is that this only works because Anthropic also invested heavily in verification. The team calls Scion “among the most well-tested and well-defended codebases” it has worked on. It built hermetic simulations of every non-trivial infrastructure and source control interaction it has ever encountered, plus fuzzing and rate limiting. Claude wrote much of that too.

Without that verification, intent review is a rubber stamp with better prose. If your test suite can’t catch a broken merge path, a human reading “this change refactors merge lookups” learns nothing. Build the verification before you stop reading lines. Our guide to designing evals for AI agents covers the same idea for agent behavior.

Why labs see this first

Anthropic is explicit that its situation is unusual. It uses Claude to write software more than almost any company. It also says its ability to spend tokens internally “far exceeds what any other business would realistically want to spend.”

Model access matters as much as budget. The team started Scion around the time Claude Mythos Preview and Claude Tag became available internally. They had largely handwritten the first git-to-Scion ingestion pipeline. An early Mythos Preview snapshot rewrote it with no further instructions. Anthropic reports the result used 20x less memory and ran 4x faster, with ordering invariants preserved. That’s Anthropic’s own measurement, not an independent benchmark.

So the lab is a preview, not a template. Anthropic expects this class of problem to become more commonplace within six to 12 months. We agree on the direction, though most teams will feel it in review and CI before source control.

The team also changed operations. Claude “superfans” in Slack each watch one component’s health. And the team couldn’t make a global merge-queue lock work at its merge rate, so it relies on post-merge and pre-deploy testing instead. Both depend on cheap tokens and fast fixes, so treat them as later steps.

When this is the wrong model

Saying no well requires someone who knows what to say no to. Anthropic’s seven engineers built source control at scale with deep knowledge of the surrounding systems. A team without that knowledge can’t review intent, because it can’t judge whether the intent is sound.

That changes the hiring and staffing question. Fewer people can ship more, but those people need system-level judgment. Juniors who only ever review agent output may never build it. Plan deliberate ways for them to learn the constraints, such as owning the architecture tests.

Also, don’t remove line review where verification is thin. Security-sensitive paths, data migrations, and billing logic still deserve line-level attention until your checks prove otherwise. Anthropic’s review tooling distinguishes comment-only changes from sensitive logic changes, so humans can focus on the most consequential ones. For deciding which paths keep line review, see our guide to reviewing AI-written code by risk.

Frequently Asked Questions

Did Anthropic replace git?

Inside its own monorepo, yes. Anthropic migrated to Scion, an in-house system, in five months. It says Scion isn’t suitable as a general git replacement. It suggests git servers and forges could adopt server-side APIs and better partial-checkout protocols instead.

What does reviewing intent instead of code mean?

The reviewer checks whether a change does the right thing for the system, not whether each line is correct. That means its goal, the constraints it touches, what it left out, and the evidence that it works. Automated tests and simulations carry the line-level correctness burden.

Why does adversarial review lead to over-engineering?

We think reviewer agents are rewarded for raising concerns, and hypothetical risks are cheap to raise. Author agents that fix every finding by default add code each round. Without a trust model, each round adds validation and defensive code against risks the system design already rules out.

The bottom line

Anthropic’s Scion story is about infrastructure, but its most portable lesson is about roles. Claude wrote much of the code. Engineers supplied constraints, trust boundaries, and judgment about intent. Very often, they exercised that judgment by saying no.

One thing to do this week: ask your two most senior engineers to list the five things they most often reject in agent pull requests. Turn each rejection into a check, a line in your reviewer prompt, or an item in your intent template. Then count how many of those rejections still reach a human a month later.

If agents already write most of your code and review is where it piles up, our AI cleanup work starts there.

Sources