AI can make your backlog grow faster
More drafts can leave customers waiting just as long. Follow the work through the company before deciding where to invest.

Anthropic reports that it went from merging around 2,500 code changes a day in May to more than 30,000 in September. Its X post links to an engineering account of how the infrastructure around development became a bottleneck. The company built its own source control system to handle the volume. I think the business implication deserves attention: making work faster can expose a constraint somewhere else in the company.

Anthropic's workload is unusual. Its engineering team explicitly says its new system is unsuitable as a general replacement for Git. I would take the case as a reason to examine what happens after AI produces the work. The code-change count also tells us little by itself about the value of each change or the business result.
A team can become much faster at preparing something while the result still takes just as long to reach a customer. The delay may sit in a handoff, an unresolved decision or a person who has to review everything. If more work arrives there than the next stage can handle, the queue grows. Faster preparation then adds to the pile waiting for attention.
Consider a hypothetical sales team using AI to prepare proposals. Drafting used to take enough time that the commercial lead could review them as they arrived. Now the team can produce several versions quickly, and more opportunities reach that lead at once. Each proposal still needs a judgement about the promised scope, the delivery commitment and the price. The team's writing capacity has increased. Its capacity to make those commitments may be unchanged.
The extra versions can make matters worse. Someone needs to compare them, explain which assumptions changed and decide which recommendation to use. A polished draft may also hide an unresolved customer question. Producing more of those drafts consumes attention that could have gone into finding out what the customer needs before preparing an offer.
I would examine a proposal from the moment the team begins work until it is ready to send. How much time goes into preparation? Where does it wait, and why does it come back for revision? The reasons matter. Waiting for a missing customer answer calls for a different change from waiting for an available reviewer. A review that repeatedly discovers the same missing information may point to a weak brief or a poor handoff.
The team could then change the handoff in a limited way. In this example, the person preparing the proposal might include the customer's decision, the assumptions behind the offer and the commitment requiring approval. They could recommend a version and explain the choice. The commercial lead would have a clearer decision to make, with the consequential commitments still subject to review.
There may also be work that should stop arriving at that person. If every minor wording change needs the same approval as a delivery promise, the process gives different decisions the same cost. Agreeing which changes the team can make within an approved offer could free attention for the commitments that need it. The boundary would have to be explicit enough for people and their agents to use consistently.
Sometimes the useful change is to produce less. A proposal that cannot proceed until the customer answers a question may not need another polished version today. The agent could help prepare the question or identify the unresolved assumption. Directing that capability towards the obstacle gives the next person a better chance of moving the work forward.
I would judge the change by what the team can finish, including the quality of the commitments and the revisions required afterwards. A shorter drafting time is useful evidence about drafting. To justify expanding the arrangement, I would also want to see whether proposals spend less time waiting and reach customers with fewer avoidable corrections. Those results may point to a different investment from buying more generation capacity.
Anthropic changed infrastructure because its existing setup could no longer handle the work arriving at it. A commercial team may need a much smaller change. Following the work far enough to find the constraint is what makes the investment decision useful. Before asking AI to produce more, I would want to know what the company is currently unable to move forward.