The Fast and the Furious guide to agent-scale delivery

TL;DR

• Anthropic went from 2,500 merges a day to over 30,000 in four months, because Claude now writes most of their code.
• Git could not keep up, so they built their own version control system, called Scion. That is the fun part, and it is the least important part.
• They gave up on testing every change before it merges. Safety now happens after the merge, at runtime, and the thing that makes this work is feature flags.
• You do not need Scion, but you do need an off switch that works after the code is live.

I live my life one merge at a time

When The Fast and the Furious first came out in 2001, it was about street racers stealing DVD players. By film nine, a car is in orbit. Nobody stopped to check the physics. If that sounds familiar, it should. It is exactly what has happened to software delivery over the last few months.

If you have never seen a Fast and Furious film, here is everything you need to know:

• A crew of street racers gradually becomes a government-sponsored special forces unit, for reasons nobody questions.
• Physics, as established, is optional.
• Nobody who dies stays dead.
• Every problem is solved by driving faster.
• Every film ends with a barbecue.

That is the whole franchise. And we don’t mean to be alarmist, but hand your codebase to coding agents and every line of that list becomes a description of your delivery pipeline: the scope keeps growing, the old limits stop applying, nothing that should be dead gets removed, and the answer to every problem is to go faster. The barbecue is the one you have to earn.

Anthropic published a post this month that reads eerily like another Fast and Furious script. In May 2026 they merged about 2,500 code changes a day. By September it was over 30,000. The team did not grow. Claude now writes most of their code, on a questionable token budget, and as they put it, every bottleneck they remove immediately leads to more code. The demand for merging is practically infinite.

Dom Toretto famously lives his life a quarter mile at a time. A coding agent lives its life one merge at a time, and it does thirty thousand of them before lunch.

Should you really care about replacing git?

The headline from the post is that git could not take it. Their monorepo history is nearly 100 GB, CI alone does 25 million checkouts a day, and they were running several hundred git mirrors just to keep the lights on. So seven people built a replacement called Scion, plus a code review tool, code search and access control, and migrated everything in five months. It is a terrific engineering story and you should read it.

But Scion is not why you should care. Anthropic says so themselves: it only makes sense for enormous monorepos, they are not releasing it, and they would rather GitHub and GitLab steal the ideas. The reason you should care is what happens to everything downstream of the merge once code stops being the slow part.

2 Fast 2 Merge

Nobody in this franchise ever chooses to stop. Stopping is something the world does to them, usually with a wall. In Anthropic’s world, that wall was the merge queue.

So how do you still go faster? Well, they argue that a proper merge queue does not make much sense at agent scale. A merge queue is the thing that takes each change, tests it against the current tip of main, and only then lets it in. It is how most serious teams keep main green, and it works by holding everything else back while one change goes through.

At 30,000 merges a day, that doesn’t work. By the time your tests finish, thousands of other changes have landed, and the main you tested against no longer exists.

So they did the thing you are not supposed to do. They moved testing from before the merge to after it, and before the deployment. They accept that changes will conflict with each other on main, and note that Claude will fix those conflicts faster than a human can notice.

Review changed too. Their engineers still look at every change request, but they now review the intent of a change rather than reading every line of code. The human’s main job, in their words, is often to tell Claude “no”.

So what’s keeping the deployments safe?

Put it together: code lands on main constantly and not always green, humans check whether a change makes sense rather than whether line 412 is right, tests run afterwards, and then it deploys.

There is one thing the post leaves out, which is fair, since it is a post about source control. The code is now on a server. Who decides whether users see it? And when something is wrong, how fast can they pull it back?

Anthropic took the merge queue off because it could not keep up, and something has to take its place. Whatever that is, it has to work after the code is already live. The rest of this post is about what that something is.

Faster and more broken

Anthropic is an extreme case, but the direction shows up in every serious dataset we have. DORA’s 2025 report found that AI adoption correlates with higher delivery throughput and, at the same time, higher instability: more failed changes, more rework. DORA correlates a 25% increase in AI adoption with a 7.2% drop in delivery stability. Sonar’s 2026 survey explains the why: 42% of committed code is now AI-generated or AI-assisted, heading for 65% by 2027. In the same survey, 96% of developers say they do not fully trust that code, and only 48% always verify it before committing. More code, less review per line, more things breaking in production.

