At the beginning of 2026, AI-generated code was overwhelming software delivery systems. Developers were dealing with oversized changes, broken builds, and repeated rounds of debugging and validation. Nine months later, many of those problems are improving. But most teams still aren’t shipping any faster.
We just published the State of Software Delivery Q3 Pulse report, built on more than 22 million real CI workflows from August 2026, and the data suggests the AI delivery bottleneck is changing. AI has made it easier than ever to start new work, but reviewing, validating, and integrating changes haven’t gotten nearly as easy. As developers juggle more parallel workstreams, the demands on their time and attention keep growing.
In this issue, we’re exploring an old problem at a new scale: work in progress. We’ll look at what manufacturing and decades of software engineering practice can teach us about managing it, what our latest data reveals about the growing volume of unfinished work, and how better processes, guardrails, and CI can help teams deliver more of what they start.
The bottleneck is changing
Our Q3 findings offer some encouraging news. Main-branch success rates have recovered from a five-year low, workflows are finishing faster, and developers are resolving broken main branches sooner. Teams are running more validation per workflow, yet CI success rates and recovery times are improving.
But most teams aren’t seeing corresponding gains in delivery velocity. Since Q1, the number of feature-branch workflows active on a typical day has increased 40%, compared with just 17% on main. The median main-branch workflow still runs about 1.7 times a day, essentially unchanged since Q2.
Meanwhile, the highest-throughput teams are expanding development activity and getting more work onto main. The throughput gap between the top 5% of main-branch workflows and the median has widened to 10.4x, up from 9.1x last quarter.
Explore the Q3 State of Software Delivery Pulse report →
If teams are getting better at validating and fixing code, why isn’t more of it reaching main?
One possibility is that organizations are using their growing development capacity to take on more work, rather than increasing the rate at which they finish it. And when work accumulates faster than teams can complete it, the consequences are familiar to anyone who’s studied manufacturing or project management.
An old problem at a new scale
In the decades after World War II, Toyota faced a difficult manufacturing problem. American automakers were producing enormous quantities of vehicles using large-scale production systems, but Toyota lacked the resources and demand to operate the same way. It needed to produce a greater variety of vehicles in smaller quantities, without accumulating expensive inventories of parts and unfinished products.
Consider a conventional production line. If one station can produce 1,000 components in a shift, keeping it running at full capacity seems efficient. But if the next station only needs 500, the additional output doesn’t help the factory finish more cars. It creates inventory that must be stored, tracked, and eventually processed.
Toyota developed a different approach, built around two principles that became the foundations of the Toyota Production System.
The first principle was just-in-time production. Rather than pushing as much material as possible through each stage, downstream stations requested (pulled) what they needed from upstream stations. Toyota’s Kanban system helped coordinate the flow, keeping inventory aligned with demand.
The second was jidoka, often described as automation with a human touch. Machines could detect abnormalities and stop production automatically, allowing workers to investigate problems without constantly monitoring every operation. Together, the principles helped Toyota improve production efficiency while protecting quality and making better use of human expertise.
Software engineering learned the same lesson
Manufacturing ideas like the Toyota Production System eventually influenced how software teams organized their work. Lean software development brought principles around reducing waste and managing flow. Agile emphasized delivering working software frequently, while Scrum encouraged teams to organize around focused goals and regularly inspect their progress.
Kanban made work in progress especially explicit, using visible workflows and WIP limits to prevent tasks from piling up at individual stages. Scrum teams have adopted similar techniques to improve flow within their Sprints.
Different approaches, but a common principle: starting more work doesn’t guarantee that more work gets finished. Sometimes the opposite happens, especially when developers have to keep switching between unfinished tasks.
The math behind unfinished work
In 1961, operations researcher John Little published a mathematical relationship that helps explain why excess work in progress can be costly. Known as Little’s Law, it connects three measures of a stable system:
Average cycle time = Average WIP ÷ Average throughput
Imagine an engineering team finishes 10 changes each week, with an average of 20 changes in progress. The average change spends two weeks in the system. Now imagine AI makes it possible to work on 40 changes simultaneously. If the team still finishes 10 changes per week, average cycle time rises to four weeks.
The team is managing twice as much concurrent work but finishing it at exactly the same rate. Individual changes now spend twice as long in the system.
Little’s Law doesn’t explain why throughput is constrained, and reducing WIP doesn’t automatically increase completion rates. But it illustrates what happens when organizations increase the amount of work entering a system without improving how quickly it gets finished.
AI has changed how much work we can start
For most of software engineering’s history, implementing a change took enough time to place a natural constraint on how much work a developer could initiate. Coding agents have changed that balance. A developer can now delegate several tasks, work on another project, and return to find multiple proposed changes ready for attention.
Imagine a developer directing three agents. One is implementing a new API endpoint, another is refactoring a shared service, and a third is fixing an intermittent integration test. All three can make progress independently, until they encounter something requiring broader context.
The API might stall on an authorization question before the endpoint is finished. The refactor could pass its checks, but what if it changes an interface another team depends on? And the test fix might fail in CI because it relies on part of the environment that wasn’t in the task description.
The agents haven’t necessarily done anything wrong. They’ve reached decisions that require project context, tradeoffs, and an understanding of how the system fits together. That’s where developers need to step in.
Multiply the scenario across an organization, and it’s easy to see how additional workstreams create competing demands on developers’ attention. Agents can move several tasks forward at once, but teams still need ways to coordinate and finish that work without overwhelming developers.
Other engineering leaders are raising similar concerns. In a recent Scrum.org article, Mary Iqbal argues that teams need to reconsider their WIP limits as AI accelerates development. Thoughtworks CTO Rachel Laycock offers a complementary perspective in Maybe We Shouldn’t Be Reviewing All This Code. She questions why so many responsibilities get concentrated in a review at the end of implementation. Moving feedback and decision-making earlier can help developers apply their expertise before problems pile up and become expensive to resolve.
What the Q3 data tells us
Our latest findings suggest teams are already experiencing some of the pressures associated with growing work in progress.
At the beginning of the year, the median contributor had 7 active feature branches. By Q3, that number had increased to 9. Among the most active 5% of contributors, active branches grew from 36 to 57. Teams everywhere are spreading development across more projects, more workflows, and more parallel workstreams.
Yet most of those workstreams aren’t moving any faster. Median main-branch throughput remains flat at 1.71 runs per workflow per day, while feature-branch throughput has declined from 2.04 to 1.89 since Q2. And although developers are resolving main-branch failures faster, median feature-branch recovery has increased to 86 minutes, up from about 80 minutes in Q1.
One possible explanation is that developers are prioritizing work on the critical path. A broken main-branch pipeline can block an organization’s ability to deliver value, so teams restore it quickly. A failed feature branch may wait while someone addresses another task, project, or branch.
The pattern is even clearer on weekends, when developers are understandably focused on life outside work. Since Q1, active feature-branch workflows have increased 65% on weekends, with agents and bots now accounting for roughly one in five weekend feature branches. AI is making it easier to start work even when developers are off the clock.
But broken feature-branch builds take 104 minutes to recover on weekends, 32% longer than on weekdays. It’s a microcosm of the broader WIP problem: when more demands compete for limited developer attention, failures take longer to resolve and work moves more slowly through the system.
The leading teams are finding another way
The highest-throughput teams aren’t necessarily taking on less work. In fact, the most active 5% of organizations have increased feature-branch activity by 55% since Q1, nearly twice the median team’s growth, without a measurable increase in contributor count.
What sets them apart is how much of that work reaches main. Since Q1, they’ve increased total main-branch throughput by 57%, and each main-branch workflow now runs 31% more often. Below the top quarter of organizations, per-workflow throughput has barely changed.
Our data offers a few clues about how they’re managing it. The most active teams get faster feedback, with median main-branch workflows finishing in 1.5 minutes compared with 6.2 minutes for the median team. Their feature-branch workflows also succeed more often, at 75.6% versus 66.6%.
They also tend to need fewer validation cycles before changes reach main. We measure that using merge efficiency ratio (MER), the number of feature-branch workflow runs for every run on main.
Fewer unnecessary cycles mean fewer occasions when a developer has to revisit a change, investigate a failure, or reconstruct context. Across hundreds or thousands of changes, those savings can add up.
Faster feedback, more reliable validation, and fewer cycles are consistent characteristics of the teams getting the most work onto main. Their results suggest that organizations can increase development capacity and delivery capacity together. The question is how to help more teams do the same.
Make human attention count
Traditional WIP management still applies to AI-assisted development. Teams need to know how much work is active, where it accumulates, and which constraints determine how quickly it can be finished.
But the answer isn’t simply to start less work. Organizations can also improve how work moves through the delivery system, reducing unnecessary interruptions and giving developers better support when their expertise is needed.
Here are three places to focus.
1. Manage the work, not just the agents
If a developer has several agents working simultaneously, a project board showing one story marked “In Progress” may no longer represent the work they’re managing.
Teams need visibility into active branches, open changes, blocked tasks, outstanding decisions, and work waiting for integration. Start by identifying where work regularly stops moving. Is it waiting for clarification, an architectural decision, another team’s approval, or a developer who’s already coordinating several other changes?
Set practical WIP limits, give agents clear acceptance criteria and boundaries for autonomous work, and prioritize clearing blocked tasks before starting more work.
2. Let agents handle routine CI failures
Every CI failure that requires a developer’s attention can interrupt other work in progress. Even a simple test failure can mean switching branches, digging through logs, and reconstructing context.
Give agents the tools to catch problems early, investigate failures, and propose fixes before handing work back to developers. CircleCI supports that process throughout development:
Before the push: Chunk sidecars and agent hooks provide fast, CI-aligned validation so agents can catch and resolve routine problems as they work.
In CI: Smarter Testing shortens feedback cycles with targeted testing, dynamic splitting, and automatic retries for flaky tests.
After a failure: CircleCI’s CLI and MCP server give agents access to failure logs, test results, and workflow controls so they can investigate problems and propose fixes.
Developers still review changes and make decisions that require engineering judgment. But better CI guardrails and agent-accessible feedback can reduce the repetitive work competing for their attention, helping teams get more changes ready to ship.
3. Measure the work that gets finished
Agent utilization, commit counts, and PRs opened tell you how much work is happening, not how much is getting finished.
Track completed changes, cycle time, work-item age, and how long changes wait for review or integration. Consider tracking MER alongside those measures to identify unnecessary validation cycles and recurring sources of rework.
If development activity is increasing while delivery velocity remains flat, look for the stages where work spends the most time. The right response may be tighter WIP limits, clearer agent instructions, faster feedback, or better coordination between people and agents.
The next challenge for the software factory
There’s good reason to be optimistic about AI-assisted development. Models are improving, developers are getting better at directing them, and CI is adapting. Our Q3 findings show that many delivery metrics are improving, even as development activity continues to grow.
Explore the Q3 State of Software Delivery report →
But more capacity means more work to manage. Decades of manufacturing and software engineering experience show that too much unfinished work can slow delivery. Teams need clearer priorities, better coordination, and CI tools that help agents catch and resolve routine problems without constantly pulling developers away from other work.
The leading teams are showing what’s possible. They’re expanding development activity while increasing delivery velocity, with faster feedback, more reliable validation, and fewer unnecessary cycles. The opportunity for everyone else is to reduce the work that requires a developer’s attention, so engineers can focus on the decisions that get software ready to ship.
Help shape our year-end software delivery research
We’re expanding our State of Software Delivery research beyond CI data to learn how developers and engineering leaders are using agents, managing work in progress, and adapting their delivery processes.
Take our Q4 survey, share what’s working for your team, and help shape our outlook for software delivery in 2027. The survey takes about 10 minutes, and one randomly selected participant will receive a $500 Amazon gift card.