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.
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.
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.
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.
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:
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.
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