DORA has since put a price on it. Their 2026 ROI of AI report calls it the instability tax and gives it a formula: deployments x change failure rate x recovery time x what an hour of downtime costs you. In their sample calculation, a change failure rate that drifts from 5% to 6% after AI adoption costs $344,000 a year in downtime. The only term you can actually drive down is recovery time, and that is the one this post is about.

Ride or die is not a release strategy

If we were on a Fast and Furious set right now, we would know exactly what to do. Floor it, drive through whatever is in the way, and sort it out at the barbecue. Ride or die. It is a great motto for a crew, but a terrible way to release software.

There are three places you can catch a bad change: before it merges, before it deploys, or after it is live. Anthropic just showed that the first two cannot keep up with agent speed. That leaves the last one. After the code is live is the only place where you can still act in seconds.

The trick that makes “after it’s live” survivable is old and boring and most teams still don’t do it properly: deploying code and releasing a feature are two different events. Deploy is when bytes reach a server. Release is when a user can see the new behavior. A feature flag is the thing that separates them. Wrap the new behavior in a flag, and ship it switched off. The merge, the deploy, the agent’s questionable decisions, none of it touches a user until you say so.

And this is where Anthropic and their Claude Code team answer the question about how they do code review. It describes six layers of checks on every change:

“Some mistakes will still get through, so the last layer is about catching them fast. Flags turn off without a deploy.”

Their pipeline, in their words:

“New behavior usually ships behind a flag to Anthropic employees first, and our heavy use often surfaces regressions before users do.”

And the line underneath it:

“Everything is reversible. Flags, reverts and staged releases undo most mistakes in minutes.”

Once you have that separation, the scary pipeline from earlier becomes almost relaxing:

• Code lands on main constantly, half tested. Fine. It’s not exposed yet.
• It deploys continuously, because holding deploys back just recreates the merge queue one step later. Fine. Still not exposed.
• You turn it on for 1% of users. If the error rate moves, you turn it off.
• When it holds, raise to 10%, 50%, 100%. Once everyone has it, the flag and the old code path get retired, by the same agent that added them, so the conditional does not live in your codebase forever.

Picture a team shipping continuously. Change 5 goes out, it is bad, and by the time anyone notices, changes 6 to 12 have shipped on top of it. You can roll back to the last good deploy, which is fast but takes 5 and everything after it with it, seven good changes gone to fix one. Or you can revert just change 5 and redeploy, which is precise but means another trip through the pipeline, and at agent speed the pipeline is always busy. Or you turn off the flag on change 5: one change off, eleven still live, nothing redeployed. The first two get worse as the merge rate climbs. A rollback takes more good changes with it, a revert waits in a longer queue. The flag is the only option that stays the same. Canaries protect the deploy. Flags protect the feature.

 

When every deployment carries thousands of changes, rolling back is too blunt. Turning off one feature is the only precise move left.

It is also where the money is. Go back to DORA’s formula: deployments, times change failure rate, times recovery time, times cost per hour. AI pushes the first two up. Recovery time is the one you can push down. DORA’s sample assumes four hours to recover from a failed deployment. Flipping a flag takes seconds. Even if you count the time to notice and decide, and call it a full hour, DORA’s calculator with every other default untouched cuts the instability tax from $344,000 to $86,000. Three quarters of it, gone, from one input.

We call this way of working FeatureOps: every release controlled, measured and reversible at runtime, regardless of how the code got there. When agents write most of your code, runtime control is the one gate you still fully own. Everything upstream is getting faster and blurrier. This is the part that stays in your hands.

Han is dead code

Nobody in this franchise stays dead. Han dies in Tokyo Drift, gets a whole film of revenge, and two films later strolls back in eating snacks while a flashback explains he was never dead, just undeployed.

Every large codebase has a Han. The famous one is Knight Capital. In 2012 they switched on a new trading feature. One of their servers had missed the update and still had an old feature inside it, one that had been switched off nine years earlier and never removed. The switch woke it up. In 45 minutes it lost around $460 million. Nobody owned the old code, nobody was watching it, and nobody remembered it was there.

That is the risk a managed flag system exists to remove, and at agent scale it gets more pressing. Agents will create flags far faster than humans ever did, and a quarterly cleanup sprint will not keep up. So expiry has to be part of the flag definition, not a chore afterwards: Unleash gives every flag type an expected lifetime, warns you when it’s stale, and tracks a technical debt rating per project. Cleanup can be fully automated, so if an agent created the flag, an agent can remove it.

Review the intent, not lines of code

