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.
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 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 could help, if you could trust it.
The JetBrains piece described where AI is actually earning its place in delivery today: reading pipeline logs at scale, correlating errors across runs, and suggesting probable root causes faster than manual inspection, while keeping decisions firmly under human control. That last clause is the whole game. Trust is not won by an automation that does more. It is won by an automation that is narrow about what it touches, honest about what it did, and easy to switch off.
At Latchkey, that principle shapes how our self-healing CI works, so let me be specific about the boundaries, because the boundaries are the point.
It heals the infrastructure, not your code. When a step fails on a Latchkey managed runner, Latchkey detects the failure, diagnoses the cause, and applies a fix while the job is still running, then re-runs the failed step. It targets transient and environmental failures: flaky networks, full disks, memory kills, missing tools, environment drift. It does not fix bugs in your application, and it is not a promise of a green build. Some builds should be red.
Real failures fail truthfully. This is the part that matters most for trust. Latchkey only attempts a fix when it has a high-confidence infrastructure or environment signal. A real defect in your code, a compile error, a failing test, a broken assertion, passes through unchanged. The green check still means what it always meant. An automation that quietly turned red builds green would be worse than no automation at all, and that is precisely the failure mode this design refuses.
Novel failures get investigated, not guessed at. For build failures that fixed rules do not recognize, an AI agent on the runner investigates, applies a fix from a vetted, bounded set of actions, and verifies it by re-running the step. When it is not confident, it does nothing, and the original failure stands. "Does nothing" is a feature. It is the difference between a tool that helps and a tool you have to second-guess on every run.
Permanent fixes come as a pull request you own. When a successful heal traces back to a structural cause, Latchkey can open a pull request proposing a permanent fix to your workflow or package configuration. You review it. You merge it. Changes to your repository only ever happen through a PR you approve. Nothing is auto-merged, and not every heal produces a PR.
Everything is on the record. Nothing happens silently. Every self-heal attempt is recorded on the dashboard with what failed, what action was taken, and the outcome, and agent heals include the full step-by-step transcript. If you want to know what the automation did to your build, the answer is right there, not inferred.
You hold the off switch. Self-healing is on by default and controlled by a single organization-level toggle. An owner or admin can turn it off for the whole workspace at any time. Trust is easier to extend when you know you can withdraw it instantly.
There is one more piece that speaks directly to the 33% who named privacy as the reason they keep AI out of CI/CD. Latchkey only reads metadata. It never reads or stores your source code. The automation that diagnoses your pipeline does not need to read your application to do its job, and it does not.
Trust and cost meet at the same place: visibility. You cannot trust what you cannot see, and you cannot manage a CI bill you cannot break down. With GitHub-hosted rates moving and the self-hosted picture unsettled, knowing where your minutes actually go has gone from a nice-to-have to a planning input.
Latchkey gives you cost and performance analytics for your GitHub Actions with nothing to instrument. Spend is broken down by repository, workflow, and runner, alongside pipeline duration and success metrics, all filterable by repository, workflow, and date range. You can see theoretical and billable cost tracked side by side over time, so a workflow that quietly doubled in cost stops being a surprise on the invoice.
Two views are especially useful in a year of shifting prices. The first is free-tier minute tracking, which shows the CI minutes you have used and have left for both your GitHub plan and your Latchkey plan, side by side in one place. The second is an end-of-cycle cost forecast: once there is enough run history, Latchkey projects your GitHub-hosted CI cost through the end of the current billing cycle, so you can see where the month is heading before the bill arrives. The forecast is a projection, not a guarantee, and it is intentionally withheld until there is enough history to make it meaningful.
You can also see your managed runner costs per configuration alongside an estimated savings figure versus what the same usage would have cost on GitHub-hosted runners. That figure is computed from your own usage, not a marketing number, which is the only honest way to talk about savings: yours will be yours.
The cheapest minute is the one you never spend. A good deal of pipeline waste is structural, and it is the kind of waste that better runners quietly remove.
Latchkey runs your GitHub Actions jobs on managed Linux runners that it provisions and tears down for you. Switching a job is a one-line change to runs-on
in your workflow YAML, with no runner fleet to operate. You pick the right size for each job, from lighter 2 vCPU machines up to heavier 16 vCPU machines, by setting a single label, so a small lint job does not pay for a large build's hardware.
Each job runs on a fresh, isolated, single-use runner that is destroyed when it finishes, so no data, artifacts, or state carry over between runs. Fresh runners would normally mean slow starts and repeated dependency installs, so two things offset that. First, jobs are picked up in seconds rather than waiting for a machine to boot from scratch, and paid tiers keep pre-warmed runners standing by. Second, the runner image ships with a wide range of languages, build tools, browsers, and SDKs preinstalled, so jobs spend less time installing dependencies, and the image is actively maintained and rebuilt to track upstream operating system and package updates so you are not maintaining it yourself.
Caching is built into every Latchkey managed runner, with nothing to install or wire up, and cache data isolated per organization, encrypted at rest, and aged out automatically. Latchkey Fast Cache saves and restores dependency caches in a single streaming request, with storage in the same region as your runners and a one-line switch from actions/cache
. A cache problem can slow a build down, but by design it never fails one. For container builds, Latchkey Docker Cache Build caches your Docker layers in a private, per-organization container registry it manages for you, so unchanged layers are reused across builds even though every runner is fresh.
The whole point of the trust gap is that teams should not have to take a leap of faith, so the on-ramp is built to be reversible and visible at every step.
You connect Latchkey by installing the GitHub App and choosing which repositories to monitor. It is a guided setup with nothing to instrument, and your historical runs sync in automatically, so the dashboard is not empty on day one. From there, when you are ready to move workloads onto managed runners, Latchkey can open ready-to-review pull requests that change only the runs-on
lines and leave every other line in each workflow file byte-identical. Only mappable Linux labels are switched. Windows, macOS, and matrix expressions are left untouched, and nothing changes until you merge. It is built for compatibility with GitHub-hosted Ubuntu runners, so for Linux jobs the steps and inputs you already use carry over, with compatibility as the goal rather than a claim of byte-identical parity.
Every step here is the same shape as the self-healing design: propose, show, and let you decide. You see your data before you commit. You review a PR before anything changes. You keep the off switch.
Notice what these boundaries have in common. Diagnose, but let real failures fail. Act on infrastructure, but propose code changes as reviewable PRs. Automate the heal, but write down every step. Default it on, but make the off switch one toggle. Show the cost before you forecast it. Migrate by proposal, not by force.
That is not AI doing less for the sake of caution. It is AI placed exactly where the cost of a wrong guess is low (a flaky runner) and kept away from where the cost is high (your test results, your source, your merge decisions). The JetBrains data suggests teams are not refusing automation because they dislike it. They are refusing it because most of it has not respected that line.
The trust gap closes one honest interaction at a time. A build that recovers from a full disk on its own, shows you exactly what it did, and still fails truthfully when your test is actually broken, is a build you can start to trust. Stack up enough of those, and the pipeline stops being the last room AI is locked out of.
If you want to dig into how any of this works in practice, including the audit trail and the organization-level controls, that is the conversation we are most glad to have, because the details are where trust is either earned or lost.
Check us out at [https://latchkey.dev](https://latchkey.dev)