DEV Community: Kay

Self-Healing CI Fixes Your Environment. Your Coding Agent Fixes the Code.

Kay — Fri, 04 Sep 2026 00:35:47 +0000

The agent is already in your workflow. The failed build is where it goes blind.

AI coding agents have moved from novelty to daily tool. In Stack Overflow's 2025 Developer Survey, 84% of developers said they are using or planning to use AI tools in their development process, up from 76% the year before, and about one in seven professional developers now use AI agents at work every day. Among developers who have used agents at work, roughly 70% agree the agents have reduced the time they spend on specific tasks.

There is one place, though, where that agent still tends to go dark: the failed CI run. The pipeline turns red, and your agent (like you) is handed a wall of log output from jobs it did not write, covering steps it did not touch. It has to reconstruct what actually broke before it can fix anything. That reconstruction is the expensive part, and it is exactly the part Latchkey is built to remove.

This piece is about a clean division of labor. Latchkey's self-healing CI repairs the failures that are about your environment, not your code. For the failures that are genuinely about your code, Latchkey does not guess and patch on your behalf. Instead it hands your own coding agent a complete, structured account of the failure over the Model Context Protocol, so your agent can fix the bug with full context instead of starting from a log file.

Two kinds of red build, and only one of them is yours to fix

Almost every failed build is one of two things. Either the environment let you down (a flaky network, a full disk, a process killed for memory, a missing tool, configuration that drifted), or your code is actually wrong (a compile error, a failing test, a broken assertion). These two cases want opposite treatment, and conflating them is how teams end up rerunning pipelines and hoping for green.

Latchkey's self-healing CI handles the first case. 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, the flaky networks, full disks, memory kills, missing tools, and environment drift that have nothing to do with your application logic. It is built into every runner, with no separate fee. For 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.

The second case is the important one for this story. Latchkey only attempts a fix when it has a high-confidence infrastructure or environment signal. Real defects in your code pass through unchanged, so your tests fail truthfully. Self-healing is deliberately not in the business of making a failing test go green. A test that catches a real bug is doing its job, and Latchkey leaves it alone.

So when self-healing stands down, it is making a statement: this looks like your code, not your environment. That is the moment the handoff begins.

Why a real failure is so expensive to debug from a log

If your environment is healthy and your code is broken, the clock starts on debugging, and debugging is where engineering time quietly disappears. A report from Undo with Cambridge Judge Business School estimated that developers lose 620 million hours a year to debugging software failures, at a cost of around 61 billion dollars. The same report found that reproducing a failure is the single biggest barrier to fixing it faster, named by 41% of respondents, ahead of writing the test or making the fix itself.

That tracks with how a failed CI run actually feels. As one developer account put it, the pipeline tells you something broke but not what or why, and you are left "scrolling through raw logs across multiple jobs, mentally diffing environment differences between local and CI, guessing whether the failure is flaky or real." The hard problem is almost never typing the fix. It is rebuilding enough context to know what the fix should be.

Handing that job to an AI agent does not automatically solve it, because the agent inherits the same truncated, noisy log you did. And trust is already thin: in the 2025 survey, more developers said they distrust the accuracy of AI tools (46%) than trust it (33%). The way you earn that trust back is not a more confident agent. It is a better-informed one, working from complete context and proposing a change you review.

MCP: the emerging standard for feeding agents context

The reason this can be a clean, portable handoff rather than a custom integration is the Model Context Protocol. MCP was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external systems and data, and it is often described as "USB-C for AI" because it replaces a tangle of one-off connectors with a single shared interface.

It caught on quickly. OpenAI adopted MCP in March 2025 and Google followed in April 2025. By late 2025, Anthropic reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads, with the protocol now supported across products including ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. Anthropic has since donated MCP to the Agentic AI Foundation, a Linux Foundation effort co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. In other words, MCP is becoming the common language for giving an agent context, which is exactly what a stranded CI failure needs.

How the handoff actually works

Here is the path a real code failure takes, end to end.

Self-healing investigates first, then stands down. Latchkey looks at the failure and tries to heal it as an environment problem. When the signal points at your code instead, it does not apply a fix. It records what it looked at and why it held back, and it prepares a handoff.

It assembles a structured failure bundle. Rather than pointing your agent at raw output, Latchkey packages the failure into a complete, structured bundle:

the root cause, in plain language
the exact file where the build failed
the full logs, with secrets stripped
what self-healing already investigated and why it stood down
your workflow definition

A note on what is not in that bundle: your application source code. The bundle is logs, the root-cause analysis, the failing file's location, and your workflow definition, with secrets removed. This is consistent with Latchkey's standing posture that it only reads metadata and never reads or stores your source code.

Your own agent connects over MCP, read-only. You connect any MCP-capable coding agent, Claude Code, Cursor, and Codex are all examples, using a read-only API key. The server exposes a small, focused tool surface to your agent: one tool to see the failures waiting for attention, and one tool to pull the complete bundle for a given failure. A single command in your agent ties them together, taking you from "the build failed" to a drafted fix in one step, with the full context already loaded.

Because the key is read-only, it can never change anything in your repository or account. The fix itself is made by your agent, in your repository, and you review and merge it the same way you would any other change. Latchkey does not fix your application-code bugs for you. It makes sure your agent has everything it needs to fix them well.

Why this division of labor matters

The point of all this is to stop treating two different problems as one. Environment failures should be repaired quickly, automatically, and quietly, without a human in the loop, because there is no judgment call to make. Real code failures should never be auto-patched, because the judgment call is the whole point, and it belongs to you and your agent.

