Keeping tests running in the background while the agent edits

The habit that changed how much I trust Cursor’s agent mode wasn’t a setting inside Cursor at all. It was leaving a terminal open next to the editor, running the test suite in watch mode, the whole time the agent works.

Without it, a broken test is something I discover when I decide to check, which in practice means after the agent has already moved on to step three or four of whatever I asked it to do. With it, a broken test is something I discover roughly thirty seconds after the edit that broke it, while the context for what just changed is still on screen and still makes sense.

The gap this actually closes

Agent mode in Cursor can touch several files in a single turn and keep going into the next turn without necessarily pausing for you to check anything in between. That’s the entire value proposition, and it’s also exactly the property that lets a regression sit quietly for longer than it would with a human making the same changes one at a time.

A human editing five files by hand tends to run the tests somewhere in the middle, out of habit, because switching windows to check is what programmers already do. An agent doesn’t have that habit, and won’t develop one, because it isn’t the one who’ll be debugging the failure three turns from now.

Watch mode puts the habit back, just relocated from the agent’s workflow to a pane that’s always visible. It’s the same test suite, run at the same frequency a careful human would run it, except now it’s running whether or not anyone remembered to trigger it.

What actually shows up on screen

The failures worth paying attention to split cleanly into two categories once you’re watching in real time.

The first is a direct break: the test for the thing the agent was just asked to change goes red immediately. That’s usually informative and rarely alarming, since it’s evidence the agent’s first attempt didn’t fully work, and Cursor will typically see the same failure in its own next tool call and try to correct it. Nothing here needs your intervention.

The second is what actually matters: something unrelated goes red. A test for a module the agent wasn’t asked to touch, breaking because of a change three files away that had a side effect nobody predicted. This is the failure mode background test running exists specifically to catch, because it’s invisible in the diff, invisible in the agent’s own summary of what it did, and only visible in the one place that’s actually checking behavior instead of intent.

Reading a red result as a stop, not a note

The discipline that makes this worth doing is treating a red result as a genuine interrupt rather than something to glance at and mentally file for later.

The instinct to let the agent “finish the current thing” before addressing a failure is understandable and it’s usually wrong, because every subsequent edit the agent makes gets built on top of the broken state. If the regression traces back three turns, unwinding it after five more turns of work is a meaningfully harder problem than unwinding it after one, and the difficulty doesn’t scale linearly. It compounds, the same way debt does.

In practice that means actually pausing the agent, not just noting the failure to deal with afterward. A short prompt describing the specific failure, pointing at the specific test, gets a faster and more targeted fix than letting the agent discover it two turns later buried inside a larger, harder-to-parse context.

Where this needs real infrastructure to work

None of this helps if the test suite itself is slow enough that watch mode can’t keep pace with how quickly the agent edits, which is a real constraint worth being honest about rather than glossing over.

A suite that takes four minutes to run isn’t providing thirty-second feedback, it’s providing four-minute-old feedback, by which point the agent may already be two or three turns further along and the failure is stale news by the time it arrives. This is one of the more concrete arguments for investing in fast, well-scoped unit tests specifically for AI-assisted work: the whole technique depends on the suite finishing before the next edit lands, not merely on the suite existing at all.

If the full suite is slow, a scoped subset targeting just the area the agent is actively working in, run in watch mode, gets most of the benefit without demanding a full infrastructure investment first.

The trust this actually buys

The honest case for doing this isn’t that it catches everything, because it doesn’t. It’s specifically good at the class of failure that’s easiest to miss during a fast-moving agent session: the side effect nobody explicitly asked about, surfacing while there’s still enough context on screen to understand what caused it.

That’s a narrower claim than “background tests make AI coding safe,” and it’s the specific claim that’s actually held up across a lot of sessions. The agent still moves fast. The difference is that fast now comes with a much shorter delay between a mistake happening and someone noticing.

More field notes on Cursor

This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on Cursor specifically, browse the full set at /blog/tag/cursor/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.