Now we’re building for a different kind of user: AI agents. Increasingly, agents are taking action on behalf of users and developers. They’re reading documentation, inspecting code, calling APIs and CLIs, and using MCP tools to interact directly with products. And just as good UX and DX require designing around the needs of their users, products need to account for how agents find information, choose tools, make decisions, and take action.

The industry has started calling this agent experience (AX). As more work moves through agents, their ability to understand and operate a product becomes part of the product experience itself. A platform can have excellent UX and DX and still be difficult for an agent to use reliably. At CircleCI, we’ve made solving that problem a core product goal: making CircleCI work just as well for agents as it does for the developers they support.

In this issue we’re sharing what we’ve learned redesigning CircleCI for agents. We’ll start with the product problem that pushed us into AX, then walk through five findings from our testing that changed how we think about context, tools, evaluation, and the way agents interact with a product.

Subscribe now

We started with broken builds

The need to design for agents is already showing up in how customers use CircleCI. In our 2026 software delivery data, average daily workflow volume increased 59% year over year, the largest increase we’ve measured. More agent-generated code means more builds, tests, and opportunities for failures to interrupt the development loop.

Broken builds were the highest-value place to start. If agents can produce code quickly, they also need an efficient way to recover when validation fails. Our first approach followed what Netlify CEO Mathias Biilmann describes as the closed model of agent experience. The original version of Chunk was a hosted agent that could diagnose a failing build, propose a fix, and open a pull request.

In production, Chunk turned CI green on around half of its attempts, but developers chose to merge less than 25% of its fixes. The takeaway was clear: engineers wanted more control over the fixing process. So we moved toward the open model, giving their existing agents direct access to CircleCI data and tools, so the developer could stay informed and in control of the recovery process.

Early benchmark testing showed how sensitive agent performance was to the environment around the model. In a 100-sample benchmark of CI repair tasks, better log preprocessing increased the share of proposed fixes that closely matched the known solution from about 25% to 53%. The size of the improvement made one thing clear: context, tools, evaluation, and workflow design could materially change how well the agent performed. We started testing those variables more deliberately, and five findings stood out.

1. Agents need finely tuned context

Our first instinct was to give the agent as much information as possible. The results moved in the opposite direction.

A raw build log can contain thousands of lines covering environment setup, dependency installation, test output, retries, warnings, and other execution details. Most of that information has little bearing on the failure the agent is trying to diagnose.

When we removed about 99% of the log content, the rate of fixes that took the wrong approach fell from 48% to 18%.

The experiment also showed that context placement mattered. Adding git context as a file did not improve performance, but putting the same information directly into the message produced our strongest run at that point. The share of fixes that followed project conventions increased from 59% to 90%.

For teams building agent workflows, context is worth treating as an input you design and evaluate. Test what information you provide, how much you provide, and where the agent encounters it.

2. Keep the tool set focused

Better context improved performance, so we tested whether giving the agent more capabilities would help further. We added skills, forced reasoning steps, and a much larger set of MCP tools.

More capability did not consistently produce better results. Added skills used about 24% more tokens without improving quality, and forced workflow steps reduced fix rates in our tests. In our largest MCP test, the server exposed 138 tools for the agent to choose from. The agent consistently relied on just 10 of them, less than 10% of the available tool set.

A developer who knows a product can navigate a broad API surface and choose the right endpoint. An agent has to select among MCP tools based on their names, descriptions, and the context available to it. Exposing every underlying API capability as a separate tool can make that choice harder without helping the agent complete the task.

For teams designing MCP servers and other agent interfaces, start with the actions required to complete the job. Add tools when testing shows that the additional capability improves performance.

3. Evaluate the result you want to ship

One of our early evaluation criteria was simple: did the agent make the build pass?

A passing build turned out to be an incomplete measure. An agent can turn CI green by increasing a timeout, loosening an assertion, excluding a failing package, or changing the failing test instead of fixing the code that caused the failure.

We started measuring merge quality separately from fix rate: not only whether CI passed, but whether the proposed fix was good enough to merge.

The benchmark exposed a meaningful gap: about 90% of fixes made CI pass, but only about 77% met our merge-quality bar. A green build alone was not always a sufficient measure of success.

The same evaluation problem applies to other agent systems. Intermediate metrics are useful, but the final evaluation needs to represent the outcome the user would accept.

4. Test the same task more than once

Changing the evaluation criteria also exposed variation between repeated runs.

The agent usually diagnosed the problem correctly, but the same failure did not always produce the same quality of fix. Incomplete changes and fixes that expanded beyond the required scope accounted for much of the variation.

Across repeated benchmark runs, 27% of cases flipped between pass and fail.

Clearer task boundaries helped reduce some of the variation. When the requested scope was narrow and explicit, the agent had less room to make unrelated changes or expand the solution beyond the failure.

For teams evaluating agent workflows, repeat the same tasks and look at the distribution of outcomes. A strong average can hide variation that matters when the system is used repeatedly.

5. Give agents direct access to product data

