A human reads // TODO(bug/12345): remove this branch and keeps going. An agent sometimes doesn't. Google's Agent Distraction, published on November 6, 2026, puts numbers on that gap: a comment pointing at an already-resolved bug can add noticeable time to an agent's task.
What was measured
The authors (Sam Saccone and Madhuri Garikapati) used TODO(bug/...) and FIXME(bug/...) as a proxy for stale information. Code gets fixed, the comment stays, and the real record lives in the issue tracker. They cross-referenced agent traces against each TODO's live bug status and the user's prompt, which let them separate work the user asked for from detours the agent started itself. The post cites thousands of engineers and hundreds of millions of agent steps, but gives no exact session or headcount.
| Metric | Value |
|---|---|
| Sessions exposed to a bug-referencing TODO/FIXME | 13% |
| Encounters where the agent acted on the referenced bug | 6% (94% ignored) |
| Of those follow-ups, share the user did not ask for | 83% |
| Of unprompted detours, share chasing closed tickets | 41% |
| Of unprompted detours, share chasing still-open bugs | 57% |
| Sessions with a detour, controls applied | +70% steps, +77% tokens, +105% wait time |
All figures come from the Google post. I did not recompute or reproduce them.
How to read the numbers
The headline is 70/77/105%, but the number to read first is 6%. Most agents ignore the comment. The cost comes from the rare case where they follow it.
Open bugs are the riskier branch. Per the post, 39% of those detours involved editing code. Chasing a closed ticket wastes time; touching an open bug puts changes nobody requested into the diff. One of the post's examples has an agent modifying ModelDownloaderV1 outside the task, then admitting the scope was wrong when the developer pushed back.
Causation or correlation
The authors ran a fixed-effects regression controlling for developer, codebase complexity, task type, model tier, files read, prompt length and more. It is still an observational study. The increases mean "sessions with a detour ran this much longer," not "deleting the TODO removes exactly this much." The data comes from one company's internal tooling and has not been independently reproduced. The cleanup effort's "95%+ acceptance" measures human reviewers approving deletions, not agent performance improving.
Applying it to your repo
Google's cleanup was straightforward. Agents scanned the codebase for references marked fixed or obsolete, checked bug history, file history and code changes rather than trusting the status flag, and sent only confirmed-obsolete items to review. Over six months they removed thousands.
A small team could start like this. The snippet below is an example I did not run, so adapt it to your conventions.
# List TODO/FIXME comments with an issue number (example pattern)
grep -rnE "(TODO|FIXME)\((#|bug/|b/)?[0-9]+\)" src/
- Look up each issue in your tracker and shortlist the closed ones.
- Have a person review deletions. A closed issue may still describe a constraint the comment documents.
- Separately, add a scope rule to your agent instructions, for example: "Do not look up or modify issue numbers the user did not mention."
Limits and open questions
- The study covers only bug-referencing TODOs. Stale READMEs and retired specs were not measured.
- The 6% rate will vary with model and harness. Measure your own traces.
- The payoff of cleanup depends on how often agents touch the code. Rarely visited modules can wait.
Conclusion
In a codebase where agents work, forgotten comments are no longer harmless noise. The evidence, however, is observational data from a single company. Count your own TODO exposure and unprompted detours first, then combine cleanup with scope limits. Managing what enters the context is a recurring theme; see agent token traffic and rereads and the three layers of agent memory.
Sources
- Google Developers Blog, Agent Distraction (published 2026-11-06, checked 2026-11-07)