Two things are true about software delivery in 2026, and they are pulling in opposite directions.
The first: AI is now writing a large share of the code that reaches your pipeline.
CloudBees' 2026 State of Code Abundance Report found that AI generates or assists in writing 61% of the average enterprise codebase, and that 81% of enterprise leaders report an increase in production issues tied to AI-generated code.
The same report names a confidence gap worth sitting with: 92% of leaders say they are confident in the production readiness of that code, even as the failures climb (CloudBees, 2026).
The second: the place best positioned to catch those failures, the CI/CD pipeline, is where teams trust AI the least.
JetBrains' TeamCity team reported that 73% of organizations do not use AI in their CI/CD pipelines at all, and 78.2% do not delegate tasks to AI in CI/CD workflows, even though general AI usage in development work exceeds 90%.
When asked why, 60% cited unclear use cases or value, 36% cited a lack of trust in AI-generated results, and 33% cited data privacy concerns (JetBrains TeamCity, 2026).
That is the trust gap.
More machine-written code is arriving, more of it is breaking in production, and the pipeline that should be the safety net is the one room teams will not let automation into.
This piece is about why that hesitation is rational, and what automation has to look like to deserve a different answer.
Why the pipeline is different The JetBrains analysis put its finger on the reason cleanly: development workflows tolerate experimentation because feedback is immediate and cheap.
CI/CD is the opposite.
It demands consistent, reproducible signals, and the cost of an error is high.
A coding assistant that guesses wrong wastes a few seconds of your time.
A pipeline that guesses wrong can hide a real defect, ship it, or erode the one thing a pipeline exists to provide: a trustworthy answer to the question "is this build good?" So the bar for automation in CI/CD is not "is it clever?" It is "can I trust the green check?" That bar is higher than the bar for a code completion, and teams are right to hold it there.
Any honest conversation about AI in delivery has to start by respecting that bar rather than arguing it down.
The cost pressure is real, too The trust question is not happening in a vacuum.
The economics of CI shifted in 2026, and they shifted in a way that makes wasted pipeline minutes more visible than they used to be.
On January 1, 2026, GitHub reduced the price of GitHub-hosted runners by up to 39%, depending on the machine (GitHub Changelog).
Reporting on the change put concrete numbers on it: a 2-core Linux runner moved from $0.008 to $0.006 per minute, and a 64-core ARM64 machine saw the steepest cut, from $0.160 to $0.098 per minute (SamExpert, 2026).
At the same time, GitHub floated a new $0.002 per-minute "cloud platform charge" that would have extended to self-hosted runner usage in private repositories starting March 1,
2026.
The reaction was swift.
Developers objected to paying an orchestration fee on hardware they already own, and within about a week GitHub postponed the self-hosted charge indefinitely, acknowledging it had missed the mark by not consulting users first (SamExpert, 2026).
As one analysis stressed, postponed is not cancelled: the company is re-evaluating, not abandoning, the idea, which is why teams are being advised to model their own self-hosted-to-hosted minute ratios now rather than later (Tenki, 2026).
Put the two pressures together.
Every wasted minute now has a clearer price, and a meaningful slice of pipeline minutes are wasted not on real work but on failures that were never about your code: a flaky network call, a runner that ran out of disk, a missing tool, environment drift between yesterday's build and today's.
Those failures cost money to re-run and cost engineers the time it takes to notice, diagnose, and click "re-run jobs." This is exactly the territory where automation c