AI Coding Agent Failed a Test

When a run goes wrong, don't re-prompt and hope. Narrow the problem to one symptom, 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. A run that went badly can still contain an edit or two that were right, and if you throw everything away you pay for that work again. The diff is also easier to read than the transcript when you are working out where the run went wrong.

Re-prompting harder almost never works. If the agent misread the task, adding "please be careful" to the same prompt gives it nothing new. New information changes the outcome: the file it never opened, the exact error text instead of your paraphrase, or a boundary tight enough to remove the ambiguity. If the second attempt fails the same way as the first, look at the prompt before you blame the model.

Most of these failures trace back to a gap the run never closed: the agent missed the context that mattered, the prompt set no boundary, or nothing checked the result before it landed. Name the gap before the next run, because each one needs a different fix. Adding context, for example, does nothing for a run that had no boundary.

A failing test at least tells you something. The quieter danger is a test the agent wrote against existing code that passes on its first run. It may assert nothing, and a green check on an empty assertion looks the same as a real one. Treat a new test as unproven until you have watched it fail.

1. 1Write down the golden state: the input, and the output the code should produce on the happy path.
2. 2Hand that input and output to the agent as the anchor for the test, or put them in a detailed plan.
3. 3Read the generated test and check that it 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. Nothing in that sentence tells it which one you meant, so say which file may change.

The failing assertion is also the smallest useful piece of context. Send the 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 into the chat.

If a second narrow repair fails the same way, switch to 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. instead of rewriting the prompt. It generates hypotheses and adds log statements that send data to a local debug server, then asks you to reproduce the failure, reads the runtime evidence and makes a small, targeted fix. Once you confirm the fix, it removes the instrumentation. The presenter of a Cursor webinar on QA said it helps most on bugs that span several services or sit nested between logic layers. On those bugs, ordinary agent mode's bias for action can lead it to guess and over-edit.

If a cloud agent opened the pull request, it already tries. Cloud agents automatically try to fix CI failures in the PRs they create, and today that works with GitHub Actions only. Automatic fixing is available on Teams and Enterprise plans. On other plans that include 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. (Premium and up, or a legacy paid plan), ask the cloud agent to monitor and fix CI failures on the PR. On a pull request you opened yourself, tag Cursor in a comment, such as @cursor please fix the CI failures.

The agent also skips an automatic follow-up in some cases, which explains why it can stay quiet on a red check. It stands down when any of these is true:

• You pushed a new commit to the branch.
• You sent the agent a follow-up message.
• The same check is already failing on the PR's base commit.
• The PR has already had 10 CI-failure follow-ups.

Apply the base-commit rule to your own runs too. A check that was already red before your change is not your patch's failure, and asking an agent to make it green asks it to fix a different problem.

You control the feature per PR with a comment: @cursor autofix off stops it, and @cursor autofix on brings it back. To turn it off for all your own cloud agents, open 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 and disable Automatically fix CI Failures.