Two forces are pulling on delivery pipelines this year.
Code is arriving faster than ever, and the cost of running the pipelines that ship it has been unusually unsettled.
Let us look at both, honestly, and then talk about where reliability work fits.
Pricing was a moving target, and it still is On December 16, 2025, GitHub announced a simpler Actions pricing model that included a new $0.002 per minute "cloud platform charge." The plan was for that charge to reach self-hosted runner usage in private repositories on March 1, 2026 (GitHub Changelog).
The reaction was strong enough that GitHub reversed the self-hosted portion within days.
As GitHub put it, they "missed the mark with this change by not including more of you in our planning," and postponed the self-hosted charge to re-evaluate the approach (GitHub Changelog).
Postponed is not cancelled, so if you run self-hosted runners in private repos, this is worth watching rather than filing away.
GitHub's own framing was that the change would touch a small slice of accounts: it reported that 96% of customers would see no change to their bill, and that of the 4% affected, most would actually see their Actions bill decrease (GitHub Changelog).
Even so, the principle of paying a per-minute fee for software running on hardware you already own was the sticking point for many teams, and the reversal followed quickly.
The other half of the announcement did take effect.
On January 1, 2026, GitHub reduced the price of GitHub-hosted runners by up to 39%, depending on the machine type, while leaving free minute quotas unchanged (GitHub Changelog).
GitHub pointed teams to its runner pricing docs and calculator for the exact per-machine rates rather than publishing a single headline number (GitHub Changelog).
That "up to" is doing real work in the sentence: the reduction depends on which machines you actually use, so the only way to know your number is to look at your own usage mix.
The practical takeaway: the ground under CI budgets shifted twice in a matter of weeks, and part of it is still marked "to be re-evaluated." If you cannot see where your Actions spend goes today, you cannot reason about what any of these changes mean for you tomorrow.
A pricing change you cannot measure is just anxiety.
A pricing change you can measure is a decision.
The faster problem: code is outrunning the pipeline The pricing story is noisy, but the structural story matters more.
AI coding tools have changed how fast code shows up at the pipeline door, and that shift is not going to reverse.
One widely shared framing from Qovery describes teams moving from roughly 1 to 2 deploys per day toward 10 to 20, and argues that "code production happens in hours, but CI/CD, environment provisioning, and deployment pipelines were designed for the old cadence" (Qovery).
Those deploy-frequency figures are Qovery's framing rather than a measured industry benchmark, so treat them as illustration, not gospel.
The same piece cites large-scale examples, such as very high daily build volumes at AI-native companies, and again those are the author's reported numbers rather than something I can independently verify, so I am attributing them and moving on (Qovery).
The direction, though, is hard to argue with: when writing code gets cheaper, the pipeline becomes the constraint.
The bottleneck did not disappear.
It moved downstream, from the keyboard to CI.
This is a classic systems problem.
When you relieve one constraint, the next constraint in line becomes visible.
For a decade the slow step was a human writing and reviewing code.
Now that AI has sped up authoring, the slow steps are the ones nobody optimized because they were never the bottleneck: queue time waiting for a runner, environment setup, dependency installation, flaky retries, and the human minutes lost reconstructing why a build failed.
The trust gap: AI is in the editor, not the pipeline Interestingly, the same AI wave that is flooding pipelines has barely touched