Cleaner inputs helped once the agent had the information it needed. We also found that agents spent a significant part of each run obtaining and moving information before they could work on the fix.

CircleCI already has much of what an agent needs to begin: which workflow failed, which job produced the error, which commit was running, what tests failed, and what happened during execution.

In our testing, only 20–30% of a run was spent reading the error and editing code. The rest included surrounding work such as exploring the repository, working with git, and moving information between systems.

Longer feedback loops also added measurable cost. In one iterative experiment, runtime increased from about 10 to 20 minutes and token usage from 2.4M to 3.6M as the agent kept working toward a passing result.

For teams adding agent access to an existing product, look closely at the information your product already has when an agent begins a task. Direct access can reduce the searching and reconstruction the agent would otherwise need to perform itself.

How we’re improving agent experience at CircleCI

Across the experiments, we eventually reached a point where a capable model could turn CI green on roughly nine in ten benchmark cases: 90% in one run and 84% in the repeat.

Reaching that level required substantial experimentation with context, tools, evaluation, and feedback loops. About 77% of benchmark fixes met our merge-quality bar, but production usage showed that developers wanted to stay closer to the fixing process, and the share of fixes they actually merged remained much lower than we wanted.

Those findings shaped the AX work we’re shipping now. We’re taking what made the fixer effective and building it into interfaces that give developers’ chosen agents first-class access to CircleCI data and actions.

A lot of the infrastructure behind the new experience is new or substantially rewritten, and we’re rolling out improvements on a daily cadence.

Recent changes include:

• A ground-up rewrite of the CircleCI CLI for developers and agents, with predictable JSON, stable exit behavior, agent-readable errors, and a built-in MCP server.

• circleci run get --failure-report, which gives agents condensed failure diagnostics instead of requiring them to work through complete build logs.

• Copy Fix Prompt, which packages the relevant CircleCI failure context into a prompt developers can paste into the coding agent they already use.

• Expanded MCP tools for inspecting runs, jobs, build output, and test results and taking CI actions from an agent’s development environment.

• OAuth 2.0 with Dynamic Client Registration and PKCE, giving local tools and agent integrations a standard way to request CircleCI API access without a manually provisioned client secret.

The new Copy Fix Prompt option is one of the ways we’re making CircleCI more friendly to agentic workflows.

The details are still moving as we put these interfaces in front of more real agent workflows. Our goal is to improve both sides of the experience: help agents diagnose and fix CI problems well, while giving developers the visibility and control they need to work with those fixes.

You can try the current fixing flow from any failing CircleCI workflow:

• Install the new CircleCI CLI: brew install circleci

• Run circleci run get --failure-report on a failing run to get condensed diagnostics for your local agent

• Or use Copy Fix Prompt from a failing workflow for a manual handoff

• Need to sign up? Run circleci onboard from the CLI to get started, or create a free CircleCI account from our signup page.

The biggest lesson from our testing is that agent experience is shaped by far more than the model. Context, tool design, evaluation, repeatability, and direct access to product data all changed how reliably agents could work with CircleCI. For teams building for agents, AX means designing those surrounding systems as deliberately as you design the product experience for people.

Yesterday, we published our Q2 Pulse report, a follow-up to our annual State of Software Delivery that digs into a question engineering leaders are running into everywhere: why do some teams turn AI-generated code into shipped software while others watch feature branches pile up?

AI has made writing code cheaper and faster than ever. Every team we look at is generating more of it than they were a year ago. But the data keeps showing the same split: code volume is up almost everywhere. Shipped changes are not.

The bottleneck is validation. A change goes out, a pipeline takes several minutes to run, something fails, and the cycle restarts before anything merges into main. Each round trip drains both engineering time and delivery budget. In our previous issue, we modeled how a 50-developer team can spend close to $900,000 a year on avoidable validation cycles, driven by repeat CI runs and the tokens agents spend reloading context after slow feedback breaks the flow.

The most productive teams are pulling away because they ship in fewer cycles. That lifts individual and team velocity while driving down the cost of each change. In our Q2 Pulse report, we went behind the scenes with the most productive organizations on CircleCI to isolate the habits that help them break the delivery bottleneck without breaking the bank. Below, we’ll share three of them.

The teams setting the pace

The cohort we studied includes 20 anonymized organizations with the highest main-branch throughput on our platform. They span sizes, regions, and industries, with a concentration in security and developer tooling and additional representation from fintech, e-commerce, logistics, and energy.

As a group, they run an average of 2,165 production-branch workflows every day, a 72% jump from a year ago. That builds on the AI-driven volume surge we flagged in our Q1 report, when average daily workflow runs across CircleCI were up 59% year over year. The new finding is sharper: among the teams pushing hardest, increased activity is translating into dramatically higher production-branch throughput.

The gap between these teams and everyone else is widening. Across the platform, the most productive teams now ship roughly 9x the validated code of a typical team, up from 8x just a quarter ago. Their operational advantage comes down to three distinct habits.

Habit 1: Every engineer ships more finished work