What changes with the handoff is the starting line. Instead of your agent reproducing the failure from a partial log (the step the research says is the single biggest barrier to fixing bugs faster), it begins from the answer: the root cause, the failing file, the clean logs, and the context of what already ran. That is the difference between asking an agent to investigate and asking it to fix.

And because the handoff rides on MCP rather than a bespoke plugin, it works with the agent your team has already chosen, in a year when most teams have chosen one. Self-healing keeps your pipeline moving through the noise. The MCP handoff makes sure that when the failure is real, the fix happens fast, in your repository, under your review, with nothing reconstructed by hand.

Check us out at https://latchkey.dev

The Pipeline Became the Attack Surface: What the 2026 CI/CD Shifts Mean for Reliability

Kay — Fri, 04 Sep 2026 00:33:47 +0000

The Pipeline Became the Attack Surface

For most of the last decade, we treated the CI/CD pipeline as plumbing: invisible, trusted, and mostly ignored until it broke. That assumption is no longer safe. The clearest signal came in 2025, when attackers stopped going after the software a pipeline builds and went after the pipeline itself.

This week's research pass pulled together three shifts that are all landing at once: a supply-chain attack that redefined the threat model, GitHub's response in its 2026 security roadmap, a pricing change that quietly rewrites the cost math, and a persistent gap between how much teams trust AI in general and how little they trust it inside CI. Here is what the sources actually say.

The tj-actions attack changed the threat model

On March 14, 2025, researchers discovered that the popular tj-actions/changed-files GitHub Action had been compromised. According to Palo Alto Networks Unit 42, the action was used by over 23,000 GitHub repositories at the time (Unit 42).

The mechanics are worth understanding, because they explain why this matters beyond one action. Attackers injected code that dumped the CI/CD runner's memory and wrote sensitive environment variables and secrets straight into the workflow logs. They retroactively modified multiple version tags to point at a single malicious commit, so pipelines that pinned to a tag rather than a commit SHA pulled the payload (Unit 42). The incident is tracked as CVE-2025-30066, described as allowing remote attackers to discover secrets by reading action logs (GitHub Advisory Database).

The compromise did not start with tj-actions. Unit 42 traced it back through a leaked personal access token that reached reviewdog/action-setup, a dependency in the chain, with earlier steps going back to late 2024 (Unit 42). In other words, the pipeline's own dependency graph was the delivery vehicle.

The takeaway is not "avoid one bad action." It is that the automation running your builds is now a first-class target, with its own attack surface: unpinned action references, secrets sitting in runner memory, and state that lingers on a runner between jobs.

GitHub's 2026 security roadmap is a direct answer

GitHub's published 2026 security roadmap reads like a point-by-point response to that threat model (The GitHub Blog). The headline items:

Workflow-level dependency locking. A new dependencies: section in workflow YAML that locks direct and transitive dependencies to commit SHAs, so a retagged release cannot silently swap in new code. GitHub lists this in public preview within 3 to 6 months.
Scoped secrets. Credentials bound to a specific repository, branch, environment, or trusted reusable workflow, so secrets are no longer implicitly inherited by every job.
Policy-driven execution controls. Centralized rules for who can trigger workflows and which events are allowed, such as restricting workflow_dispatch to maintainers.
Native egress firewall. A Layer 7 firewall for GitHub-hosted runners that sits outside the VM and stays enforced even if an attacker gains root, controlling which domains and IP ranges a job can reach.
Actions Data Stream. Near real-time execution telemetry delivered to Amazon S3 or Azure Event Hub for centralized observability.

The through-line is reproducibility, least privilege, and containment. Lock what runs, limit what each job can see, and box in what it can reach.

Alongside the roadmap, GitHub is tightening operational hygiene: it is enforcing minimum version requirements for self-hosted runners on a staged timeline through 2026, with brownouts that intermittently block registration and job execution on unsupported versions (GitHub Changelog). If you operate your own runner fleet, that is real maintenance work arriving on a deadline.

The cost math is shifting too

Security is not the only thing changing. GitHub announced that on January 1, 2026, it would reduce the price of GitHub-hosted runners by up to 39% depending on machine type, while keeping free usage minute quotas the same. Separately, a $0.002 per minute platform charge for self-hosted runners takes effect March 1, 2026, counting toward the minutes included in your plan (GitHub Changelog).

GitHub's own framing is that 96% of customers will see no change to their bill, and of the 4% affected, 85% will see a decrease (GitHub Changelog). Even so, any repricing is a good reason to actually know where your CI spend goes, because "no change on average" and "no change for your team" are not the same statement.

The AI-in-CI trust gap is still wide

Given how deeply AI has moved into daily development, you might assume pipelines are full of it. They are not. JetBrains reports that 73% of organizations do not use AI in CI/CD pipelines at all, even as general AI tool usage in development exceeds 90% (JetBrains TeamCity Blog). 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 three barriers together and they describe a single requirement. For AI to earn a place in the pipeline, it has to be scoped to problems it can actually solve, transparent about what it did, and careful with what it can see. Trust is the gating factor, not raw capability.

How we think about reliability from here

At Latchkey we build managed GitHub Actions runners, so these shifts are our daily context rather than someone else's headline. A few of the principles above map directly onto how the product works, and it is worth being precise about what that does and does not mean.

Fresh, isolated runners reduce lingering state. Every job on Latchkey runs on an ephemeral, single-use runner that is destroyed when the job finishes, so no data, artifacts, or state carries over between runs. That does not make any runner immune to compromise, and no one should claim it does. It does mean there is no long-lived machine accumulating secrets and state across jobs.

Workflow security analysis surfaces the misconfigurations the tj-actions class of attack exploits. Latchkey scans your GitHub Actions workflows for issues like excessive permissions, unpinned actions, and secret exposure, and surfaces the fix. It does not catch every vulnerability and it is not a full application security product. It targets a defined set of workflow misconfigurations, which is exactly the category the 2025 incident lived in.

