Independent reviewers on PeerSpot (peerspot.com/products/incredibuild-reviews) put Incredibuild at an 8.0 out of 10 average across verified user reviews, independent of anything in this piece.
Twenty numbers, pulled from primary sources rather than each other, tell a consistent story: AI-assisted development has pushed code volume up faster than most CI/CD infrastructure was sized for, and the gap is showing up as a measurable cost, not just an engineering annoyance. Some of these stats are about adoption. Some are about what happens once that adoption meets a pipeline that hasn’t changed since 2019. Read together, they explain why build speed has quietly become a board-level line item rather than a platform-team complaint.
Worth being direct about why this matters now specifically. Every number below describes 2025 into 2026, not a hypothetical future. The volume growth already happened; it’s sitting in this year’s Octoverse and Stack Overflow data. What’s still unresolved is whether the infrastructure catches up, and the DORA finding covered further down suggests the industry’s own measurement tools are struggling with the same volume shift the infrastructure is. None of the twenty numbers below required speculation to compile; every one is already published, which is exactly what makes the pattern across them worth taking seriously rather than dismissing as another AI hype cycle.
A quick methodology note: every figure below is attributed to its original publisher, GitHub, Stack Overflow, Microsoft, DORA/Google Cloud, or Incredibuild’s own published survey research, with a link where the source is checkable online. Where a number comes from our own data, it’s labeled as such rather than presented alongside independent research without distinction.
The AI velocity gap, in numbers
1 to 3. GitHub’s own 2025 Octoverse report (github.blog/news-insights/octoverse) puts hard numbers on the volume shift: developers burned through 11.5 billion GitHub Actions minutes running tests that year, up 35% year over year, while merged pull requests grew 23% and total commits rose past the prior year’s pace by a similar margin. None of that growth came with a matching increase in CI compute; it landed on infrastructure sized for the commit volume of two or three years earlier.
4 and 5. Microsoft’s own earnings disclosures track the driver behind that volume directly: GitHub Copilot crossed 20 million all-time users by July 2025, up from 15 million just three months earlier (TechCrunch), and paid subscribers reached 4.7 million by January 2026, up 75% year over year on Microsoft’s own Q2 FY26 earnings call. That’s not a niche tool anymore; it’s a mainstream part of how code gets written, and every one of those users is generating commits a pipeline somewhere has to build.
6 to 8. Stack Overflow’s 2025 Developer Survey (survey.stackoverflow.co/2025) found 84% of developers now use or plan to use AI coding tools, up from 76% the year before, with 51% of professional developers using them daily. The same survey found trust moving the opposite direction: favorable sentiment toward AI tools fell from over 70% in 2023 to 2024 down to 60% in 2025, and 66% of respondents named AI code that’s “almost right, but not quite” as their single biggest frustration with the category.
9. That last number has a direct pipeline consequence. A separate analysis of the same 2025 survey data found 45% of developers reporting that debugging AI-generated code takes longer than debugging their own. Code that’s almost right still runs through the same test suite as code that’s fully wrong. At a volume no pipeline was originally sized for.
10. Widely reported industry estimates place GitHub Copilot’s average contribution at roughly 46% of an active user’s code. Higher on some language stacks. Whatever the precise figure, the direction matches everything above: a shrinking share of what a CI pipeline builds was typed by someone who understands the codebase’s existing coupling. That’s exactly the kind of change that touches more files, more shared headers, more of the dependency graph than an equivalent human-authored change would.
Self-hosted infrastructure feels that volume differently than hosted infrastructure does, and the mechanism is worth naming, not just the number. Executor pools and plugin ecosystems sized for a 40-developer team’s commit rate don’t scale gracefully to 400 developers generating AI-assisted commits at multiples of the old rate. The queue grows first. Then the plugin compatibility surface becomes the second bottleneck, once a team starts patching more aggressively just to keep up.
What DORA’s delivery-performance numbers actually show
11 to 14. The DORA research program, now under Google Cloud, remains the industry’s most-cited source on software delivery performance. Real numbers on how uneven delivery speed still is: only 16.2% of organizations achieve on-demand deployment, multiple times a day. 23.9% deploy less than once a month. Just 9.4% of teams get code from commit to production in under an hour. 43.5% need more than a full week. Elite and low performers aren’t a small gap on a chart. They’re most of the industry, sitting on the slow side of it.
Those four numbers matter more together than any one does alone. A team stuck at monthly deployments and week-plus lead times isn’t failing at CI/CD as a discipline; it’s most of the industry, which is exactly why DORA’s own researchers frame elite performance as the exception worth explaining rather than the baseline worth assuming.
15. The more pointed finding from DORA’s own 2026 research is methodological: at organizations where AI now generates an estimated 30 to 70% of committed code, Deployment Frequency and Lead Time for Changes, two of the four original DORA metrics, are described by DORA’s own team as becoming misleading. When a third to two-thirds of what ships wasn’t typed by a human, the metrics built to measure human delivery cadence stop measuring what they were designed to measure. That’s not a caveat buried in an appendix; it’s a direct statement that the industry’s standard yardstick is bending under the same volume this piece is about.
Common mistakes teams make reading these numbers
The most frequent one: treating deployment frequency as a standalone health metric instead of pairing it with change failure rate. A team deploying on demand with a high failure rate isn’t actually faster in any way that matters; it’s just failing faster. DORA’s own framework pairs throughput and stability metrics for exactly this reason, and reading one column of the report without the other reliably produces the wrong conclusion about a team’s actual performance.
The second: assuming these industry-wide numbers describe your organization specifically. DORA’s benchmarks are aggregated across tens of thousands of respondents. A 43.5% figure for slow lead times doesn’t mean any individual team is average. The number worth tracking is your own trend over time, measured the same way each quarter. Not where a single snapshot lands against a global distribution.
The third: treating adoption statistics (84% using AI tools, 20 million Copilot users) as evidence of a problem solved rather than a problem relocated. Adoption numbers describe how much AI-generated code exists. They say nothing about whether the infrastructure downstream, the CI pipeline, the test suite, the delivery metrics, has caught up to absorb it. Most of the numbers in this piece exist specifically because that catching-up hasn’t happened yet. A team that reads the adoption stats as good news and stops there is the team most likely to be surprised by the build-time and delivery-metric numbers a section later.
How to check whether this is actually your bottleneck
A few reference points, using the numbers above instead of abstractions. Start with your own median lead time against the DORA bands cited earlier. Under an hour is elite territory, 9.4% of the industry. A day to a week is the large middle. Over a week, where 43.5% of organizations actually sit, is where most teams land. Knowing which band you’re in says whether this is a speed problem worth solving or just a normal-range number.
Queue time and compute time get lumped together constantly, and they shouldn’t be. A build that takes 40 minutes because it sat in a queue for 35 of them is a scheduling problem. A build that takes 40 minutes because the compile and link steps themselves take 40 minutes is a compute problem. Different fixes entirely, and most teams never bother splitting the number to find out which one they actually have.
One more thing worth tracking: how much of that 57-minute daily wait (see the build-time figures further down) lands on full rebuilds versus small incremental changes. Concentrated on full rebuilds, a caching layer handles most of it. Spread evenly across small changes too, the real bottleneck is probably test suite time or flaky tests, not compile speed, and the fix looks nothing like the one this piece is about.
The cost nobody puts on a dashboard
16. Our own “Big Dev Build Times” survey research (incredibuild.com/blog) found developers spend an average of 57 minutes a day waiting for builds to finish. Labeled clearly as our own data, not independent research, and worth reading alongside what happens during that wait.
17. What happens during that wait is context switching, and the recovery cost is well documented independent of anything build-related: widely cited productivity research, tracing back to interruption studies out of UC Irvine, puts the average time to fully return to an interrupted task at roughly 23 minutes. A developer who context-switches during even a handful of long builds a day is losing hours, not minutes, to the round trip, and the same body of research found interrupted work carries a higher error rate than uninterrupted work, not just a slower one.
18. A mid-size fintech engineering team we’ve talked with put a number on the compounding effect specifically: they measured a 22-minute average full rebuild before addressing it, and found their own internal survey showed engineers self-reporting roughly two “deep work” interruptions per day tied directly to build waits, not meetings or messages. The specific complicating detail: fixing the interruptions didn’t require fixing the meetings problem everyone assumed was the bigger issue; it required fixing the builds.
Tooling and ecosystem trends worth tracking
19. Container adoption keeps compounding pipeline complexity: Stack Overflow’s 2025 survey recorded a 17-percentage-point jump in Docker usage to 71.1%, the largest single-year gain of any tool in the survey’s history. Containerized build and test steps add real overhead per job, on top of the volume growth already covered above.
20. Jenkins, despite its age, still anchors a large share of enterprise CI: its community plugin ecosystem now tops 2,000 plugins (plugins.jenkins.io), each one a potential compatibility question at every LTS upgrade. On the newer end of the spectrum, JetBrains’ own TeamCity free tier (jetbrains.com/teamcity/download) caps out at three build agents and 100 build configurations, a ceiling teams hit well before they outgrow the rest of their toolchain. Both numbers illustrate the same point from opposite ends of the market: even mature or generous tooling runs into scaling limits once commit volume moves the way the numbers above describe.
Neither limit is a criticism of either product. Jenkins’ plugin depth is exactly what makes it flexible enough to survive two decades of changing build requirements, and TeamCity’s free tier is genuinely generous relative to most competitors. The point these two numbers make together is narrower: tooling built around a given commit-volume assumption eventually meets a team that’s outgrown that assumption, and 2026’s volume numbers make that meeting happen sooner than it used to.
Where the compute layer fits
Every statistic above describes a volume and speed problem. None of them describes a tooling failure exactly, GitHub Actions, Jenkins, DORA’s own framework, and the rest are all doing what they were built to do. What none of them were built to do is stop the same compile, link, or test from being redone across branches, developers, and CI runs, which is the specific thing that turns rising commit volume into rising build time rather than flat build time at higher throughput.
Two categories of fix exist for that specific problem, worth naming before naming any particular product. Caching is the simpler idea: don’t redo identical work. Same inputs, same output, so the second request for it comes back instantly instead of getting recomputed from scratch. Distribution is the other half. Spread work that genuinely does need to run across more machines at once, so it finishes in parallel rather than queueing on a single box. Most tools in this space pick one or the other. The two combined is where the biggest gains in the case studies below actually come from.
On the caching side, sccache and ccache handle compiler-level caching on their own, free and open source, without an organization-wide sharing layer. On the distribution side, distcc and Icecream spread compilation across machines without the caching half. Both are legitimate starting points for a team not ready to adopt a commercial layer, and both stop short of combining the two categories the way the rest of this section describes.
Incredibuild is one implementation of both categories together: the agent installs alongside whichever CI platform and hardware a team already runs, hashes every compile, link, and test task, and either returns a cached result in seconds or distributes the work across idle compute instead of queueing it on one machine. The published results: Adobe cut a build from 7.5 hours to 15 minutes, Cerence went from 15 minutes to seconds, and a financial institution we work with dropped 48-hour compilations to 2 (case studies, incredibuild.com/case-studies). None of those teams changed CI platforms or rewrote a pipeline to get there.
The honest limit, the same way each statistic above has one: this doesn’t touch DORA’s change failure rate, doesn’t reduce Jenkins’ plugin maintenance burden, and doesn’t make an AI-generated pull request more correct. It closes the compute gap specifically. If the actual bottleneck a team is facing is code quality or deployment risk rather than wall-clock build time, these numbers point somewhere else.
A few more scenarios worth naming directly. Serverless or fully ephemeral build runners, spun up fresh per job with no persistent disk, don’t have idle capacity sitting around to distribute onto. Not much room for a cache to live between runs either. This approach depends on machines sticking around long enough to actually share work and results.
Heavily regulated environments, financial services, healthcare, government contracting, often need a lengthy security review before any third-party agent touches build infrastructure at all. That’s true independent of how good the technical fit is. Budget that review timeline separately from the technical rollout; they’re not the same clock.
And a team whose real pain is that 43.5%-of-organizations lead time problem cited earlier, but for process reasons rather than compute ones, approval gates, manual QA sign-off, won’t see that number move here. Doesn’t matter how fast the compile step gets.
Worth being specific about which of the twenty numbers above actually predict whether this helps a given team. High Octoverse-style commit growth plus a build time already measured in tens of minutes (statistics 1 through 3 and 15 to 17) is the strongest signal. A team whose numbers look more like DORA’s change-failure-rate concerns, or whose Jenkins pain is plugin maintenance rather than wait time, is looking at a different problem than the one this section addresses.
Where these numbers are likely headed next
The near-term trend is more of the same: commit volume tied to AI-assisted development shows no sign of plateauing in either the Octoverse or Stack Overflow data, so expect next year’s version of statistics 1 through 9 to be larger, not smaller. Expect the tooling numbers (18 through 20) to keep climbing too; container adoption and plugin ecosystems have grown every year this data has been tracked, with no year showing a reversal.
The more speculative possibility, flagged by DORA’s own researchers rather than by this piece: if AI-authored code keeps climbing toward or past the 70% figure already cited, the industry may need a genuinely different measurement framework, not just adjusted DORA thresholds, since metrics built around human commit cadence may stop being meaningful once most commits aren’t paced by a human at all. That’s a real possibility worth watching, not a prediction to act on today.
Key takeaways
The pattern across all twenty numbers: AI-assisted development has made commit volume grow faster than CI/CD infrastructure, delivery-performance measurement, or developer attention were built to absorb, and the resulting cost shows up as measurable build-wait time and delivery-metric distortion, not just a subjective sense that things feel slower. The adoption numbers (1 through 10) explain why. The DORA numbers (11 through 15) show the industry’s own yardsticks straining under it. The build-time numbers (16 through 18) put a dollar and a minute figure on what that strain costs a single developer’s day. Where the bottleneck is genuinely compute rather than process or quality, a shared cache and distribution layer installed underneath whichever pipeline is already running closes that specific gap; Build Runner Early Access or a free trial is the fastest way to see what that looks like against a real pipeline rather than a statistic.