The most productive teams get more production-ready work through the system per contributor. We measure this as main-branch workflows per contributor per day: a practical signal for how often validated work is reaching the production branch.

On a typical team, that comes out to about 1 main-branch workflow per contributor per day. Among high performers, it’s closer to 3. Among the 20 most productive teams, it’s around 12. That puts them at more than 10x the output of a typical team. It also shows how quickly the bar is rising: this same set of elite teams has nearly doubled per-contributor throughput in just one year.

High per-contributor throughput is the natural result of a delivery system built around frequent integration. Branches stay short-lived, validation runs continuously, and changes do not sit for days waiting on review or late-stage cleanup.

Frequent integration matters even more with AI in the loop. As more code enters the system, the teams that pull ahead are the ones that can move changes quickly from generation to validation to merge.

Habit 2: Validation runs beyond the manual push

The mechanics behind high volume become clear when looking at how top teams trigger validation. Engineers are not manually pushing code every single time they need to find out whether something works.

Most teams only run CI when someone pushes code, and the median team triggers nearly 100% of its pipelines that way. The most productive teams do not:

• Direct pushes: Account for only about 68% of their triggers.

• Automated triggers: The remaining 32% comes from scheduled runs, API calls, dependency-update checks, and post-deploy verification.

Their CI keeps validating the codebase and deployment lifecycle even after devs have closed their laptops.

A broader trigger mix gives teams more places to catch problems, from dependency health to release verification. Done well, it can also keep push-driven feedback focused on the change a developer is trying to merge, instead of mixing that signal with unrelated failures that could have been caught elsewhere.

Habit 3: Fewer validation cycles per shipped change

Throughput and automation drive volume. Efficiency keeps that volume affordable.

We track efficiency with a metric called Merge Efficiency Ratio, or MER: the number of feature-branch workflow runs for every workflow that runs on main. A high MER means work takes more rounds of pre-merge validation before it’s ready.

Every extra feature-branch cycle means more compute spent validating the same change. In an agentic workflow, it can also mean more tokens spent reloading context and generating fixes each time a slow run reports back. A team can ship a lot and still bleed money if every change takes five or six cycles to ship. The most productive teams keep cycles low, so their higher volume moves into production without a runaway bill behind it.

Less waiting, more shipping

Higher output per engineer, validation beyond the push, and fewer cycles per change all point to the same operating principle: the best teams reduce the distance between writing code, validating it, and merging it.

That is how more code turns into more shipped software. Feedback stays fast, branches stay short, and changes reach production instead of piling up. Just as important, the cost per change goes down instead of up.

The full Q2 Pulse report lays out the cohort behind the numbers, the implementation patterns behind each habit, and what it costs to operate at this level.

Read the Q2 Pulse report →

The report focuses on the operating model behind high-throughput teams. Chunk is one practical way to start applying the same principle: move routine validation out of the slow CI loop and into the moment code is being written.

Chunk sidecars run validation in the inner loop, right alongside your agent, so lint failures, broken tests, and syntax errors get caught in seconds while the context is still warm, instead of after a five-minute round trip through CI. In our own testing, microbuilds delivered feedback with up to 30x less compute usage than a full pipeline run and about 5x fewer tokens.

Chunk sidecars are available now, free on every CircleCI plan. One command gets you started: brew install CircleCI-Public/circleci/chunk

Read the five-minute setup guide →

Earlier this year, the conversation in software was all about maximizing agent output. Tokenmaxxing. Jensen Huang telling engineers to spend $250K a year on tokens. Every benchmark was about throughput: how much code could your AI generate per hour?

That mood has shifted fast.

Uber reportedly used its entire 2026 AI coding tools budget in four months. Microsoft started pulling back internal Claude Code licenses. Amazon just scrapped an internal AI leaderboard after employees started running up token costs to climb the rankings instead of shipping useful work. Across the industry, orgs are staring at massive AI bills and wondering where the ROI went.

In our recent research, we found a big part of the answer: teams are generating changes faster than ever but struggling to validate and ship them at the same pace. The delta between code written and code in production has never been wider, and it carries a hefty price tag.

In this issue, we’re digging into why teams are paying more than they should to move code into production. We’ll preview some new findings from an upcoming update to our State of Software Delivery report, show how moving validation into the inner loop of local, agent-driven development can dramatically reduce delivery time and cost, and give you practical steps to get started.

Merge efficiency (and why it matters)

One of the most interesting findings from the recent State of Software Delivery was that median throughput increased 15% on feature branches but declined 7% on main branches. AI makes writing code trivial, but it adds complexity downstream when those changes hit the shared codebase.

We wanted to dig into what that burden actually looks like for a typical team. How many cycles does it take to get a piece of code into production?

To find out, we looked at the ratio of feature branch runs to main branch runs across CircleCI in March 2026. This gives us an imperfect but directionally useful proxy for the total CI overhead required to ship a single change.

Here’s what we found:

• For the median org, every main branch workflow is accompanied by 3.9 workflow runs on a feature branch. At the mean, that number rises to 8.6. At the p95 level, it rises to 23.7.

• Using main branch workflows as a rough proxy for a merged change, that means every production deploy requires 5+ total CI runs (~4 on the feature branch and 1 on main) to complete.

• Main branch workflows also fail 20-30% of the time, adding at least one more cycle when they do.

In a human-paced development context, these numbers wouldn’t be terrible. A developer pushes a change, waits a few minutes for feedback, and iterates through a couple of build-test-fix cycles before merging to main and wrapping up the workday. That’s how you get to the canonical advice that “everyone pushes to main daily.”

In an agentic world, merge efficiency matters a lot more. When full CI runs take 5-10 minutes to deliver feedback, the agent loses context. Fixing the failure means starting a new cycle: reloading context, re-examining the change, potentially redoing work that was already completed.

That not only derails productivity but also creates massive cost inefficiencies. At 5+ CI runs for every shipped change, the math gets dire quickly.

Where costs pile up

Let’s make this concrete.

Imagine an AI agent is tasked with adding a new feature to a medium-sized codebase. The full repository context, including system instructions, tool definitions, and source files, comes to about 200,000 tokens.

Modern frontier models use prompt caching to make reading massive contexts affordable. The first time the agent reads your codebase, it’s a “cold write” at a premium price. On Opus 4.7, the cost is $6.25 per million tokens. On subsequent steps, the model reads from a warm cache at a 90% discount: just $0.50 per million tokens.

But (as usual) there’s a catch: prompt caches expire after about 5 minutes of inactivity.

Here’s how that plays out in a typical delivery workflow:

1. The agent loads the codebase (200,000 tokens) and generates the code change. API cost: ~$1.28 (plus output tokens).

2. The agent pushes the change, triggering a CI pipeline. The CI platform queues the job, spins up a fresh VM, pulls dependencies, compiles the project, and runs the full test suite. The pipeline consumes about 5 minutes of billable compute across its parallel jobs. But the total round trip from push to feedback, including queue time and provisioning, stretches well past the 5-minute mark.

3. The prompt cache goes cold. By the time CI reports back, the cache window has closed. The cache is wiped.

4. The build fails on a minor syntax error. The agent needs to fix it, but the cache is gone. It pays the full cold-write price to reload the codebase, and the context has grown: the previous attempt’s output and the CI build logs have pushed it from 200,000 to roughly 230,000 tokens. API cost: ~$1.44. Then the agent regenerates the fix from scratch, burning another round of output tokens at $25 per million.

5. The agent pushes the fix. Your CI provider spins up another fresh environment and runs the full suite again. Another 5 minutes of billable compute.

The merge efficiency data shows it takes an average of 5+ total CI runs to ship a single change. And with each cycle, the context grows: the agent retains the full session history, so each retry passes the original codebase plus every previous attempt along with its CI build logs. By run 5, input context can double.

In this scenario, input tokens that should cost under $2 with a warm cache balloon to over $13 across 5 cold reloads, purely because the feedback loop is slower than the agent’s cache. Add output token rework at $25 per million and $1-3 in CI compute, and the total cost per change runs to around $25.

Now imagine this at scale. A 50-developer team at agentic pace ships about 3,000 changes a month (roughly 3 per developer per working day). At ~5 CI runs per change, that’s 15,000 pipeline runs and nearly $1 million per year in token and compute costs. At 500K tokens (common for larger production codebases), it crosses $1.5 million. And with the continued increases in change volume that our data shows, those numbers climb every quarter.

Most of that spend is going to cycles that shouldn’t exist.

Validation in the inner loop

Scenarios like this play out because all of the validation is happening in the outer loop: CI pipelines, shared infrastructure, billable compute. CI is the right place to catch integration failures, security issues, and anything that requires a full environment. But when a syntax error or a failing unit test has to round-trip through a full pipeline run before your agent gets the signal, you can quickly accumulate a ton of unnecessary costs.

What if those cheap failures could be caught earlier, before they ever reach CI? The way to do that is to move validation into the inner loop, where agents iterate locally before the push.

In a healthy system, the inner loop handles the basic checks so the outer loop only runs on code that’s ready for deeper validation. Without a quality gate before the push, your outer loop becomes a bottleneck: flooded with changes, catching failures that range from trivial to critical, burning compute and tokens on every cycle.

The path forward is to raise the quality bar in the inner loop. Validate before the push. Catch the lint failures, the broken tests, the syntax errors while the agent still has context and the fix costs almost nothing.

Introducing Chunk sidecars

Moving validation into the inner loop means having an environment that can run real checks fast enough for an agent to act on the results. To get there, we recently released Chunk sidecars: sandbox environments spun up by the Chunk CLI that mirror your CI stack.

Rather than waiting for a full pipeline run to surface a failing unit test or a syntax error, the sidecar runs the validation checks you’ve configured: linting, unit tests, build validation, or whatever your stack requires. Failure feedback comes back to the agent while it still has context. The agent fixes the issue and the hook fires again, repeating until the checks pass and the change is ready to push.