Self-healing addresses reliability, not correctness. When a step fails on a Latchkey managed runner because of a transient or environmental problem (a flaky network, a full disk, a missing tool, environment drift), Latchkey diagnoses the cause and applies a fix while the job is still running, then re-runs the step. It will not fix bugs in your application code, and it does not guarantee a green build. Real defects (compile errors, failing tests, assertions) pass through unchanged, so your tests still fail truthfully when your code is actually broken.

Transparency is the default, because that is what earns trust. Nothing happens silently. Every self-heal attempt is recorded on the dashboard with what failed, what action was taken, and the outcome, and agent-driven heals include the step-by-step transcript. That directly answers the "I don't trust what the AI did" barrier: you can read exactly what happened.

Privacy posture is narrow on purpose. Latchkey only reads metadata; it never reads or stores your source code. For teams whose main hesitation about AI in the pipeline is data privacy, the scope of access is the first question, and the answer here is deliberately limited.

And because the cost picture is moving, Latchkey gives you cost and performance analytics for your GitHub Actions with nothing to instrument, showing spend broken down by repository, workflow, and runner. When repricing lands, "know your own numbers" beats "trust the average."

The short version

The pipeline is no longer plumbing. It is a target, a cost center under active revision, and a place where AI has to earn trust before it earns adoption. GitHub's roadmap points at locking dependencies, scoping secrets, and containing what jobs can reach. Those are the right instincts. The teams that come out ahead will treat their CI/CD system as something to be secured, observed, and understood, not just something that turns green.

If you want to go deeper on any one of these threads, the sources linked throughout are the primary material, and they are worth reading in full.

Check us out at https://latchkey.dev

The CI/CD Tools Landscape in 2026: What Each Category Is Actually For

Kay — Fri, 04 Sep 2026 00:31:22 +0000

Most "best CI/CD tools" lists are twenty logos in a table, ranked by nothing in particular, with the author's product at the top. This is not that. It is a map of the categories, what each one exists to solve, and how to tell whether you need it yet.

I work at Latchkey, so I will say plainly where we sit: we are one option inside one of the six categories below, and I will tell you when we are the wrong answer. Read the rest as a map, not a pitch.

A note on what is missing here: I have not invented benchmark numbers or quoted prices for tools I do not operate. Vendor pricing changes often enough that any figure I write today is wrong by the time you read it. Where a number matters, go to the vendor's own pricing page.

The mistake most teams make

Teams usually shop for CI/CD tools by asking "which one is best." That question has no answer, because the tools are not competing with each other. They are stacked on top of each other.

A team that adopts a build accelerator to fix a slow pipeline, when the actual problem is that half their failures are flaky, has bought a faster way to fail. A team that adds pipeline observability before they have enough pipeline to observe has bought a dashboard nobody opens.

The useful question is narrower: which layer is currently your constraint? Answer that, and the tool choice inside the layer is usually obvious.

Here is the whole landscape in one view.

Layer	What it solves	When it becomes your bottleneck
CI platform	Running the pipeline at all	Never; this is where everyone starts
Runners and compute	Where jobs run, and how fast they start	Queue time or runner cost is visible
Build acceleration	Doing less work per run	Full rebuilds dominate your wall clock
Supply chain security	What the pipeline is allowed to reach	You ship to production or touch customer data
Observability and cost	Where time and money actually go	You cannot answer why last week was slow
Artifacts and registries	Storing what the pipeline produces	You publish images or packages

The rest of this post walks each row.

1. CI platforms

This is the layer everything else plugs into: the thing that watches your repository, decides what to run, and reports back.

The practical split in 2026 is between platforms that live where your code lives and platforms you bring to your code.

GitHub Actions is the default for most teams on GitHub, and the default is a real advantage: the trigger model, the permissions, and the marketplace of reusable actions are already wired to the repository. GitLab CI occupies the same position for GitLab teams. Jenkins remains the answer when you need to run somewhere no SaaS reaches, and the cost is that you now operate a Jenkins. CircleCI and Buildkite are the main "bring your own" options, with Buildkite in particular built around the idea that the control plane is hosted and the compute is yours.

The honest guidance for this layer is boring: use whatever your forge gives you until it stops working. Platform migrations are expensive, they rarely fix the problem you actually have, and the problem you actually have is usually in one of the five layers below.

If you are evaluating a platform switch to solve slow or flaky builds, check the next two categories first. The pipeline definition is rarely what is slow.

If you want the vocabulary before you evaluate anything, our CI/CD glossary defines the terms these vendors use inconsistently.

2. Runners and compute

This is where the jobs actually execute, and it is the layer most teams reach for second, usually because a build queue got long enough to notice.

Three models exist:

Platform-hosted. GitHub-hosted runners, GitLab's shared runners. Zero operations, and you pay per minute at the platform's rate.
Self-hosted. Your machines, your problem. Cheapest per minute on paper and the true cost is the engineer maintaining the fleet, patching the images, and answering why a runner is wedged.
Managed third-party. A vendor operates ephemeral runners that register with your CI platform. You change a label, they handle the machines. This is where Depot, Blacksmith, WarpBuild, RunsOn, and Latchkey sit.

The tradeoff inside the third category is not really about price per minute, because those numbers are close enough that the difference rarely dominates a bill. It is about what else the runner does: some optimise cold start, some bundle caching, some focus on Docker builds specifically.

Where we sit, stated plainly. Latchkey runs ephemeral Linux runners that you switch to by changing one runs-on line:

