Development

SWE-Touch: The Edit You Make While an Agent Still Runs

SWE-Touch's 3 August 2026 benchmark found resolve rates fall 7.7 points on average when a user edits code an agent is still working on, and the agent often finishes anyway.

The small edit you make in a file while the agent is still running — fixing the typo you spotted, renaming a variable, adding a log line — happens because you’re sitting there watching it work and the fix takes four seconds. It feels harmless: two of your lines against the agent’s hundred. SWE-Touch , a benchmark published 3 August 2026 by Yuqiao Tan, Kang Liu and colleagues, measured what actually happens when that harmless edit meets a workspace the agent believes it owns alone, and found resolve rates on SWE-bench Verified fell 7.7 percentage points on average across nine models — not because the fix was wrong, but because the agent finished and reported success with the human’s conflicting code still sitting in the file.

The failure looks like success until you open the diff

That’s the part worth sitting with: the agent doesn’t crash, doesn’t flag a merge conflict, doesn’t ask a clarifying question. It just says done. Of the 526 runs SWE-Touch tracked that flipped from solved to unresolved after a mid-run edit, 63.3% ended in what the paper calls Retained Conflict — the agent finished its own plan and never re-read the region the user had touched. Another 13.9% ended in Incorrect Replacement: the agent noticed the edit, deleted it, and installed the wrong fix in its place. The taxonomy is model-specific, which is the tell that this isn’t one bug but a spectrum of bad manners. MiniMax M2.7 ends more than 70% of its newly-failed runs in Retained Conflict, ignoring the user outright, while Claude Opus 4.8 shows only 17.2% retained conflict but 37.9% Incorrect Replacement — it notices the change and overwrites it anyway. Same interruption, opposite failure mode, same green checkmark at the end.

The agent doesn't crash or flag a conflict when a mid-run edit breaks its work — it just says done.

Vendors are selling the exact condition agents are least tested for

Every major coding tool is now pitched on this overlap continuing, not stopping for it. Cursor’s changelog advertises “always-on cloud agents that build, test, and ship code while you keep working,” and GitHub’s Copilot CLI shipped a /rewind command this month whose entire purpose is restoring an agent’s changes “while preserving subsequent edits” — a feature that only makes sense if the maintainers assume you’ll keep typing. That assumption has data behind it: SWE-Touch’s own analysis of the SWE-chat session dataset found repository changes attributed to the user in 59.0% of sessions. SWE-chat’s own paper separately reports that users push back against agent outputs — through corrections, failure reports, and interruptions — in 44% of all turns. So if you kick off a cloud or background agent and keep editing in your IDE while it runs, your own two-line fix can be the thing that turns its final “done” into broken code — and nothing in the diff will mark that line as the cause. Yet the resolve rates every vendor quotes are measured in the solo condition, no human touching the repo — the inverse of that 59.0% figure, so roughly 41% of real sessions on SWE-Touch’s own numbers — a mismatch one recent scoreboard comparison already showed produces rankings that drift with whatever condition happens to be measured.

It matters to be precise about what SWE-Touch actually proves here, because the paper is careful about it even where the headline number isn’t. Its interventions are engineered: edits validated so the user’s patch alone fails the tests, the reference patch alone passes, and the two together still fail, averaging 7.0 lines and injected right as the agent reaches that code. Real developers fixing a typo aren’t trying to sabotage the agent. What the session data actually establishes is that users modify the repository mid-run at scale, not that those ordinary edits are adversarial in the way SWE-Touch’s are. Read across from a deliberately conflicting test to an accidental one, the honest claim is that the 7.7-point drop is an upper bound on a real mechanism — the agent’s failure to re-inspect a shared workspace — not a field estimate of how often your keystrokes will actually break something.

Capability blunts the effect, but doesn’t close the gap

The paper’s own numbers make the counterargument, and it’s a real one. Claude Opus 4.8 lost 1.8 points, GPT 5.5 lost 1.3 — both near noise — while the collapse concentrates in cheaper open-weight models like Qwen3-Coder-480B, down 16.5 points. That lines up with SWE-Together’s finding, from a separate benchmark of interactive sessions, that “stronger agents generally achieve higher final success rates while requiring fewer interventions” — evidence that capability, not the mere presence of a human, does most of the work.

Resolve-rate drop after a mid-run edit, by model (percentage points)
Resolve-rate drop after a mid-run edit, by model (percentage points)
CategoryPoint drop
All models (avg)7.7
Claude Opus 4.81.8
GPT 5.51.3
Qwen3-Coder-480B16.5
Source: SWE-Touch, 3 August 2026

SWE-Touch’s own authors concede a similar limit directly. The paper explains that it deliberately uses region-triggered, controlled Counter-Edits to support matched comparisons and interpretable attribution, and states plainly that its results characterize robustness to controlled, simulated task-conflicting edits rather than the full distribution of collaborative user behavior. That’s an honest hedge, not a retraction — a fixed, worst-case edit schedule is what let the researchers isolate cause from effect, and it’s also why the number shouldn’t be read as a universal tax on every developer’s habits.

What the paired findings do settle is where the industry’s evaluation gap actually sits: on frontier models, working alongside an attentive user, the concurrency pitch mostly holds. On everything else — the cheaper models now embedded in free tiers and default plans — the same “build while you keep working” pitch asks the model to do the one thing its scorecard never checked it could do: notice you.

This article was written by AI. How Pipeline works.