This keeps the feedback loop tight enough that agents never lose context between a failure and its fix. To measure what that’s actually worth, we took real failures from the chunk-cli CI pipeline and ran them two ways: through CI as normal, and through Chunk sidecars using microbuilds. We measured compute time and token consumption across four pipelines with warm snapshots.

Here’s how those numbers affect the costs we saw in the scenario introduced earlier:

• Input tokens: $13 → under $2. The 27-second feedback time keeps the agent inside the 5-minute cache window. Five cold reloads become one cold load plus four warm cache reads.

• Output tokens: 5 full regenerations → targeted fixes. The agent gets a focused failure signal instead of a full CI log dump, so it applies a small fix instead of rebuilding context and regenerating the entire change.

• CI compute: 5+ runs → 1–2. Fifteen to twenty minutes of billable compute per change drops to a single pipeline run on code that has already passed its checks.

The change that was costing ~$25 in tokens and compute drops to around $6. For the 50-person team from our model, that takes annual token and compute costs from approximately $900k to around $200k. Total savings for a 50-person team: $700k or more.

Stop wasting your delivery dollars

Concerns over runaway AI spend are volume problems at their core. When you scale agentic workflows without changing the feedback architecture underneath them, costs accumulate with every additional change.

Teams who have closed this loop are already separating from the pack, and that difference is widening every quarter.

If you want more return on every token and every pipeline run, look at where your validation is actually catching failures today. If most of them are happening in CI, after a push, there’s a better way.

Chunk sidecars are available now on all CircleCI plans, including free. Install the Chunk CLI with brew install CircleCI-Public/circleci/chunk, run chunk init in your project, and start a sidecar session from your agent. The setup takes minutes, and the savings start on the first build.

Subscribe now

You can tell a lot about a developer from the tools they use. Editor, OS, language, framework. Everyone has a side, and everyone is a little suspicious of the other side’s choices. Version control is no exception. Ask a GitHub team and a GitLab team how they ship software, and you will get two pretty different descriptions of what normal looks like.

But do these preferences (and their downstream impacts) actually show up in delivery metrics? Each VCS attracts a certain kind of team, and each platform builds features to reinforce those tendencies. If teams really do self-select based on their priorities, then those priorities should show up in the delivery data.

In this issue of Confident Commit, we break down data from our most recent State of Software Delivery by code hosting platform to find out.

The evolving source of truth

Git has been the foundation of collaborative software development since Linus Torvalds created it in 2005 to manage the Linux kernel. It quickly became the industry standard, displacing older centralized systems like Subversion and CVS.

Hosting platforms arrived shortly after to enable team collaboration at scale. GitHub launched in 2008, Bitbucket the same year (acquired by Atlassian in 2010), and GitLab in 2011. Between them, these three cover the vast majority of professional engineering teams today.

Despite sharing the same underlying technology, these platforms evolved to serve different kinds of teams and workflows, making unique design choices along the way:

• GitHub is built around pull-request-driven social coding, making it the natural home for high-velocity, branch-heavy workflows.

• Bitbucket is tightly coupled to Jira and the Atlassian suite, attracting teams that prioritize rigorous change management and cross-functional visibility.

• GitLab serves as an integrated, governance-first platform appealing to teams that require strict, centralized control over security and compliance.

Given those philosophies, you would expect GitHub teams to iterate fastest, while Bitbucket teams move with more deliberate enterprise ceremony. GitLab teams, often working in complex and regulated environments, should land somewhere in between.

CircleCI integrates with all three platforms, so we can test those expectations directly to see if they hold up. Let’s take a look at how the hosting platforms stack up across the four key software delivery metrics.

Duration: how long is the feedback loop?

Duration measures the time from when a pipeline starts to when it finishes and determines how long a developer waits to find out whether a change passed or failed. Teams optimizing for rapid iteration want this number as low as possible. Teams running deeper validation, with more extensive tests and approval gates, accept longer durations in exchange for higher confidence in what they ship.

Workflow duration is generally consistent across all three platforms. At the median, the three cohorts are within a few seconds of each other: GitHub at 2m 58s, GitLab at 3m 4s, and Bitbucket at 2m 58s.

GitLab teams running slightly longer workflows is consistent with the hypothesis that these teams run governance-heavy pipelines, but the overall story here is similarity rather than divergence. Even at p90, pipeline durations are closely clustered at 493, 489, and 484 minutes respectively.

Throughput: how much is moving through the pipeline?

Throughput is the number of workflows a team runs per day. It can reveal how actively a team is pushing changes, and is often used as a directional indicator of team productivity.

Looking across all branches, Bitbucket teams run 1.71 workflows per day, while GitHub teams run 2.25 and GitLab teams 2.55.

But the branch-level breakdown is where the numbers get interesting. Throughput on feature branches tells a story about iteration speed: how often developers are committing, running CI, and testing changes before they are ready to merge. On the main branch, throughput is a proxy for how often code moves toward production. Given what we know about each platform’s user base, you would expect GitHub teams, as the most iteration-focused cohort, to lead on throughput.

