If you've ever watched an AI coding agent — the kind that lives in your terminal, reads files, runs commands, and edits code on its own — you've probably seen it get stuck. It runs the wrong test, misreads an error, tries the same broken fix three times, and eventually gives up or produces something worse than what it started with. Most research so far has looked at these agents the way you'd look at a car crash: at the wreckage. Did it succeed or fail? What was the final score?

This paper takes a different approach. The authors argue that failure isn't a moment — it's a process. Agents don't just fail; they drift into failure over many steps, often crossing a point of no return long before they visibly break. So the researchers did the first large-scale study of what those trajectories actually look like, tracing the sequence of tool calls, reasoning steps, and mistakes that lead a CLI coding agent from a hopeful start to an unrecoverable dead end.

The key insights are worth chewing on:

• Failures compound. A single small misstep — like misreading a file path or misinterpreting an error message — often doesn't kill the task on its own. But it corrupts the agent's mental model, and every subsequent action is based on that corrupted picture. By the time the agent notices something is wrong, several turns of bad reasoning have already been baked in.
• There's a "point of no return." The researchers identify a phase where recovery is still possible if the agent backs up and reconsiders, and a phase where it isn't. Most agents blow past this threshold without recognizing it, doubling down instead of stepping back.
• The visible symptom is rarely the real bug. When an agent finally errors out or produces garbage, the immediate cause usually traces back to something that happened many steps earlier. Studying only the final failure hides the actual mechanism.
• Certain failure patterns are stereotyped. Things like hallucinating a file's contents, misreading test output, or getting locked into a repair loop show up over and over — meaning they're addressable if we design for them.

Why should you care? Because everyone is racing to deploy these agents to fix real bugs, ship real features, and touch real production systems. If we only measure them by pass/fail, we're flying blind on how they fail — and blind teams can't build the guardrails, checkpoints, or recovery prompts that would make agents genuinely reliable. This paper reframes reliability as an intervention problem: catch the drift early, and you catch the failure before it happens.