A TODO is context, not permission to expand an agent’s task

A TODO can explain unfinished work without authorizing a coding agent to undertake it. Teams should distinguish references from assigned tasks and remove obsolete instructions deliberately. An open linked bug can be useful context while still lying outside the work the user requested.

This retrospective covers the week of November 4, 2026, with evidence through November 8. Google's Agent Distraction article, published November 6, reports an internal observational analysis of agent encounters with bug references. It provides a reason to examine scope boundaries. It does not establish that all comments cause delay or that every model behaves like the agents in Google's environment.

A reference has less authority than an assignment

A repository can contain several kinds of text in the same file. A comment may explain a workaround, name a historical defect or suggest future work. The current task comes from elsewhere. Reading all those materials is often necessary for understanding the code, but treating each suggestion as another assignment creates an uncontrolled expansion of the job.

Consider a hypothetical request to adjust one report's date filter. A nearby TODO points to a different performance issue. Discovering that reference may help the agent avoid misunderstanding the code. It does not, by itself, authorize changing the performance behavior. Even if the issue is open, the original request still defines the work being accepted.

The distinction protects the business side of maintenance. An unexpected improvement can bring a larger review, new behavior to explain and a different release risk. The problem is not that adjacent work lacks value. Its value has not yet been weighed against the commitment already made. A useful discovery can be recorded without silently changing that commitment.

There is a necessary exception in reasoning about dependencies. If the requested result cannot be achieved correctly without addressing the adjacent problem, the relationship belongs in the task explanation. That requires showing why the work is necessary for the requested outcome. Mere proximity in a file or an enthusiastic TODO is insufficient evidence of that dependency.

What the internal analysis can support

Google uses inline bug references as a proxy and relates subsequent agent actions to bug status and the user's prompt. It reports associations and estimates using fixed effects. This is evidence from one internal setting, not an independent randomized demonstration that a particular comment causes a particular delay in another repository.

Those limits matter when turning research into policy. A team should not take a reported association and promise a percentage improvement from deleting comments. Nor should it infer that an unfamiliar model will reproduce the same pattern. The defensible conclusion is narrower: references encountered during a task deserve an explicit distinction between information and authority.

For a maintainer, that conclusion remains useful without transferring a single headline number. The question is whether the finished change follows the requested objective and whether adjacent discoveries are visible. An agent can produce technically plausible work and still make the wrong scope decision. Correctness and authorization need separate attention in the review.

Google's earlier November 3 cost-per-task article supplies context for considering complete agent loops, including retries and verification. It is not independent corroboration of the distraction analysis. Its relevance here is the unit of work: evaluating the whole completed task is more informative than admiring one inexpensive step.

Preserve comments that explain current behavior

Deleting every TODO would confuse cleanup with understanding. A reference to a resolved bug can still explain why a workaround remains necessary. Conversely, an open issue may describe a future change that the current task should not attempt. Issue status is useful evidence about history, but it is not a complete statement of the comment's present purpose.

A deliberate cleanup would therefore ask what the comment does now. If it explains a current constraint, preserve that explanation. If it instructs future work that is demonstrably obsolete, removal may be appropriate within an authorized cleanup. The recommendation concerns judgment about meaning, not indiscriminate deletion based on a marker or a closed status.

This also avoids rewriting history into false certainty. A maintainer who cannot establish whether a reference is obsolete should keep that uncertainty visible. Removing the text merely because it looks old can discard the only explanation for unusual behavior. A cleaner-looking repository is a poor substitute for preserving knowledge that still affects a decision.

Useful initiative can be surfaced separately

The strongest counterargument is that agents should notice adjacent problems. A rigid reading of scope can suppress valuable discoveries and leave obvious defects unreported. That objection is valid. The useful boundary is between noticing and undertaking: the agent can explain the discovery, its relevance and whether it blocks the assigned result.

A separate finding lets the owner decide what deserves another task. It also lets the original change remain reviewable against the reason it was requested. If the discovery is a prerequisite, the explanation makes that dependency concrete. If it is independent, recording it avoids losing the benefit of investigation without converting it into an unsolicited implementation.

For software maintenance, this is a practical ownership rule. Keep explanatory comments useful, clear obsolete instructions only with enough context, and make adjacent work visible before accepting it as part of the task. A TODO should help the maintainer understand the repository while the actual assignment continues to govern the change.