As expected, GitHub is the runaway leader on feature branches at 3.39 workflows per day versus 2.52 for GitLab and 1.71 for BitBucket. This makes sense considering GitHub’s user base skews toward smaller teams, open-source projects, and startups that prioritize iteration speed over formal approval processes.

But on the main branch, GitLab teams run the most workflows at 2 per day compared to 1.68 for GitHub and 1 for BitBucket. While this runs contrary to what we might first expect, the finding is consistent with previous research we’ve done showing compliance-heavy teams shipping more frequently but hitting friction in other areas of the SDLC (more on that below).

Success rate: how healthy is the path to production?

Success rate is the percentage of workflow runs that complete successfully. The default branch is where this metric matters most. Teams with efficient delivery processes catch errors locally or on feature branches before merging, so a high success rate on main is a signal that the upstream process is working.

Average success rate on main-branch workflows is highest for Bitbucket teams at 73.7% and falls to 70.6% for GitHub and 61.3% for GitLab.

Bitbucket teams running the fewest pipelines but passing more of them is consistent with a stability-leaning culture where more review happens before a merge. GitHub sits in the middle, reflecting a culture comfortable operating at tempo while keeping things green. GitLab’s lower success rate likely reflects the complexity of the environments these teams operate in, something the recovery data makes even clearer.

Time to recovery: how long until you’re back to green?

Time to recovery measures resilience: how long it takes to fix a broken build and get back to a successful state.

Across all branches, GitHub teams recover in 72 minutes, Bitbucket in 80, and GitLab in 124.

On the main branch specifically, those differences are magnified: GitHub teams recover in under an hour, BitBucket teams take about 80 minutes, and GitLab teams require nearly 8 hours to get back to green.

This may seem like a large delta. However, these results are consistent with what we’ve seen previously regarding high complexity, compliance-heavy workflows. When things go sideways on main in a complex environment, the need for more extensive root cause analysis, documentation, and verification before merging a fix can add significant time to the recovery process.

Of all four metrics, time to recovery is where the self-selection pattern shows up most dramatically. The teams who chose the governance-first platform are the ones paying the governance tax on recovery.

What did we learn?

While impactful, tool choices alone are never the determining factor for how a team performs. Most of that comes down to experience, engineering vision, processes, and how you use the tools at your disposal. But it’s also true that teams gravitate toward the tools that map to their way of doing things, and over time, those choices become part of a team’s identity.

Each cohort’s delivery performance aligns closely with what their platform was designed to support. Teams self-select into the tool that matches their priorities, and those same priorities show up in the data.

• GitHub teams prioritize velocity: more feature branch workflows, faster iteration, quicker recovery. This tracks with GitHub’s pull-request-driven culture where branching is cheap, experimentation is encouraged, and speed matters more than gating every change.

• Bitbucket teams prioritize stability: fewer workflows, highest success rate on main. The Atlassian ecosystem emphasizes structured workflows and cross-functional coordination. Teams catch more issues before merge, but that deliberation costs iteration tempo.

• GitLab teams prioritize governance: most main-branch workflows, longest recovery times. This reflects GitLab’s governance-first design. Teams in regulated environments often ship frequently despite their additional constraints, but when things break, the overhead of meeting compliance requirements extends recovery.

Each platform attracts teams with different priorities, and those priorities shape delivery outcomes. So while your VCS doesn’t determine your delivery destiny, it does reflect the outcomes you’re optimizing for.

Go deeper

VCS choice is one way to see how different choices and team characteristics shape delivery performance. The 2026 State of Software Delivery takes a deeper look at what drives these differences, cutting the same metrics by team size, industry, and geography to show how delivery patterns shift depending on who you are, where you are, and what you are building.

Download the report to see the full analysis, or explore the data and benchmark your team against similar organizations in the interactive Software Delivery Data Explorer. The more you understand about how teams like yours ship, the easier it is to know what to optimize next.

Subscribe now

The 2026 State of Software Delivery found the largest year-over-year increase in throughput ever recorded. Workflow volume is up 59%, but on the flip side, main branch activity is falling. Teams are generating a lot more code, but most are struggling to turn that activity into shipped software.

How the AI delivery bottleneck affects your team has as much to do with your specific business requirements as it does your ability to integrate AI into your workflows. Breaking down the delivery data by industry, then, can give us useful insights into different ways the problem shows up and what teams like yours are doing to solve it.

In this issue of The Confident Commit, we’re looking at three industries that stand out in this year’s data, each for unique reasons: civil engineering, utilities, and retail. We’ll break down what each one is doing well, where they’re still falling short, and what their results can tell you about closing the gap between code generation and code delivery on your own team.

Civil engineering

Civil engineering teams validate more changes per day than any other industry. The typical project triggers 9.9 workflows every day, nearly 6x the median result across the entire dataset. On feature branches, where developers build and test new work before it’s ready for production, activity is 6.8 workflows per day.

That high volume likely reflects how civil engineering projects are structured: multiple parallel workstreams across structural, mechanical, electrical, and site systems, each being developed simultaneously. But the picture changes when you look at the main branch, where code actually ships to production. Throughput there drops to 1.8, right in line with what most teams run.

That’s a clear illustration of the AI bottleneck in action. These teams are generating massive amounts of code, but they are paying a heavy integration tax. Their complex, interconnected systems have to be validated against each other before anything can ship. That takes time, and it doesn’t scale linearly with volume.

Given the quality and compliance constraints in this vertical, a bottleneck at the integration stage makes sense. But it also means that despite having the highest overall throughput of any industry, civil engineering’s internal velocity rarely translates into faster project delivery

Utilities

So what does it look like when a team actually breaks through the production bottleneck?

Utilities teams run 7.6 workflows per day on feature branches and 7.8 on main. Both numbers are about 4x the current global median and represent a more than 2x year-over-year increase for this vertical. But what’s especially notable is that activity on main is keeping pace with feature branches. Where civil engineering teams are increasing code volume but struggling to integrate it, utilities teams are writing and shipping more code.

One possible explanation is business pressure. Utilities are critical infrastructure. Grid management, outage response, and regulatory reporting can’t wait. That urgency may push teams to ship smaller, more isolated changes that integrate cleanly rather than letting work pile up on feature branches. Civil engineering projects operate on longer timelines with less immediate consequence for any individual change, which may explain why parallel workstreams pile up and create integration complexity at main.

Whatever the reason, the data shows that utilities teams are shipping code as fast as they write it. But that’s not the complete story.

Utilities teams take approximately 400 minutes to recover from a failed build on main, compared to a global median of just 59 minutes. When something fails in a high-stakes pipeline, formal investigation steps take priority over speed regardless of how fast your CI system can rerun a build. But for a critical service that people depend on, almost 7 hours of blocked deployments has real consequences.

Retail

Like utilities, retail teams depend on 24/7 availability for their customers. While downtime for a retailer may not carry the same consequences as a utility outage, the impact on revenue and customer sentiment can be massive. That pressure has pushed retailers to optimize for uptime and fast recovery.

The typical retail team recovers from a failed build on main in 20 minutes. Most non-retail teams take 60 minutes or more.

Not only does retail recover the fastest, but it’s also among the top performers on success rates. Retail workflows running on main succeed 85.2% of the time, placing them fifth among all industries. With these two metrics combined, retail is the strongest all-around performer on the metrics that matter most for reliability.

Banking tells a similar story. The typical banking team recovers from a failed build in 41 minutes, second only to retail, and maintains an 80.1% success rate on main. What retail and banking have in common is that the business cost of downtime makes recovery speed an organizational priority, not just an engineering goal. For these teams, MTTR is a financial metric.

What this means for your team

Each of these industries has optimized for the thing their business pressure demands and accepted a tradeoff elsewhere. Civil engineering iterates at massive volume but ships to production at an average pace. Utilities ships to production at a very high rate, but recovery takes nearly seven hours when something breaks. Retail recovers faster than any other industry because the revenue impact of downtime made it an organizational priority.

The question for your team is which of these dimensions is actually constraining you right now. If your feature branches are active but production is flat, you have a throughput-to-production problem, the same one civil engineering is paying for at scale. If your success rate is below 80%, you’re burning engineering time and tokens on failures that stack up with every change you generate. If recovery takes more than an hour, every failure blocks not just the build that broke but everything behind it in the queue.

This is what we’re building autonomous validation to solve: faster feedback, deeper context across your build history, and the ability to automatically resolve common failures before they turn into 400-minute recovery stalls or integration bottlenecks that keep code from reaching customers.

See where your team stands

The full 2026 State of Software Delivery breaks down performance by industry, region, and team size.

Want to benchmark your own metrics against these industries? The Software Delivery Data Explorer lets you compare your throughput, success rate, duration, and recovery time against teams in your specific segment.

Ready to start closing the gap between generation and delivery? CircleCI is free to get started.

Subscribe now

In our last issue, we shared a preview of data from our upcoming 2026 State of Software Delivery showing that the promised AI productivity boom isn’t all hype. Throughput across the CircleCI platform increased 59% year-over-year, by far the largest productivity jump we’ve ever recorded and a clear indication that AI-assisted coding is driving massive increases in change volume.

But the gains weren’t evenly distributed. The top 5% of teams nearly doubled their output, while the median team improved by just 4%.

Since then, we’ve released the full report. Alongside it, we launched the CircleCI Software Delivery Data Explorer, an interactive tool built on tens of millions of real CircleCI workflows that lets you benchmark your team’s throughput, duration, success rate, and MTTR against peers in your industry, region, or team size.

In this issue, we’re digging deeper into the performance divide we called out last time. What’s actually driving this separation, and what can you do about it?

The branch data tells the real story

To understand what’s causing the AI performance gap, it helps to know a little about how modern software gets built.

When a developer starts on something new, they typically don’t write code directly into the main codebase. They create a separate copy called a branch, a safe workspace where they can build and test without affecting anything in production or blocking their team from shipping other changes. When the work is done and the code passes automated checks, it gets reviewed and merged back into that main codebase, where it can be deployed to users.

Those two events mean very different things. Activity on feature branches tells you developers are working. Activity on the main branch tells you software is shipping. When you split the throughput data along those lines, the picture changes considerably.

For the top 5% of teams, throughput increased 26% on the main branch and 85% on feature branches between 2024 and 2025. Why is the jump so much bigger on feature branches? Because AI is particularly well-suited to the work that happens there: working out complex problems quickly, spinning up prototypes, and iterating quickly until the approach is right.

But the most important story is the increase in activity on main. Top performers are generating and shipping significantly more than they were just one year ago. That’s what it looks like when AI acceleration runs all the way through the delivery pipeline.

For everyone else, the picture is different. Teams in the top 10% saw feature branch throughput rise nearly 50%, but main branch activity was essentially flat at 1%.

And at the median, feature branch activity was up 15%, while main branch throughput actually declined by 7%.

In other words, the typical software team got marginally better at generating changes last year, but they got worse at getting those changes into customers’ hands.

For any business leader, a regression in the organization’s ability to deliver value is going to set off alarm bells. So what’s behind it? The short answer is that AI has made it significantly easier to write code, but the process of integrating that code into a production system involves a different set of challenges. And those challenges get harder, not easier, as the volume of incoming changes goes up.

Why AI-generated code is harder to land

It’s easy to say “integration is the bottleneck” and leave it there. But there are several distinct places between a developer finishing a piece of code and that code reaching production where things can slow down or break, and AI is putting pressure on all of them.

The first place AI generated changes run into trouble is code review. Most teams still require proposed changes to pass a manual review before they can be merged, and AI is making that queue harder to manage on two dimensions: volume and complexity.

We’ve already shown that AI is driving big increases in code activity for teams across the board. Those changes are not only happening more frequently, they’re also larger, denser, and touch more of the codebase than a human would in the same pass. Research by Faros AI and others has shown that AI adoption increases the size of pull requests by more than 150% on average.

What this means is that senior engineers tasked with reviewing AI-generated pull requests are facing an ever-growing review queue that is more difficult than ever to process. And they’re reporting all kinds of negative effects from it, from feelings of overwork and burnout to the tendency to take shortcuts and skim potentially risky code.

While the former is a serious risk to employee wellbeing and business continuity, only the latter is measurable in delivery data. And the impact is hard to ignore. Main branch success rates fell to 70.8% this year, the lowest in over five years and well below the 90% benchmark that indicates a healthy pipeline.

Roughly 3 in 10 attempts to merge changes into production are now failing, and when the main branch breaks, nothing else can ship until it’s fixed.

That brings us to a third place AI code tends to get stuck: fixing it when it breaks. Recovery times for failed builds have been climbing since AI-assisted development went mainstream in 2022. This year, the typical team takes 72 minutes to get back to green, a 13% increase from the previous year.

Recovery times have been getting longer as teams incorporate more AI-generated code into their workflows. The same challenges that slow down manual review – PR size and complexity – also make failures harder to diagnose. Larger changes create more places for bugs to hide. And when something breaks in code a model generated, the developer debugging it often has little intuition for why it was written the way it was or what it might have affected downstream.

CI/CD has to keep up

In a recent newsletter, we made the case for autonomous validation as the next evolution of CI/CD. The data in this report is the clearest argument yet for why that evolution is necessary.

The AI choke points we described are all symptoms of the same underlying weakness: delivery infrastructure built for a world where humans produced code at a human pace. That’s why we’re evolving CircleCI to deliver

• Faster feedback so issues surface while context is still fresh, not after developers have moved on to the next AI-generated change

• Deeper context across your build history, dependencies, configs, and policies to surface risk in AI-generated changes that a diff alone can’t reveal

• Agentic capabilities that can resolve common, repeatable failures autonomously, without pulling an engineer off their work every time a flaky test or dependency conflict blocks the pipeline

When delivery pipelines can’t keep up, AI code is more likely to stall at review, break on merge, and burn engineering time on recovery. By rethinking CI/CD to operate at the same speed and scale as AI development, we’re taking concrete steps to remove the sources of friction that keep most teams from turning AI-generated code into shipped software.

Where do you stand?

If your team is generating more code than ever but struggling to get it across the finish line, you’re not alone. That’s the reality for the majority of teams in this year’s data.

You can learn more in the 2026 State of Software Delivery. It breaks down exactly where things are slowing down and what high performers are doing differently.

Download the report →

Want to see where your own numbers land? The Data Explorer lets you benchmark your delivery metrics against teams in your industry, region, and size band.

Benchmark your team in the Data Explorer →

And when you’re ready to turn all that AI-generated code into shipped software, CircleCI is free to get started.

Start building for free →

Subscribe now