jobs:
  build:
    runs-on: latchkey-small   # was: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Every job gets a fresh single-use machine that is destroyed afterwards, and the differentiator we actually build for is that the runner repairs its own transient failures mid-run rather than handing you a red X. That is described in full in our self-healing documentation.

When we are the wrong answer, and this is the useful part of the section:

You need Windows, macOS, or arm64. Latchkey runners are Ubuntu x86_64 only. If your matrix spans operating systems, keep those jobs on platform-hosted runners. Mixed workflows are fine, but we cannot be your only runner.
Your builds are dominated by Docker image builds specifically. That is a narrower problem with vendors built squarely around it.
Your CI is already fast and cheap. If your pipeline finishes in three minutes and costs less than a coffee, this entire category is a solution to a problem you do not have.

For a category overview independent of any one vendor, we maintain a managed runners explainer, and per-vendor comparisons live under our comparison pages — which are, obviously, written by us.

3. Build acceleration

Everything in this category exists to avoid redoing work. It splits cleanly in two.

Caching restores artifacts from a previous run: dependency trees, compiled objects, Docker layers. It is the cheapest speedup available and the most commonly misconfigured thing in CI. The usual failure is a cache key that changes every run, which means you pay the cost of saving a cache you never restore.

We have written the details up separately rather than repeat them here:

CI caching explained — the general model
Cache key vs restore key — the single most common misconfiguration
GitHub Actions caching and its limits — where actions/cache stops helping
Docker layer caching explained
Dependency caching strategies

Build systems with caching built in are the heavier answer. Bazel, Nx, Turborepo, and Gradle with a build cache all model your build as a dependency graph, so they can skip any node whose inputs have not changed, and share those results across machines.

The adoption cost is real and worth stating: you are restructuring your build, not adding a step. The rule of thumb that holds up is monorepo size. In a single-package repository, a well-configured dependency cache gets you most of the win for a fraction of the effort. Once you have many packages where a one-line change triggers a full rebuild of everything, graph-aware tooling starts paying for itself.

The signal to watch is not build duration. It is the ratio between "how much changed" and "how much rebuilt." If a one-line change rebuilds the world, you have a graph problem, and no amount of faster compute fixes a graph problem.

Side-by-side breakdowns of the individual tools live in our tool comparisons.

4. Supply chain security

The pipeline is the most privileged thing most teams run. It holds credentials for production, it can push to your registry, and it executes third-party code on every run.

The categories worth knowing:

Concern	What it means	Representative tooling
Runtime egress control	Restricting what the runner can reach mid-job	Harden-Runner
Dependency scanning	Finding known vulnerabilities in what you pull in	Dependabot, Renovate, Snyk
Artifact signing	Proving an artifact came from your pipeline	Sigstore, cosign
Provenance and SBOM	A verifiable record of what went in	SLSA provenance, syft
Secret hygiene	Keeping credentials out of logs and source	OIDC federation, gitleaks

The highest-leverage item on that list for most teams is not a scanner. It is replacing long-lived cloud credentials with OIDC federation, so the pipeline exchanges a short-lived token per run instead of holding a static key that lives in your secrets forever.

The second is pinning third-party actions to a commit SHA rather than a mutable tag. uses: some/action@v3 means you run whatever that tag points at today, which is not necessarily what it pointed at when you reviewed it.

5. Observability and cost

This is the layer that barely existed as a category five years ago and is now the one teams ask about most, for a simple reason: the number of builds went up faster than the number of engineers.

There are two distinct questions here, and tools tend to answer one or the other:

"Why is the pipeline slow or unreliable?" Duration trends, failure rates, flaky test detection, mean time to recovery. Some CI platforms ship a version of this natively; dedicated tools go deeper, particularly on flake detection.

"Where is the money going?" Spend attributed to a repository, a workflow, a runner size. This is harder than it sounds, because the platform bill arrives as one number and the interesting question is which of your two hundred workflows caused it.

Latchkey does both, and I will be specific about the boundary so it is not oversold: we report on the jobs we can see. Cost analytics cover your GitHub Actions usage and your Latchkey runner usage, broken down by repository, workflow, and runner, with free-tier minutes tracked for both. If a large part of your build spend is somewhere else entirely, a separate cloud account doing container builds, say, we are not seeing it and will not pretend to.

If the general problem interests you more than our take on it, our GitHub Actions cost guide covers the mechanics without needing our product.

6. Artifacts and registries

The least glamorous layer, and the one that quietly breaks builds most often.

Container registries (GHCR, ECR, Docker Hub, Artifactory), package registries (npm, PyPI, Maven Central, and private mirrors), and build artifact storage all live here. Two failure modes account for most of the pain:

Rate limits. Anonymous pulls from public registries are throttled, and CI is very good at looking like abuse. The fix is authenticating pulls or running a pull-through cache.
Retention. Artifact storage accumulates until someone notices the bill. Retention policies are boring and worth setting on day one.

When these break they usually surface as an error message rather than a design decision, which is why most of our writing on this layer sits in our CI/CD error library rather than in a guide.

How to actually choose

A sequence that works, in order:

Measure before you buy. Find your slowest and most frequent workflows and the failure rate of each. Any tool you evaluate should point at a number you already have.
Fix caching first. It is the cheapest intervention in the entire landscape and it is misconfigured more often than not.
Separate flaky from broken. If a meaningful share of your failures are environmental rather than real defects, faster compute makes them arrive faster. That is a reliability problem, not a speed problem.
Only then buy compute. Once builds are doing the minimum necessary work and failing for real reasons, throwing faster machines at them produces a clean, measurable win.
Add observability when you have more than one team. Before that, you already know what is slow.

