Self-Healing CI: Agents That Write, Test, and Fix Their Own Code

Fail and Start Work

CI (continuous integration) automatically runs tests and builds after code is submitted. When an agent submits code, its work may appear done, but minutes later CI can fail, leaving the investigation to a human. This step can be pre-arranged: when a designated check fails, immediately launch an investigation and hand the entire run to the agent.

GitHub's CI Doctor template follows this pattern. The template defaults to listening to a workflow named CI on the main branch. On failure, it starts an agent that reads logs, code, and related changes, then writes findings and suggestions back to the issue.

At this point the agent has taken over triage and reporting. To let it continue with PR creation and code fixes, the corresponding events and repair workflows must be connected.

Pinpoint This Failure

If the agent only receives "CI failed, please handle," it will likely ask for the repository, run ID, and log snippets — forcing the human to supply context again. CI Doctor passes the repository, failed run number and link, and the associated commit so the agent can trace the failed task, read logs, and examine code.

The key is to pinpoint "this" failure . The failure belongs to a specific commit; if the agent reads already-changed latest code during analysis, the diagnosis may not match. The template also encodes investigation habits: start from the earliest failed task and the first meaningful error, examine related commits, distinguish whether the problem is code, dependency, configuration, or network, and provide evidence-backed suggestions.

Practices like "check logs first," "is it an environment issue," "look at what changed this time" — which normally require several rounds of prompting — can be written in advance. Similar failures will then follow the same investigation routine.

If the code-writing agent should also handle the fix, the PR must be linked to the original coding task, and the commit and CI run must be associated. Otherwise the report is generated automatically but a human still has to find the original session, paste the report, and say "continue."

Figure 1: To return to the original task, first remember the association between PR, commit, and run. This is a teaching wiring diagram; PR events and repair flow need separate integration.

From Report to PR

In GitHub's gh-aw repository, a CI failure report shows the follow-up process.

In February 2026, CI Failure Doctor created report #14295 (https://github.com/github/gh-aw/issues/14295). The error was a test that checks error messages: the program's output engine name order was unstable, and the last item was missing an or, causing a mismatch with the test expectation.

The report attached the run, commit, test, and error details, and noted a blocker: a retry attempt hit a 403 when downloading dependencies, preventing further verification.

This issue was later assigned to Copilot. It submitted fix PR #14313 (https://github.com/github/gh-aw/pull/14313), which sorted the engine list, adjusted the prompt format, and added relevant tests. The maintainer approved and merged the PR.

Here investigation and repair are handled by separate workflows . When the repair task receives the issue, log clues and fix direction are already inside; maintainers can also trace back from the PR to the original problem and the incomplete verification from diagnosis.

Public records do not state whether the originally failing code was also written by an agent, but the flow from failure report to fix PR already shows how this handoff works.

Write Then Investigate

If the code was also written by an agent, can the subsequent investigation be caught as well? Below is a teaching design (not yet executed) to illustrate; the PR check events and repair flow need separate integration.

Suppose an agent modifies a shipping fee calculation. The original rule: orders ≥ 100 yuan get free shipping, otherwise 5 yuan, amounts expressed in cents. The agent changes amount_cents >= 10000 to amount_cents > 10000.

Only one equal sign differs; exactly 100-yuan orders would then be charged shipping. If tests cover this boundary, CI should fail.

Figure 2: Both sides of the threshold may pass; exactly 100 yuan exposes the error. Table results derived from teaching rules, not actual test runs.

The check result is fed back to the coding task, giving the agent clues: the failed test targets the 100-yuan order, expects 0 fee, but current logic yields 500 cents. Comparing this commit with the original rule points to the recently changed comparison operator.

At this point a judgment exists. But if only a report is returned, a human must still say "then fix it."

If the initial instruction was "keep the shipping rule unchanged, follow through until checks pass," this fix stays within the original task scope . The agent can restore >=, verify boundary cases, update the PR, and wait for the next CI round — without stopping after analysis for a human nudge.

Figure 3: Continue along the same task; after checks pass hand to human for review; if rule conflict or stuck, bring records to human. Animation is a teaching flow illustration.

During the few minutes waiting for CI, the agent need not keep running — the task stays pending for the result . If the fix isn't successful after an agreed number of attempts, the agent returns with attempt records instead of endlessly modifying and re-running.

When to Involve Humans

Another situation: the work can continue automatically, yet the human isn't much freer because the agent notifies at every stage — started, found logs, analyzing, discovered test failure.

Each phone buzz forces a context switch only to find nothing actionable.

When wiring the flow, notification timing must also be designed. For the shipping fee error, if it can be fixed per the original rule, the process stays in the task record and notification happens only when PR and check results are ready.

But if documentation says "≥ 100 yuan" while the new requirement says "> 100 yuan", the agent should stop and ask for clarification . The handoff might look like this (illustrative, not actual output):

The 100-yuan order test failed. New requirement writes "over 100 yuan for free shipping", but existing rule and test say "100 yuan or more". Should the free-shipping threshold be adjusted this time? Related requirements, commits, and failure logs are attached; waiting for your confirmation before continuing.

This time the human only needs to confirm the rule; the investigation does not restart from scratch.

CI Doctor makes a similar trade-off on reports: if the same root cause already has an issue, it adds new information; if there are no actionable new findings, it does not create another report. There is no need for humans to read multiple near-identical analyses for the same error failing repeatedly.

Reduce One Prompt

Pick a task that frequently needs nudging. CI fails — logs must be pasted; start with automated triage. Defect feedback arrives — context must be gathered; let the agent organize reproduction clues first. These can be tried independently; once one segment works, connect the next.

After trying, review how many times you spoke up in the middle:

Which sentence was confirming a rule, and which was just "continue investigating," "fix again," "run tests again"?

If the latter are nearly identical each time, they are worth baking into the next task delegation. One less wait for you means the work moves one step further.

References

GitHub CI Doctor template (https://github.com/githubnext/agentics/blob/578e0e0ea6291fed42a36d3fd46cec6a0e86afd8/workflows/ci-doctor.md)

CI Doctor installation guide (https://github.com/githubnext/agentics/blob/main/docs/ci-doctor.md)

Public diagnosis case: github/gh-aw #14295 (https://github.com/github/gh-aw/issues/14295)

Follow-up fix PR: github/gh-aw #14313 (https://github.com/github/gh-aw/pull/14313)

Khazix: Agent automation system sharing (https://x.com/Khazix0918/status/2117054043868860521)