Work in progress is the new software delivery bottleneck
Principal Content Producer
Starting new software work has never been easier. Developers can assign tasks to multiple coding agents, let them work independently, and turn their attention elsewhere while those agents write, test, and revise code. As models improve, teams have more opportunities to pursue work that previously would have waited.
Getting all that work validated and merged is another matter. The 2026 State of Software Delivery Q3 Pulse report shows teams working across more branches and projects. But for the median organization, all that additional development activity isn’t translating into faster shipping.
Work in progress (WIP) is emerging as the new delivery bottleneck. Coding agents allow teams to keep far more work in flight at once, but the capacity to validate, review, and integrate changes hasn’t expanded at the same rate. As parallel development accelerates, unfinished work is piling up faster than teams can get it onto main.
Delivery metrics are improving, but work keeps piling up
At the beginning of 2026, software delivery systems were struggling to keep up with AI-driven development. The Q1 State of Software Delivery report found that average daily workflow volume had increased 59% year over year, while main-branch throughput for the median team declined 7% and success rates fell to a five-year low. Teams were generating more code, but validating and integrating it reliably had become harder.
By Q3, models had become more capable, developers were getting better at working alongside coding agents, and CI was adapting to agent-driven development. Main-branch success rates had increased, workflows had sped up, and recovery times had improved.
With better models and healthier delivery pipelines, teams have more capacity for development as well as a choice about how to use it: They can put it toward accelerating existing work or pursuing more of their R&D roadmap. The Q3 data suggests teams are increasingly choosing to expand the scope of development, opening more projects and managing substantially more changes in parallel.
More work in flight
| Development activity | Change since Q1 |
|---|---|
| Active projects | +16% |
| Active feature branches per median contributor | 7 → 9 |
| Active feature branches among the most active 5% | 36 → 57 |
But all that additional work isn’t translating into faster shipping. Median throughput on main has remained essentially flat at just 1.7 runs per day throughout 2026, even as the number of active projects and branches has surged.
Teams have significantly expanded the amount of work underway without a corresponding increase in the pace of delivery. More changes are in progress, creating a growing backlog of work that still needs to be validated, reviewed, and merged.
Why more parallel work can slow delivery
Coding agents have changed how much work a developer can manage at once. One agent can implement a feature while another fixes a bug and a third updates dependencies. Each can modify code, run tests, and investigate failures with relatively little supervision.
But independently developed changes eventually need to work together. Requirements must be clarified, dependencies reconciled, failures resolved, and code reviewed before integration. Agents can handle increasingly large parts of that process, but some decisions still require broader context and engineering judgment.
As teams expand the number of active branches and projects, they also increase the amount of work that needs to be coordinated. More changes can mean more work awaiting review, more integration dependencies, and more unfinished tasks competing for attention.
What Little’s Law tells us about growing WIP
The relationship between WIP and delivery speed is well established. Little’s Law describes how work in progress, throughput, and cycle time relate in a stable system:
Average cycle time = Average WIP ÷ Average throughput
Suppose a team merges five changes per day and has ten changes in progress. Each change spends an average of two days in the system.
Little’s Law in practice
| Scenario | Changes in progress | Merges per day | Avg. cycle time |
|---|---|---|---|
| Starting point | 10 | 5 | 2 days |
| Agents double active work | 20 | 5 | 4 days |
| Completion rate doubles too | 20 | 10 | 2 days |
If agents double the amount of work underway without increasing the rate at which changes are completed, average cycle time doubles.
The Q3 findings show how quickly parallel development is expanding. Little’s Law explains what happens when the capacity to finish work doesn’t keep pace: unfinished work accumulates, and changes take longer to reach main.
As more tasks remain unfinished, developers have more dependencies, decisions, and competing priorities to keep track of. Even with more capable agents, growing WIP can make it harder to get changes merged and shipped.
The highest-throughput teams are breaking the pattern
Not every organization is experiencing the same constraints. In Q2, workflows at the 95th percentile were delivering roughly nine times the median throughput on main. By Q3, that gap had widened to more than 10×.
The most active organizations are expanding their workload, too. Among the top 5% of organizations by total main-branch activity, the number of active feature branches grew 55%. Crucially, they also increased throughput on main by 31%.
The median organization is taking on more parallel work without a corresponding increase in shipping velocity. The leading teams, meanwhile, are managing more work in progress and getting more validated code onto main. They’re finding ways to turn greater development capacity into greater delivery velocity.
How to keep parallel work moving
Agent-driven development gives teams more capacity to pursue work in parallel. Making the most of that capacity means improving how changes move from implementation through validation, review, and integration.
Three practices can help.
1. Make the actual workload visible
A developer might have several agents working simultaneously, yet a project board shows only one story in progress. Behind that story could be multiple active branches, unfinished changes, and decisions waiting for attention.
Track active branches, open PRs, blocked changes, and work awaiting review or integration. Pay attention to where queues are growing and how long changes remain unfinished.
Set practical WIP limits based on the team’s ability to complete changes. Give agents narrowly scoped assignments with clear acceptance criteria, and plan how parallel changes will be integrated. When review or integration queues are growing, prioritize getting existing work merged before launching more tasks.
2. Give agents the feedback they need to resolve failures
One way to increase shipping capacity is to make error detection and remediation as efficient as code generation. Agents need fast, actionable feedback about whether their changes work, along with the tools to investigate failures and attempt repairs without waiting for a developer to intervene.
CI can provide that feedback throughout the development process. Chunk sidecars give agents fast, CI-aligned validation before changes are pushed. Smarter Testing reduces feedback times by focusing test runs only on the checks affected by a change. The CircleCI CLI and MCP server allow agents to inspect failures, retrieve test results, and rerun validation autonomously, without requiring developers to copy and paste error logs or other build context.
Developers remain responsible for decisions that require engineering judgment. Giving agents direct access to validation feedback helps them resolve routine problems independently, while developers focus their attention on the changes and decisions that need their expertise.
3. Measure delivery, not just activity
Agent utilization, commits, and PRs opened tell you how much development work is happening. They don’t tell you whether teams are shipping more software.
Track active WIP, time to first review, cycle time, and changes merged into main. Merge efficiency ratio (MER) measures the number of CI runs on feature branches relative to main. A higher MER can indicate repeated validation and rework that may be slowing delivery.
You can use these metrics to look for patterns that reveal where work is accumulating.
Reading your delivery metrics
| What you’re seeing | What it may indicate |
|---|---|
| Rising WIP + longer cycle time + flat merge throughput | Work is accumulating faster than the team can complete it. |
| More open PRs + longer time to first review | Changes may be waiting for review before they can move forward. |
| Rising MER + repeated CI failures | Rework and repeated validation may be slowing integration. |
| More active branches + increasing throughput on main | The team is expanding parallel development while getting more validated code merged. |
The aim is to understand whether greater agent capacity is helping teams deliver more software, or simply creating more work that remains unfinished.
Turn development capacity into delivery velocity
Coding agents have made it possible for developers to pursue more work in parallel. As models improve and teams grow more confident directing them, the number of active tasks, branches, and projects will likely keep increasing.
The 2026 State of Software Delivery data shows that teams are getting better at validating the code agents produce. But for the median organization, those improvements haven’t translated into faster shipping. The highest-throughput teams are demonstrating that it’s possible to expand parallel development and increase delivery velocity together.
The next gains in software delivery will come from getting more of that parallel work across the finish line. Managing WIP, giving agents fast and actionable validation feedback, and involving developers where their expertise matters can help teams turn greater development capacity into more completed, validated software.
CircleCI gives coding agents direct access to validation results, failure diagnostics, and workflow controls so they can resolve routine problems independently, freeing developers to focus on the engineering decisions that require their expertise. Get started with CircleCI and turn more of your team’s development activity into software that ships.
