What happened
In a November 6, 2026 announcement, Google engineers Sam Saccone and Madhuri Garikapati describe an analysis of coding-agent interactions across thousands of engineers. Google used distributed traces spanning hundreds of millions of individual agent steps to examine what happens when an agent reads an inline TODO or FIXME comment that references a bug ticket. The publisher’s premise is that a developer can skim past a stale comment, while an agent may treat it as a call to investigate.
Google cross-referenced comments encountered by agents with the status of the linked bug and with the developer’s original prompt. That lets it distinguish requested work from a detour: the referenced ticket may be closed, fixed, obsolete, or still open, and the developer may not have asked the agent to touch it. Google says TODO comments can remain in a repository long after the underlying issue has been resolved or abandoned, even though the ticket is the canonical record of its status.
Google reports that 13% of the millions of file-reading sessions in its analysis exposed an agent to an inline TODO/FIXME bug reference. Agents ignored the comment in 94% of encounters. In the other 6%, an agent took a subsequent action targeting the referenced bug; 83% of those actions were unprompted by the developer. Among those unprompted detours, 41% pursued tickets that were already closed. Google breaks that group into 32% fixed and verified, 9% obsolete or marked will not fix, and an additional 2% involving duplicate or restricted tickets.
The other 57% of unprompted detours involved tickets still marked NEW, ASSIGNED, or ACCEPTED. Google says the agent expanded its work to investigate or modify an issue outside the prompt. In these cases, 61% involved issue lookup only and 39% included code edits. The announcement illustrates both an agent researching a bug fixed in 2023 after seeing a lingering comment during unrelated work, and an agent changing code for a bug it was not asked to fix before a human challenged the increased scope.
Google says it controlled for developer, codebase complexity, task type, model tier, number of files read, initial prompt length, and the step at which a bug reference appeared. In a multi-way fixed-effects regression with developer-clustered standard errors, the company reports that unprompted bug detours were associated with 70% more steps, 77% more tokens, and 105% more wait time per session. Google labels all of those findings statistically significant at p<0.0001.
The company also describes a remediation workflow. Its agents scan codebases for references to bugs marked fixed or obsolete, then examine the history of the bug, the file, and relevant codebase changes, sometimes across years. Only after confirming that both a TODO and the intent behind it are obsolete do they submit a deletion for human review. Google says this process removed thousands of actually obsolete references over the preceding six months and that human reviewers accepted more than 95% of the proposed changes. The announcement does not announce a price, an external product, or general availability of the cleanup system.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This does not yet fit a pattern New Runtime tracks. Google’s result concerns stale code comments prompting unrequested detours; on its own, it does not establish a broader trend about runtime boundaries, completed-work economics, or verification capacity.
Why it matters
For teams using coding agents, repository context is not passive background. A TODO that an experienced developer recognizes as historical debris can be interpreted as a relevant task signal, increasing cost and potentially widening a task without approval. The risk is most relevant when an agent reads broadly during planning, investigation, or research rather than making a tightly bounded edit.
The finding changes the maintenance calculation for old comments. Cleanup work once deferred as low-value housekeeping may reduce agent steps, token consumption, waiting, and human correction. But the answer is not indiscriminately deleting every comment attached to a closed ticket. Google’s described process checks ticket history, file history, and later code changes before requesting removal. That preserves the possibility that a comment remains load-bearing even if its original ticket no longer is.
For engineering leaders, the practical consequence is to treat stale TODOs as part of the operational context supplied to agents. Codebase hygiene now affects not only human readability but also what an autonomous tool decides is in scope. The measured percentages are Google’s results, not an assured overhead rate for every tool, repository, or task.
Limits and uncertainty
Google’s numbers come from its own traces and analysis. The announcement does not provide an independent replication, a public dataset, or sufficient detail to determine how representative the participating engineers, codebases, models, configurations, and task mix are of other organizations. Its regression controls for several stated factors, but an association between detours and extra steps, tokens, and wait time does not establish the same effect in every environment.
Google reports more than 95% reviewer acceptance for its cleanup changes, but does not define the review population, disclose a comparison group, or quantify errors that may have escaped review. It also does not measure how much the cleanup changes future task success, code quality, or developer satisfaction. The remaining obsolete-comment backlog is undisclosed.
Skill to build now
Run a bounded audit of TODO and FIXME comments that point to issue IDs in one actively agent-assisted repository. For each candidate, check the linked ticket’s current status, then inspect the comment’s intent and relevant file history before proposing removal. Keep deletion as a reviewable change rather than an automatic edit. Separately, test whether your coding-agent instructions explicitly limit it to the requested task when it encounters unrelated issue references.
Reader takeaway
Stale TODO/FIXME comments are potential instructions in an agent’s working context, not harmless repository archaeology. Google’s analysis suggests that they can create measurable detours, including work on closed bugs and unrequested changes to open ones. Maintain them with the same care applied to other inputs that shape an agent’s plan.