The through-line: most CI problems are not solved by the layer people reach for first. Slow builds are usually a caching or graph problem, not a compute problem. Unreliable builds are usually an environment problem, not a test problem. The tool categories are easy; the diagnosis is the hard part.

The honest summary

The CI/CD tool landscape looks crowded because it is six distinct markets that share a name. Almost nobody needs all six. Most teams need their forge's default CI platform, working caching, and one thing fixed in the layer that is currently their constraint.

We build in the runners-and-compute row, with a reliability angle. If your constraint is elsewhere — and for plenty of teams it is caching, or a build graph, or nothing at all yet — then the right move is to fix that instead, and this post did its job either way.

If you take one thing from this: figure out which row you are in before you shop. The tools are not competing. The layers are stacked, and only one of them is your bottleneck today.

Check us out at https://latchkey.dev

The Trust Gap: Why CI/CD Is the Last Place Teams Let AI In, and How to Earn That Trust

Kay — Fri, 04 Sep 2026 00:30:14 +0000

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 could help, if you could trust it.

What trustworthy pipeline automation looks like

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.

Seeing where the minutes go

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.

Lower-waste runners by design

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.

Getting started without a leap of faith

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.

The pattern underneath all of this

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

CI Got Cheaper in 2026. Reliability Is Now the Harder Problem

Kay — Fri, 04 Sep 2026 00:29:23 +0000

The first half of 2026 reset two things at once for engineering teams: what continuous integration costs, and what it takes to keep delivery stable while AI pushes more change through your pipelines than ever. Those two stories are connected, and the connection is the part worth your time.

The pricing reset

On January 1, 2026, GitHub reduced prices for GitHub-hosted runners by up to 39%, with the size of the cut depending on the machine type (GitHub Changelog). Standard hosted-runner usage on public repositories stays free, as it was before.

The DevOps publication SamExpert documented the specific per-minute moves. A Linux 2-core runner dropped about 25% (from $0.008 to $0.006 per minute). A Windows 2-core runner dropped about 38% (from $0.016 to $0.010). A Linux 64-core arm64 runner dropped about 39% (from $0.160 to $0.098) (SamExpert). If your CI runs mostly on hosted runners, that is real money back, and it is worth recalculating your monthly estimate against the new rates rather than assuming last year's numbers still hold.

The same December 2025 announcement carried a more controversial proposal: a $0.002 per-minute charge for self-hosted runner usage in private repositories, scheduled to start March 1, 2026 (DevClass). GitHub framed it as ending a cross-subsidy, where revenue from hosted runners was effectively underwriting the cost of operating Actions for everyone, and said the large majority of customers would see no change to their bill. The reaction from developers who run CI on their own hardware was sharp, with some publishing the monthly figures they expected to owe for compute they already pay to operate themselves.

Within about a week, GitHub posted that it was postponing the self-hosted billing change to re-evaluate its approach (SamExpert). Postponed, it is worth being precise here, is not the same as withdrawn. There is no new date and no guarantee the charge returns in its original form, but there is also no statement that it is gone for good. If you operate self-hosted runners, this is a line item to keep watching rather than one you can cross off.

The takeaway is not "CI is cheap now, problem solved." Cheaper minutes lower the floor on per-minute cost. They do nothing for the minutes you lose to flaky failures, cold starts, and re-runs, or for the engineering hours spent staring at a log to find out a job died because a disk filled up. Price per minute is one variable. Minutes wasted is the other, and it is usually the larger one. That is where the second story comes in.

The reliability paradox

Google's 2025 DORA report, drawn from survey responses from nearly 5,000 technology professionals around the world, found that 90% of respondents now use AI at work and more than 80% believe it has increased their productivity (Google Cloud). That is genuinely good news. This year DORA observed a positive relationship between AI adoption and both software delivery throughput and product performance, a reversal from the prior year, when the throughput signal was less encouraging.

The catch is stability. The report states plainly that AI adoption "does continue to have a negative relationship with software delivery stability." The explanation is intuitive once you say it out loud: AI accelerates how fast code gets written, and that acceleration exposes weaknesses downstream. Without robust control systems, an increase in change volume leads to instability (Google Cloud). More pull requests, more merges, more pipeline runs, all arriving faster than the systems meant to catch problems were designed for.

There is a trust dimension too. The same report found that about 30% of respondents report little or no trust in the code generated by AI, a slightly lower share than the year before but still a meaningful minority (Google Cloud). People are shipping more AI-assisted code than they fully trust, which puts even more weight on the automated checks downstream.

DORA's broader framing is that AI is an amplifier. As the report puts it, AI's "primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses," and the greatest returns come not from the tools themselves but from a strategic focus on the underlying system around them (DORA). The report also found that 90% of organizations have adopted at least one platform, and that a high-quality internal platform correlates directly with a team's ability to unlock value from AI.

Read those findings together and a clear picture emerges. More code is arriving faster. Whether that helps or hurts depends on the control systems underneath it: automated testing, fast feedback, version-control discipline, and quick recovery when something breaks. CI is where most of those controls actually run, which makes the platform layer under your pipelines a strategic surface, not a commodity you pick on price alone.

Security moves toward the default

GitHub's 2026 Actions security roadmap points in the same direction: making secure pipelines the default rather than something you assemble by hand. The roadmap describes five initiatives (GitHub community discussion):

Workflow execution protections, which let administrators control who and what can trigger workflows, including which events and branches are permitted to run them.
A native egress firewall for hosted runners, which restricts outbound network traffic with allow and deny capabilities so a compromised step cannot freely call out.
Workflow-level dependency lock files, which pin actions to specific commit SHAs much like a package lock file, reducing the supply-chain risk of a tag silently changing under you.
Scoped secrets, which allow more granular secret access so that a single compromised step exposes less.
An Actions data stream, which delivers execution telemetry to external systems as a more durable, separate record than mutable workflow logs.

