# August Update: Insight v2 and Heals That Verify Themselves

> The August Latchkey update: AI Insight v2 with evidence-backed findings you can apply as a PR, heal PRs that prove themselves on their own run, what is coming next, and where we are taking the platform beyond GitHub.

Source: https://latchkey.dev/blog/insight-v2-verified-heals-and-ci-beyond-github  
Kaveh Alemi  
Published 2026-08-01

**TL;DR** AI Insight v2 turns cost, reliability and security findings into evidence you can apply as a PR or hand to your agent. Heal PRs now prove themselves on their own workflow run before you merge. Next, Latchkey starts running CI from your terminal and your agent, not only from GitHub.

## Shipped in July

- **AI Insight v2.** Evidence-backed findings across cost, reliability and security, each with a plain explanation and one clear next step.
- **Apply as a PR, or hand it to your agent.** Cost and security findings open a reviewable pull request; reliability findings hand off to your coding agent over MCP or open the evidence runs.
- **Heal PRs that verify themselves.** Every heal PR is labelled verified or not verified, and its own workflow run confirms the fix before you merge.
- **Control over heal PRs.** At most one PR per kind of failure, and a "stop proposing fixes" choice you can undo.
- **Smarter retries for flaky tests.** A single retry, only where your workflow's own history shows the test is flaky.
- **Broader ecosystem coverage.** Self-heal recognises transient failures across more build tools, package registries and browser test frameworks.
- **Easier onboarding and a rebuilt docs site.** Dashboard-first signup, guidance for personal accounts, and documentation in English, Japanese and Brazilian Portuguese.
- **Latchkey for Open Source.** The Scale plan free for approved open source projects.

This is the August update, covering what we shipped in July and where the platform is going. July was about making our two AI surfaces honest: AI Insight was rebuilt so every finding carries evidence and one concrete next step, and self-heal learned to prove a pull request works before calling it verified. After that come the changes already in motion, and the bet behind them: Latchkey as the place CI runs, not only the machine a GitHub Actions job lands on.

![Latchkey Ledger No. 08: Insight v2, heals that verify themselves, and CI beyond GitHub](/blog/images/ledger-2026-08-cover.png)

## Platform core: AI Insight v2, findings you can act on

The first version of AI Insight produced a lot of text, much of it advice you had to turn into work yourself. A tool that sends many messages that lead nowhere teaches you to ignore the one that matters.

Insight v2, live on July 9, starts from a different rule. A finding exists only when we can point at something real in your CI history and put a number on it: dollars a month, minutes per run, or a count of risky references. If we cannot quantify it, we do not show it. The AI writes the plain-language explanation of a finding that already exists; it does not decide what is wrong.

Findings fall into three areas:

- **Cost.** Jobs running on a bigger runner than they need, priced from what you were actually billed, with the monthly saving of moving down a size.
- **Reliability.** Workflows that are flaky (a retry passed and masked an earlier failure), workflows that have got noticeably slower, and failures self-heal diagnosed but could not fix.
- **Security.** Actions referenced by a mutable tag instead of a pinned commit, so the code you run can change without a diff in your repository.

A smaller group of adoption suggestions (turn on self-heal, add caching, connect your coding agent) are one-click setup steps. Each finding card shows the evidence, a short explanation of why it matters, and one primary action.

![The Insight hero in our own latchkey-dev org on July 28: nine open findings, "Apply all 6"](/blog/images/ledger-2026-08-insight-hero.png)

*Our own org on July 28. Nine findings, but "Apply all" covers six: the three reliability findings are investigate-only by design.*

### Apply, hand off, or investigate

**Apply** opens a pull request on your repository. For an over-provisioned job, the PR moves `runs-on` down one size. For an unpinned action, it pins the reference to a full commit SHA and keeps the tag as a comment so you can still read it:

```text
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@<full 40-character commit sha> # v4
```

Generated PRs only touch workflow files, only owners and admins can apply, and each apply records who did it. Nothing lands on your default branch until you merge it.

**Fix with your coding agent** is for reliability findings, where we do not open PRs, because a flaky test or a slow build is usually about your code. The button gives you a prompt to paste into your agent, carrying the finding, the evidence runs and the steps to connect the Latchkey MCP server, so the agent can pull the failure logs itself.

**Investigate** opens the evidence runs behind a finding with a chart. No diff, no PR.

### Heal failures become findings

Failures self-heal diagnosed but could not fix now appear as reliability findings too, grouped by workflow and kind of failure, with **Review proposed PR** when a heal PR is already open. We also cut notifications down to new findings, merged PRs you applied, and a weekly digest.

## Platform core: heals that verify themselves

Self-heal repairs the environment a job runs in, never your code. Usually it fixes a failure in place. Sometimes the right fix is a permanent change to a workflow, and then it arrives as a pull request you review. Our problem: a heal PR was sometimes a proven fix and sometimes a well-informed guess, and both looked the same.

### Labelled at birth

Every heal PR now says which one it is: **Verified at runtime** if the change was applied on the runner and the step then passed, **Not verified** if we could not try it in place.

### Verified on its own run

A heal PR edits the workflow that failed, so opening it runs that workflow, and we use that run as the test. The PR description gains a "Latchkey verification" section:

| The PR's own run | What the PR says |
|---|---|
| Passes | Verified |
| Fails or times out | Failed verification |
| You re-run it | The newest attempt counts |