Anthropic’s engineers still look at every change. What changed is what they look at. They decide what a change is for, whether it belongs, and how much could go wrong if it is mistaken, and they say no when the answer is wrong. The lines themselves are the agent’s problem.

Feature management has had the tools for intent review for years. A change request that says “roll new-checkout out to 25% of EU users” is an intent, and a human can approve or reject it in ten seconds. The 2,000 lines behind it were reviewed by an agent, tested after the merge, and will be caught by the rollout if they are wrong. The Claude Code team has formalized this into tiers: low-risk changes merge with no human once the checks are green, medium needs one person, high needs two. And the change sets the tier, not the author. Their phrase for it is “blast radius sets the bar.”

The question at agent scale is not whether to automate review and release but how much, and the only honest answer is: it depends on what breaks if you are wrong. A copy change and a payments change should not go through the same gate, and a human reading both with the same attention is a waste. Once you know the risk of a change, you can be precise about the level of automation it gets, from fully automatic to two humans and a change request.

That is where we think feature management is heading: flags that know how risky they are, and release workflows that adjust accordingly. In practice today that means change requests on production environments, roles per project and environment, and humans spending their attention on the one thing they are still better at: judgment.

Agent intent and automation

The agents need their own door too, and it should not be a plain API. Anthropic’s big design principle for Scion was that everything the client can do, a job can also do through an API, so CI never needs a checkout. Flags need the same, with one addition: the agent should not have to learn our API to get a flag right. That is what the Unleash MCP server is for. The agent states what it wants, a flag for this change, a safe rollout to this segment, a stale flag cleaned up, and the server works out the steps, checks what already exists, and keeps the risky operations behind the right permissions. It is agent-first rather than bolted onto the API, and the conventions that make a flag a good flag travel with it. The UI is for people reviewing intent. The MCP server is for the things doing the work.

And then somebody has to watch the road. A cool detail in the Anthropic post is what they call superfans: Slack channels where Claude is told to obsess over the health of one component, with access to logs and telemetry, acting like an engineer who has nothing better to do than refresh dashboards.

That is a good way to watch a system, but an automated rollout can do one better. An automated rollout relies on a known signal, error rates and impact metrics per flag, and a known response, which is to pause or roll back. Those two things can be wired together in Unleash. Set a safeguard on the rollout, and when the metric crosses the line the flag turns itself off. The rollout watches itself, and the first anyone hears about the bad change is a message saying it has already been turned off.

Your first quarter mile

You do not need a new version control system. You do not need to fire your merge queue this week. But you do need to stop treating runtime control as something you bolt on after the pipeline is “done,” because the pipeline is about to change under you. In order of payoff:

1. Chart your merge rate. Put merges per day next to change failure rate on one dashboard. Anthropic’s curve went from flat to vertical in four months; if you check quarterly, you will see it after it has arrived.
2. Make “off by default” the default. Any change that alters what a user sees, or that touches something you cannot afford to get wrong, like payments, auth or data, goes behind a flag. Especially the ones agents write. Give agents a way to create flags through the API or MCP so it costs them nothing.
3. Give every flag an expiry. Set expected lifetimes by flag type, let the platform mark flags stale, and let the agent clean up after itself.
4. Move production approval to the intent layer. Change requests on prod. Humans approve rollouts. Agents own the code diff.
5. Put a kill switch on anything you would hate to redeploy under pressure. Rolling back a deploy means touching every change in it, and at agent scale that is thousands of changes. A kill switch turns off one feature and leaves everything else running.
6. Add “How to revert” to your PR template. The Claude Code team requires it on every pull request, next to “Testing” and “Risk.” If the answer is “turn off the flag,” you are doing it right.
7. Monitor rollouts like Anthropic watches components. Even one alert on error rate per newly enabled flag turns “who merged this” into “turn it off, then find out.”

None of this needs new infrastructure, but it gets much harder to retrofit once the merge rate has doubled. And it is going to double.

Everyone accounted for

Every one of the Fast and Furious films ends the same way. The job is done, nobody is in the wreckage, and the crew is in a backyard with a grill.

What’s our happy ending? Agents are going to write most of the code, faster than any pipeline can check it. The merge will stop being the place where you decide whether a change is safe. The only place left is runtime, and it happens to be the only place where that decision takes seconds instead of a sprint.

So ship it switched off. Turn it on for a few people. Watch. The moment it misbehaves, turn it off, and leave the other thousand changes running. Let the agent clean up after itself. Then, when the day ends with nothing on fire and everyone accounted for, we say grace.

You do not need Scion. You need FeatureOps.