The common thread across pricing, the DORA findings, and this roadmap is the same one: the platform layer underneath your pipelines is where reliability, cost, and trust are won or lost. Securing it by default, rather than by effort, is the direction the whole ecosystem is moving.

What this means for how you run CI

If 2026 is the year change volume goes up, the practical question is how your pipeline absorbs that volume without your team paying for every hiccup in re-runs and context switches. A few moves are worth making regardless of which vendor you use:

Separate real failures from infrastructure noise. A failing test should fail loudly and truthfully. A runner that ran out of disk, lost a network connection, or was missing a tool should not cost you a debugging session or a manual re-run.
Measure recovery, not just speed. Lead time and deployment frequency get the attention, but mean-time-to-recovery and rebuild success tell you whether your control systems are keeping up with the change volume DORA is describing.
Know where your CI spend and minutes actually go before you optimize, especially now that hosted prices have shifted and the self-hosted picture is unsettled.
Treat pipeline security as a default to turn on, not a project to schedule. Pinning actions, scoping secrets, and constraining what can trigger a workflow are cheap relative to the cost of getting them wrong.

This is the work Latchkey is built for, so here is where we fit, described plainly and without inflated numbers.

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 the runs-on label in your workflow YAML, and because the runners are built for compatibility with GitHub-hosted Ubuntu runners, the steps and inputs you already use carry over for Linux jobs. Each job runs on a fresh, single-use runner that is destroyed when it finishes, so no state carries between runs, and jobs are picked up in seconds rather than waiting for a machine to boot from scratch. The runner image ships a broad preinstalled toolchain, so jobs spend less time installing dependencies, and caching is built into every runner with nothing to wire up.