Only the original failing workflow counts. We never auto-close a PR that fails verification; a person decides.

### Fewer, better proposals

Self-heal is also stricter about what it proposes. A fix has to be backed by what the failing step's logs actually say, it will never propose supplying a secret or anything that makes your workflow less safe, and it opens at most one PR per kind of failure. If you do not want fixes for a failure at all, **Stop proposing fixes for this failure** on the finding card stops the PRs until you undo it, without hiding the finding.

### More of your stack covered

**Retries for tests that are actually flaky.** Test failures are your code, and real failures stay red. The one exception: when Insight has a flaky-workflow finding for a workflow, a failing test run there gets a single retry, and if those retries stop turning runs green, they stop.

**pnpm and Yarn, fixed on the spot.** `pnpm: command not found` used to be a failure self-heal could only report. Runners now have pnpm ready, and self-heal can enable the package manager a job expects without touching your workflow.

**Broader ecosystem coverage.** Self-heal now recognises transient failures across a wider set of tools: Gradle and Maven, Rust's crates.io, Yarn Berry, Playwright and Cypress browser downloads, npm and PyPI rate limits, and private registries for pip, Docker, Bundler, Go modules, pnpm, Composer, Terraform providers, uv and conda. It also reads a failing step's full output, which matters for tools like Maven that print errors to standard output.

**Cache isolation per organization.** Each organization's caches are reachable only by that organization's jobs.

## Onboarding, docs, and three languages

**Dashboard-first signup.** Your first GitHub login lands on the dashboard, and setup happens in place. If you install on a personal account, we now explain that GitHub organizations are free and walk you through creating one.

**Docs, rebuilt.** One long page with video embeds became a proper docs site in seven sections, illustrated with real screenshots from our own org.

**Japanese and Brazilian Portuguese.** The marketing site, the docs and the Learn library are available in both. The dashboard stays in English for now, because it changes too quickly to keep three languages in step.

**Latchkey for Open Source.** Approved open source projects get the Scale plan free, with no subscription. You can apply at [/open-source](/open-source).

## Our own month, in one screenshot

We run our own CI on Latchkey runners with self-heal on. Here is the self-healing page for our `latchkey-dev` org from June 29 to July 28.

![Self-healing in the latchkey-dev org, June 29 to July 28, 2026: 78 attempts, 76 healed, 97 percent, heal rate by category for config and network](/blog/images/ledger-2026-08-self-heal-dogfood.png)

*78 heal attempts, 76 healed. Every config-category failure healed; network failures healed less often.*

Two caveats. This is one organization, our own, over one month, and it is not a benchmark for anyone else's pipelines. And the shape of the chart matters as much as the total: almost all of the attempts came before July 8, and the last three weeks were close to silent. A quiet CI month is a good month, but it is also a small sample.

## Coming next

The largest change coming is that a Latchkey run will no longer need to start with a push. This month we are bringing runs to your terminal: send the code in your working tree to a clean Latchkey runner, stream its logs, and get the result back where you are already working. The same runs will be available to your coding agent through the Latchkey MCP server, so an agent can start a check, read the outcome and try again without a human relaying anything.

Failures from those runs will get the same treatment as failures from GitHub Actions. Self-heal still repairs the environment, and when a failure is about your code, the diagnosis goes to your agent.

Insight will connect to that loop. When your agent works on a reliability finding, we want it to be able to confirm its fix on a real runner before it opens a pull request, rather than asking you to trust a guess.

On Insight itself, reliability findings stay investigate-first. The pressure to let them open pull requests for flaky tests is real, and we are going to resist it until the evidence says a PR would be right more often than it would be noise.

## Platform vision: CI beyond GitHub

Today, Latchkey is a runner inside someone else's CI. You push, GitHub Actions owns the queue and the check, and a job with a `latchkey-*` label runs on our runner. That was a good place to start. It is also a ceiling.

![Today: git push to GitHub Actions to a Latchkey runner. Heading: terminal, coding agent or git push into Latchkey, with version control as an integration](/blog/images/ledger-2026-08-direction.png)

Most code at Latchkey is written by agents now, and CI is the quality gate. An agent that can only learn whether its change works by pushing and waiting is working with one eye closed. Every round trip through a remote queue is time the agent spends idle and context it has to rebuild. We want run, read the result, fix and run again to be a loop an agent closes by itself, on the same clean runner your pipeline uses.

That is why we are starting to build Latchkey as the place CI runs:

- **Runs that do not start with a push.** Check your work on a clean Latchkey runner from your terminal or your coding agent, before you push rather than after.
- **Version control as an integration.** Your code host plugs in for what only it can do, rather than being the only way in.
- **GitHub Actions keeps working.** Existing workflows on Latchkey runners stay exactly as they are.

This extends the bet from earlier issues rather than replacing it. Self-heal keeps the environment out of your way, the MCP handoff gives your agent what it needs to fix your code, and running CI directly is what lets the agent check that fix without waiting on a push. None of this section has shipped yet; I will report on what did in the next issue.

Previous issue: [July Update: Your Coding Agent Can Fix What Self-Healing Won't](/blog/self-healing-ci-and-the-mcp-handoff) · Next issue: [September Update: Meet the Latchkey CLI](/blog/latchkey-cli)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt