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 the pipelines themselves. In JetBrains' reporting, AI usage in software development now exceeds 90% of the workplace, yet "73% of organizations don't use AI in CI/CD pipelines at all," and in JetBrains' own AI Pulse data 78.2% of respondents do not use AI in CI/CD workflows (JetBrains TeamCity Blog). That is a striking gap. Nearly everyone uses AI to write code. Roughly three quarters of organizations keep it out of the pipeline entirely.
The stated barriers are telling: 60% cite unclear use cases or value, 36% cite lack of trust in AI-generated results, and 33% cite data privacy concerns (JetBrains TeamCity Blog). Read those two facts together. Engineers happily let AI help write code, where mistakes are cheap and reversible, but they hold the line in CI/CD, where a bad automated change can break a release for everyone. As the JetBrains piece frames it, "AI adoption is highest where the cost of mistakes is low." That is not resistance to progress. That is good engineering judgment.
It is worth sitting with the privacy number for a moment. A third of respondents worry about what an AI system sees when it reaches into their pipeline. That concern is rational. CI systems touch secrets, source, and production credentials. Any AI that operates there should be explicit about what it reads and what it does not, and it should be able to state that boundary plainly rather than burying it in a policy page.
What this asks of a CI/CD platform
If the pipeline is now the bottleneck, and if trust is the thing keeping AI out of it, then the useful question is narrow: how do you speed up delivery without asking teams to trust automation that touches production behind their backs?
A few principles fall out of the data above.
Automation should default to proposing, not merging. The privacy and trust concerns in the JetBrains numbers do not go away because a tool is convenient. They go away when a human stays in the loop on anything that changes a workflow or a repository. A pull request is a trust primitive. It is reviewable, it is revertible, and it keeps a person at the point of decision.
Failures should come back as answers, not archaeology. More builds per day means more failures per day, even if your failure rate is flat. The cost of each failure is mostly the time an engineer spends reconstructing what happened from a wall of logs. Cutting that reconstruction time is one of the highest-leverage things a platform can do in an era of 10x more builds.
Environmental failures should not cost human attention at all. A flaky network, a full disk, a runner that ran out of memory: these are not interesting. They are noise. If your best engineers are spending afternoons re-running jobs that failed for reasons that have nothing to do with their code, the pipeline is taxing the wrong people.
Cost has to be legible. After a year of pricing moving twice, "where does our CI spend go" should be a dashboard question, not a spreadsheet project. You cannot manage what you cannot attribute to a repository, a workflow, and a runner.
Where Latchkey fits
I work at Latchkey, so read this section as what we build, not as a neutral survey. I am going to stay careful about claims, because being careful about claims is the entire point of the product.
Latchkey runs your GitHub Actions jobs on managed Linux runners that we provision and tear down for you. Switching a job is a one line change to the runs-on label in your workflow YAML, and for Linux jobs that label is the only change, so the steps and inputs you already use carry over. There is no runner fleet to operate. Each job runs on a fresh, isolated, single-use runner that is destroyed when it finishes, so no state carries between runs. Runners start fast, with jobs picked up in seconds rather than waiting for a machine to boot from scratch, and paid tiers keep pre-warmed capacity standing by. The runner image ships a broad, regularly updated toolchain of languages, build tools, and SDKs preinstalled, so jobs spend less time installing dependencies.
On reliability, Latchkey's self-healing CI targets the failures that waste the most time: the transient and environmental ones. When a step fails on a managed runner because of a flaky network, a full disk, a memory kill, a missing tool, or environment drift, Latchkey detects the failure, diagnoses the cause, applies a fix while the job is still running, and re-runs the failed step. It is built into every runner, with no separate fee. To be clear about the boundary, because it matters: self-healing does not fix bugs in your application code, and it is not a promise of a green build. When the failure is a real defect, a compile error, a failing test, an assertion, that failure passes through unchanged so your tests fail truthfully. For novel build failures that fixed rules do not recognize, an AI agent on the runner investigates, applies a fix from a vetted, bounded action set, and verifies it by re-running the step. When it is not confident, it does nothing, and the original failure stands.
That boundary is the whole point. The JetBrains data says teams do not trust automation that might quietly "fix" the wrong thing, and they are right not to. Latchkey only attempts a fix when it has a high-confidence infrastructure or environment signal, and every attempt is recorded on the dashboard with what failed, what action was taken, and the outcome. Agent heals include the full step-by-step transcript. Nothing happens silently, and self-healing is controlled by a single organization-level toggle that owners and admins can turn off for the whole workspace at any time.
When a failure really is your code, Latchkey hands the work back to you rather than guessing. Through an MCP server, it can give your own coding agent (any MCP-capable agent, such as Claude Code, Cursor, or Codex) a structured failure bundle: the root cause, the exact failing file, the secret-stripped logs, and what self-healing already tried. Your agent makes the fix in your repository, and you review and merge it as usual. This speaks directly to that one-third of teams worried about privacy: consistent with how Latchkey works everywhere, it reads only metadata and never reads or stores your source code, and the API key involved is read-only, so it can never change anything in your repository or account.
And when a fix should be permanent, or when Latchkey has an optimization or caching improvement to suggest, it comes to you as a pull request you review and merge. Repository changes only ever happen through a PR you approve. Migrating a workflow to Latchkey runners works the same way: a ready-to-review pull request that changes only the runs-on lines and leaves every other line byte-identical, so nothing changes until you merge. That is the "propose, do not merge" principle the survey data is quietly asking for, built into the grain of the product.
On cost, Latchkey gives you analytics with nothing to instrument: spend broken down by repository, workflow, and runner, alongside pipeline duration and success metrics, all filterable by repository, workflow, and date range. It tracks theoretical and billable cost side by side, surfaces your free-tier minutes used and remaining for both your GitHub plan and your Latchkey plan, and once there is enough run history it projects your GitHub-hosted CI cost through the end of the billing cycle. In a year when GitHub-hosted rates dropped and a self-hosted fee appeared and then paused, being able to see where your minutes actually go is not a luxury. It is the difference between reacting to a bill and planning around one.
The honest summary
The 2026 landscape is not complicated once you separate the noise from the signal. The noise is the pricing whiplash, real, worth tracking, but still settling, with hosted runner prices down up to 39% since January and the self-hosted fee postponed rather than dropped (GitHub Changelog, GitHub Changelog). The signal is that AI made code cheap and pipelines did not get faster or more trustworthy at the same rate (Qovery, JetBrains TeamCity Blog).
The teams that come out ahead will not be the ones that automate the most. They will be the ones that automate the boring, environmental failures away, keep humans in the loop on anything that changes their code, and can actually see what their pipeline costs. That is the bet Latchkey is built on: speed where speed is safe, a human at every point where it is not, and no claims we cannot stand behind.
If you take one thing from this week's read, let it be this. The bottleneck moved. The question is no longer how fast can you write code. It is how fast, and how honestly, can you ship it.
Check us out at https://latchkey.dev
Top comments (0)