On reliability, every Latchkey managed runner includes self-healing CI. When a step fails for a transient or environmental reason (a flaky network, a full disk, a process killed for memory, a missing tool, 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 does not promise a green build or claim to fix everything, and it is careful by design: a fix is only attempted when there is a high-confidence infrastructure or environment signal. Real defects in your code, like compile errors and failing tests, pass through unchanged, so your tests still fail truthfully when the code is actually wrong. Nothing happens silently either. Every self-heal attempt is recorded on the dashboard with what failed, what action was taken, and the outcome, and when a heal traces back to a structural cause, Latchkey can open a pull request proposing a permanent fix that you review and merge. Repository changes only ever happen through a pull request you approve.

When a pipeline does fail in a way that should fail, Latchkey reads the logs, identifies a likely root cause, and proposes a targeted fix you can review, so you open the dashboard to an answer instead of a raw log file. That is diagnosis, offered for you to apply, not an automatic change to your code.

On measurement, Latchkey trends mean-time-to-recovery and rebuild success over time, so you can see whether your pipeline is recovering faster or slower as change volume grows. On cost, it breaks down your GitHub Actions spend by repository, workflow, and runner, tracks your free-tier minutes used and remaining for both your GitHub and Latchkey plans side by side, and, once there is enough run history, projects your GitHub-hosted cost through the end of the current billing cycle. Those are your numbers, from your runs, not a benchmark we are asking you to take on faith. And on privacy, Latchkey only reads metadata. It never reads or stores your source code.

Getting started is a guided setup: you install the GitHub App, choose which repositories to monitor, and your historical runs sync in so the dashboard is not empty on day one. If you want to move workflows over, Latchkey can open ready-to-review pull requests that change only the runs-on lines and leave every other line untouched, so nothing changes until you merge.

Cheaper minutes are welcome, and the January price cuts are a real win for teams that lean on hosted runners. But the harder, more durable problem in 2026 is keeping delivery stable while AI pushes more change through the same pipelines. That is a control-systems problem, and CI is where those controls live. Get the platform layer right, and the cheaper minutes are a bonus rather than the whole story.

Check us out at https://latchkey.dev

The 2026 GitHub Actions Reset: Cheaper Runners, Stricter Security, and Smarter Pipelines

Kay — Fri, 04 Sep 2026 00:26:52 +0000

The first half of 2026 rearranged three things at once for teams that live in GitHub Actions: what CI costs, how it is secured, and how much of it a machine can now do on its own. None of these landed cleanly. Prices went down for most people while a new platform charge quietly went up. A self-hosted runner fee was announced, met a wall of objections, and was pulled back within a week. And a security roadmap arrived that will change how workflows pin dependencies and scope secrets over the next two to three quarters.

Here is a grounded read of what happened, with sources, and an honest account of where Latchkey fits.

Hosted runners got cheaper, and a new platform charge arrived

On January 1, 2026, GitHub reduced GitHub-hosted runner prices by up to 39%, with the size of the cut depending on the machine type (larger runners saw the larger relative reductions), per GitHub's own changelog (github.blog). In concrete terms, community reporting put the Linux 2-core rate moving from $0.008 to $0.006 per minute and the Windows 2-core rate from $0.016 to $0.010 per minute (samexpert.com).

Alongside the cuts, GitHub introduced a $0.002 per-minute Actions cloud platform charge that applies to all Actions workflows. For GitHub-hosted runners, that charge is already bundled into the reduced meter price, so it is not a separate line item there (github.com).

Two things stayed the same and are worth repeating, because they get lost in the noise: standard runner usage on public repositories remains free, and GitHub Enterprise Server pricing is unaffected (github.com).

GitHub framed the net effect as small for most accounts: it stated that 96% of customers would see no change to their bill, and that of the 4% affected, 85% would see costs decrease while the remaining 15% faced a median increase of roughly $13 (github.com). That is a reassuring headline. It is also a reminder that the bill depends entirely on your own mix of runner sizes and minutes, which is exactly the thing most teams cannot see clearly.

The self-hosted runner charge that wasn't

The louder story was the one that got reversed. GitHub had planned a $0.002 per-minute charge for self-hosted runners in private repositories, set to take effect March 1, 2026 (github.com). The reaction from developers was blunt. They described billing for runners on hardware they already owned as "absolutely bananas" and as charging "rent" on their own property (samexpert.com).

Within about a week, GitHub retreated, saying: "We've read your posts and heard your feedback. We're postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach" (samexpert.com). The hosted price cuts went ahead as scheduled; the self-hosted charge was shelved.

The lesson for anyone planning CI budgets is less about the specific fee and more about the volatility. Pricing models are moving, and the teams that weather that best are the ones who can attribute their spend to a repository, a workflow, and a runner size before the invoice arrives, not after.

Security is becoming the default, not an add-on

GitHub also published a 2026 Actions security roadmap built around making secure behavior the default, aimed squarely at CI/CD supply chain attacks (github.blog). A few pieces stand out:

Workflow dependency locking introduces a dependencies: section in workflow YAML that locks direct and transitive dependencies to commit SHAs, with updates reviewed as pull request diffs. Policy-driven execution uses rulesets to govern who can trigger which workflows, with an evaluate mode to test policy before enforcing it. Secrets become bindable to specific repositories, branches, and workflows rather than broadly inherited, and write access will no longer automatically grant secret management. GitHub also described near real-time execution telemetry and a Layer 7 egress firewall for hosted runners. The roadmap places most of these in public preview within three to six months and general availability around six to nine months (github.blog).

The through-line is unpinned actions, over-broad permissions, and loosely scoped secrets moving from "known bad practice" to "actively blocked." If your workflows lean on floating tags or a single broadly-scoped token, this is the year that catches up with you.

The market is consolidating on Actions, but not exclusively

Adoption data from JetBrains and TeamCity, drawn from the State of Developer Ecosystem Report 2025 and a dedicated CI/CD survey, puts GitHub Actions at 33% organizational use, Jenkins at 28%, and GitLab CI at 19%, with 18% reporting no CI/CD tool at all (blog.jetbrains.com). Roughly one-third of organizations run two CI/CD tools at once, and about 55% of developers regularly use CI/CD tools (blog.jetbrains.com).

In other words, Actions is the center of gravity, but most shops are not all-in on one tool. That mixed reality is why low-friction, one-line changes matter more than rip-and-replace migrations.

Where Latchkey fits

We build on GitHub Actions rather than around it, so the changes above are the ground we stand on. A few honest notes on how Latchkey lines up with this moment:

On cost, Latchkey gives you cost and performance analytics for your GitHub Actions with nothing to instrument, breaking spend down by repository, workflow, and runner, and showing theoretical and billable cost side by side over time. When pricing shifts under you, that attribution is what turns a surprise into a decision. Latchkey managed runners are up to 69% cheaper per runner minute than GitHub-hosted, and you can see estimated savings for your own usage rather than a marketing average.

On migration, moving a job onto a Latchkey managed Linux runner is a one line change to runs-on, and we can open a pull request that changes only the runs-on lines and leaves every other line byte-identical. Nothing changes until you review and merge. There is no runner fleet to operate, and the runners start in seconds.

On security, Latchkey scans your GitHub Actions workflows for misconfigurations like excessive permissions, unpinned actions, and secret exposure, and surfaces the fix as a reviewable pull request. That maps directly onto the pin-your-dependencies, scope-your-secrets direction GitHub is pushing. It is not a full application security product, and it does not promise to catch every vulnerability. It catches a defined set of workflow problems and shows you the change. Throughout, Latchkey only reads metadata; it never reads or stores your source code.

On reliability, self-healing CI is built into every Latchkey managed runner with no separate fee. When a step fails on an infrastructure or environment signal (a flaky network, a full disk, a missing tool, environment drift), Latchkey detects it, diagnoses the cause, applies a fix while the job is still running, and re-runs the failed step. It does not fix everything, and it is not a promise of a green build. Real defects in your code, compile errors and failing tests and assertions, pass through unchanged so your tests fail truthfully. When a heal traces back to a structural cause, Latchkey can open a pull request proposing a permanent fix that you review and merge. And every attempt is recorded on the dashboard with what failed, what action was taken, and the outcome, so nothing happens silently. Self-healing is on by default and controlled by a single organization-level toggle you can turn off at any time.

What to do this quarter

You do not need to overhaul anything. Three practical moves fit the moment. First, get real visibility into where your Actions spend goes by repository, workflow, and runner, so the next pricing change is a line on a chart instead of a shock. Second, audit your workflows for unpinned actions and over-scoped permissions now, ahead of GitHub's secure-by-default enforcement, rather than during it. Third, treat any migration as a reviewable pull request, not a leap, so you keep the parts of Actions you already trust.

CI in 2026 is cheaper for most, stricter by default, and increasingly able to fix its own environment. The teams that come out ahead are the ones who can see their pipelines clearly and change them one safe step at a time.

Check us out at https://latchkey.dev

The 2026 CI/CD Squeeze: Faster Code, Shifting Prices, and Where Reliability Fits

Kay — Fri, 04 Sep 2026 00:24:32 +0000

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

We Audited 156,808 Failed CI Runs Across Eight Open Source Repos

Kay — Mon, 17 Aug 2026 05:17:44 +0000

I'm Kay, CTO and co-founder at Latchkey. We build managed GitHub Actions runners that repair failures while the job is still running. Before we shipped any of that, we wanted to know what actually breaks CI. Not what people complain about. What the logs say.

So we pulled every failed GitHub Actions run from eight production open source codebases over three months and read them.

156,808 failed runs, across Go, Python, C++, TypeScript and Rust.

The thing that surprised me

Going in, my model of a red build was "someone broke something." Reading a few thousand of these, that model is wrong most of the time.

A package registry 500s. Docker Hub rate limits you. The runner fills its disk on a Gradle cache. Node hits the default heap ceiling and gets SIGKILLed with exit 137. Someone bumps packageManager in package.json and now pnpm isn't on the PATH.

None of those are defects. There is no commit that fixes them. The environment fell over, and the correct response is to fix the environment and run the step again.

And nobody was fixing them. They were being re-run by hand. Someone opens the run, reads a wall of log, decides "yeah, that's flaky," clicks the button, waits eleven minutes. All day, on every team.

That's the actual cost. Not the compute. The interrupt.

The taxonomy

These are the classes we could write a deterministic detector for, which is a much narrower bar than "kinds of failure that exist."

Class	What it looks like
Transient network	Registry timeouts and 5xx across npm, Yarn, pnpm, pip, Go modules, Cargo, Bundler, NuGet. Docker pull rate limits. Git and DNS. API rate limits. Biggest bucket by a distance, and almost all of it is someone else's outage showing up as your red build.
Out of memory	Exit 137, kernel OOM kills, plus Node, JVM and Python signatures. Usually not a leak. Usually a default ceiling that stopped being big enough as the codebase grew.
Disk full	`no space left on device`, inode exhaustion, corrupted caches. Almost always fixed by pruning something rebuildable.
Missing tools	Exit 127 and missing shared libraries. A dependency that happens to be on the GitHub-hosted image and is declared nowhere.
Package manager drift	pnpm not on PATH, Yarn not matching the pin in `package.json`.
Environment and config	Missing env vars, toolchain mismatches, file handle limits.
Flaky tests	Pass on retry with nothing changed.
Real defects	Compile errors, type errors, assertions, panics, genuinely failing tests. The build is telling you the truth.

The hard part is knowing what you're not allowed to fix

This is the whole design problem, and it's where I think most "AI fixes your CI" pitches fall over.

Once you can retry a step, retrying everything is trivially easy and completely disastrous. A tool that reruns a failing test until it goes green isn't a healing tool, it's a mechanism for shipping bugs with a green check on top. Same for --legacy-peer-deps, pip install --no-deps, and || true. The symptom clears. The cause ships.

So the rule we settled on: the system may repair the environment. It may never repair your code, and it may never hide a result.

Compile errors, type errors, assertions, panics and genuine test failures are recognised across a few dozen language and framework signatures, and are never retried and never modified. They fail loudly. That's the point of having a test suite.

The one exception is the flaky-test retry, and it's gated on evidence rather than optimism. A test is only re-run when our own analytics already flagged that exact workflow as one that passes on retry. It runs exactly once. It never edits anything. Without that evidence, a failing test stays red.

There's a related rule I like: if a repeating failure's recent root causes are mostly upstream 5xx and rate limits, we suppress the finding entirely instead of reporting it to you. Someone else's outage is not a problem in your codebase and it shouldn't become your homework.

How it's built

Three layers, cheapest first. Deterministic rules keyed on exit code. Then signature matching against a library of over a hundred known failure shapes. Then, only for failures matching nothing or where a first fix didn't hold, an agent that reads log tails and checked-out files, forms a hypothesis, and picks a fix from the same vetted action set the rules use. It can't run arbitrary commands and can't touch your source.

Most failures never reach layer three. That matters for latency and cost, but mostly for auditability: a deterministic rule can be reviewed, a model's reasoning at 3am cannot.

The rule that caused the most internal argument: when the agent isn't confident, it does nothing and lets the original failure stand. A tool that guesses when it doesn't know is worse than no tool, because then you can't trust the green or the red.

What the corpus gave us

Replaying our detection and repair pipeline against those 156,808 failures:

1,300+ runs auto-greened. Transient failures healed and retried in place, zero human touch.
~700 fix-PRs opened. Permanent fixes for missing system libraries, setup gaps and too-low timeouts.
~$100K per quarter saved, modeled. That one is a model, not a measurement. It assumes a mid-market team on paid runners and prices the engineer interrupt as well as the compute. Take it as a shape, not a number.

Two caveats on the record. This was a retrospective audit against public workflow history, not a live deployment on someone's production org. And the auto-greened count is bounded by what the detectors covered when we ran it, not by what's theoretically fixable. Both should go up.

Where a failure ends up

Four terminal states, and every failure hits exactly one. Healed during the run. Or a pull request with a typed, deterministic edit, labelled verified-at-runtime or proposed. Or handed to your own coding agent over MCP with the root cause, exact failing file and full untruncated logs, secrets stripped. Or explained, with the exact failing job, step and file, which is still a much better morning than a 40,000 line log.

The bit I'd push back on

You should be suspicious of a vendor publishing a study that concludes their product category is necessary. Fair. So here's the version that doesn't sell anything:

Go look at your last month of failed runs. Bucket them by hand into "real defect" and "environment fell over." I'd bet the second pile is bigger than you expect, and that the total human time spent clicking re-run on it is a number your team would be annoyed to see written down.

Whether you fix that with us, with a retry action, or with fifty lines of bash, fix it. The status quo of paying senior engineers to be a retry button is genuinely dumb.

If you want the tooling: Latchkey runs the managed runners this is built into, one line of YAML to switch. We also open-sourced CI Doctor, an MIT-licensed agent skill that does the diagnosis half locally, free, no account.