The Stale TODO That Sends a Coding Agent on a Side Quest

A developer asks a coding agent to fix a failing test. While reading a file, the agent sees an old TODO(bug/…) comment and starts investigating a different issue. The code comment looks like useful context; the ticket may have been fixed years ago. The result can be extra searches, edits outside the task, and a human reviewer having to pull the agent back. Google’s newly published analysis treats this as a maintenance problem with measurable cost.

Google says it analyzed traces from more than 913,000 coding-agent sessions and found that 13% exposed agents to inline bug references. In 6% of those encounters, the agent took a subsequent action targeting the referenced issue; 83% of those actions were unprompted. The company reports two kinds of detour: some led to tickets already closed or obsolete, while others expanded work on still-open issues the developer had not asked it to handle. Its regression analysis associated the unprompted detours with 70% more steps, 77% more tokens, and 105% more wait time per session. These are Google’s internal trace findings and methodology, not an independently replicated industry-wide rate. ^[1]

Why a comment can outrank the actual request

People learn to distinguish a reminder from an instruction. An agent that reads a codebase as context may treat the reminder as a fresh task, especially if it is concrete, nearby, and linked to an issue that appears actionable. The code itself cannot reveal whether a ticket is closed, whether the TODO is obsolete, or whether the current request is intentionally narrow.

Google’s examples include an agent chasing a bug that had been fixed years earlier and another agent making an unrequested change after following an open bug reference. The second case is not merely wasted inference. It crosses a scope boundary: the developer asked for one outcome, while the tool expands the proposed patch into another. ^[1]

This resembles a familiar human problem—stale documentation—but the cost changes when software reads that documentation repeatedly and can act on it. A comment that once sat quietly in a source file can now influence planning, repository search, and edits in an automated session.

Treat the repository’s instructions as an interface

Teams already maintain build scripts, API contracts, and tests so contributors can use a repository safely. Agent context deserves the same care. Search for TODOs and FIXMEs that include issue identifiers, then compare each reference with the issue tracker. Remove comments that are demonstrably obsolete; rewrite valid ones so they state the constraint or decision a future maintainer needs, rather than issuing an ambiguous command.

Do not bulk-delete every TODO. Some comments mark real deferred work, security invariants, or a deliberate limitation. Google says its own cleanup agents looked at issue history, file history, and subsequent changes before proposing removals; a simple “ticket closed means delete” rule would discard relevant context. The company reports more than 95% human acceptance for its internally proposed cleanup changes, but that figure is Google’s own review result and should not be generalized without comparable data. ^[1]

Repository-level instructions can reinforce boundaries. For example, tell a coding assistant to stay within the requested files, avoid unrelated TODOs, and ask before widening scope. GitHub documents repository custom instructions and agentic review guidance, but instructions are guidance rather than a sandbox: permissions, diffs, tests, and human review still determine what code can land. ^{[2] [3]}

A practical cleanup loop

1. Inventory issue-linked comments. Search for TODO(, FIXME(, and the formats used by your tracker. Include generated or vendored code only where your team owns the context.
2. Check status and history. Confirm whether the linked issue is closed, superseded, duplicated, or still active. Inspect the code history before changing a comment; the implementation may still depend on the described constraint.
3. Rewrite for present-day use. A useful comment records why the code is shaped this way, what invariant must hold, or what concrete follow-up remains. Remove obsolete references after verification.
4. Constrain agents at the workflow boundary. Ask the agent to report any unrelated issue it encounters, not to fix it. Keep proposed changes reviewable and apply least-privilege tool access.
5. Measure side effects. Track out-of-scope files changed, reverted hunks, extra tool calls, and reviewer corrections—not only task completion or token use.

The fifth step matters because more activity is not automatically failure. A genuinely relevant TODO can uncover a necessary dependency. The signal is whether the agent’s detour advances the requested result and whether the human knowingly accepts the expanded scope.

Clean context is part of agent readiness

Google recommends repository cleanup tooling, including analyzers and agents that review stale references. That makes sense only with safeguards: proposed deletions should include evidence, owners should review ambiguous cases, and automated changes should not silently merge. A focused linter can flag old issue IDs without deciding their meaning.

For teams that use code assistants, audit one representative repository first. Measure the number of issue-linked comments, how many point to closed or replaced work, and how often agent changes exceed the prompt’s scope. Then clean the highest-risk directories and compare the same indicators over time. Google’s numbers make the cost plausible; your own workflow must establish whether it is occurring locally.

The broader lesson is simple: codebase health now includes the context machines read. Tests can tell an agent whether a change passes. Accurate comments and bounded instructions help it choose which change to make in the first place.

For related practical guidance, see our articles on GitHub Actions dependency integrity and reviewing AI coding changes.