AI Coding Agent Failed a Test

When a run goes wrong, resist the urge to re-prompt and hope. Narrow it to one symptom first, then make the smallest change that tells you whether you guessed right.

1. 1Stop the run and save the current diff.
2. 2Check whether the task was too broad or missing files.
3. 3Read the failing command, log or review comment out loud.
4. 4Start a smaller run with one clear done state.
5. 5Run the narrowest check before asking for more changes.

Save the diff before you do anything else. Even a run that went badly usually has an edit or two in it that were right, and if you throw the whole thing away you'll just pay for that work again. It's also far easier to read than the transcript when you're trying to work out where things went sideways.

The instinct is to re-prompt, harder. Look, it almost never works. If the agent has already misread the task, adding "please be careful" to the same prompt gives it precisely nothing it didn't have the first time. What actually changes the outcome is new information: the file it never opened, the error text you paraphrased instead of pasting, a boundary tight enough that the ambiguity disappears. When the second attempt fails the same way as the first, that's the prompt telling you something, not the model.

Most of these failures trace back to a gap the run never closed. Usually the agent missed the context that mattered, the prompt never set a boundary, or nothing checked the result before it landed.

A failing test at least tells you something. The quieter danger is the test the agent wrote against existing code that passes on the first run. It may assert nothing, and a green check on an empty assertion looks identical to a real one. The principle: never trust an automated test that you didn't see fail.

1. 1Determine the golden state - the input and the output the code should produce on the happy path.
2. 2Give the agent that input/output state as the test's anchor, or codify it in a detailed plan.
3. 3Read the generated test and confirm it actually asserts that state.
4. 4Break the code on purpose once to make the test fail, so you know its red means red.

Name the assertion as the thing that must stay true, and put the test file inside the boundary you don't want touched. A prompt that says "make the tests pass" leaves the agent a choice between repairing the code and weakening the assertion, and nothing in that sentence tells it which one you meant.

Say which file may change and the choice disappears.

The failing assertion is also the smallest useful unit of context, and probably the one people under-send. One test name, the exact assertion text, the file it lives in, and the command you ran. That is usually enough for a narrow repair, and it is a far tighter instruction than the whole suite's output pasted in.

And when a second narrow repair fails the same way, that's the point to change mode rather than prompt. Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. forms a hypothesis, adds instrumentation that streams logs to a local debug server, asks you to reproduce the failure, reads the runtime evidence, then makes a small targeted fix and removes the instrumentation. It earns its keep on bugs that span several services or sit nested between logic layers, where ordinary agent mode's bias for action would guess and over-edit.

If a cloud agent opened the pull request, it already tries. Cloud agents automatically attempt to fix CI failures in PRs they create, currently for GitHub Actions only, and automatic fixing is available on Teams today with support for non-Teams accounts described as coming soon.

The follow-up is deliberately conservative, and the skip rules are worth knowing because they explain the silence. An agent stands down if you pushed a new commit to the branch, if you sent it a follow-up message, if the same check is already failing on the base commit of the PR, or once that PR has had 10 CI-failure follow-ups.

To me the base-commit rule is the useful one, because it draws a line the generic advice keeps blurring. A check that was already red before your change is not your patch's failure, and asking an agent to make it green is asking it to fix something else entirely.

Per PR you control it with a comment, @cursor autofix off to stop it and @cursor autofix on to bring it back. The global switch sits under Cursor Dashboard → Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. → My Settings, as Automatically fix CI Failures.