Anthropic created Scion to replace Git

At six in the evening, the improvement sales requested is done, but it still can't be used. The change still needs to be reviewed and the rest of the system checked to make sure it's still working. This is a hypothetical scene, though the pending item feels familiar to anyone who has waited for a software update.

Now the amount of work reaching that review suddenly spikes. Anthropic reported that it went from about 2,500 changes merged per day in May 2026 to more than 30,000 in September. To handle that load, it built Scion and migrated its main repository away from Git in five months, according to its October 13 post.

My reading of the announcement is this: a tool that speeds up one part of the work can expose the next wait. Before asking your vendor to copy Anthropic, it's worth understanding what problem it solved.

Yes, Scion takes Git's place

Git is a version control tool. Think of an orderly history of a shared document: it lets you see what changed and recover an earlier version. The Git documentation explains those functions and its distributed design, where copies can include the full history.

Scion belongs to that same category. The main difference is that it concentrates operations on servers and delivers the data the client needs. It's designed for connected agents, with an enormous workload.

Anthropic makes clear that Scion is not a suitable replacement for Git for general use. That warning changes the conversation: we have a specialized infrastructure case, not an instruction for every company to switch tools. The case data is reported by the company itself in its engineering article.

The business problem is in the wait

For a small business owner, keeping the software's history may sound far removed. Until an update breaks a discount calculation and someone needs to figure out what happened.

That's where it matters that the vendor can identify the change and recover a version that worked. It also matters how long it takes to review an improvement before putting it in front of your customers. These are operational questions you can ask even if you've never programmed.

My interpretation of Anthropic's case is that production speed demands reviewing the capacity of the entire process. If one part generates work faster than the next can process it, a queue appears.

That queue can be visible, like a board full of pending tasks. It can also hide in messages: "it's done, it just needs approval." Meanwhile, the area that requested the change keeps using a temporary fix.

A comparison with a workshop

Let's say a workshop buys a machine that cuts parts much faster. The inspection manager is still the same person, with the same schedule.

By the end of the day there are more cut parts. Delivered orders might stay the same because they're waiting for inspection. If the manager only evaluates the machine, they'll see an improvement. If they review the full order, they'll find the wait.

With software development, I'd use that same lens. The work produced has value when it reaches a useful and reliable delivery. The number of changes, on its own, leaves that question open.

What to ask your provider

Instead of starting with "are you using the new tool yet?", I'd ask for evidence about a recent improvement. It can be something concrete: adding a discount condition or fixing a report your team needs every week.

The conversation can lean on this table:

You don't need to demand a complicated presentation. A clear explanation, with dates and a verifiable example, allows for a much more useful conversation than a list of tools.

If the provider doesn't know where the time went, that's a good first pending item. Switching technology while the wait remains unidentified makes it hard to prove whether the investment paid off.

A small exercise before spending

I'd start by logging a few recent improvements. For each one, I'd note when it was requested and when it became available to the user. Then I'd separate working time from waiting time.

It's a diagnostic proposal, not a result obtained in a project of mine. It helps formulate a hypothesis: maybe the delay is in getting an approval; maybe information is missing from the start.

If the pending item is an approval that only one person can give, it's worth agreeing on criteria and review schedules. If work gets sent back because the request was ambiguous, it's worth clarifying what result the user expects before starting.

The solution will depend on what you find. The goal of logging is to keep the conversation from ending too soon in the purchase of a tool.

Also measure what comes back

A fast delivery can look successful until the team starts reporting bugs. That's why I'd pair delivery time with a log of follow-up fixes.

You don't need to turn it into a complicated system. Just distinguish a new request from a fix to something that was recently shipped. That way you can see whether you're making progress or whether part of your capacity is being consumed by repairing recent work.

My takeaways

What interests me about the announcement is the relationship between capacity and design. A company can reach a scale where an off-the-shelf tool requires too many adjustments. At that point, building your own solution deserves serious evaluation.

For a small business, I'd demand an explanation of the problem and the cost of maintaining that solution. Anyone proposing to build a tool should also explain who will maintain it when it breaks and how you'll verify it improves the service.

The useful business metric is how long it takes an improvement to work reliably for the person who needs it.

Before changing the tool, find the row

Scion offers a concrete case for discussing how AI changes development. My recommendation for a small business is to start with a recent delivery and reconstruct its journey.

If your team saves time producing work, check where that savings ends up. It may show up as faster delivery or it may pile up in the backlog. That difference helps you decide what to improve first.

References

• Redesigning source control at Anthropic
• Git: About Version Control