# Stale Repository Notes Can Distract Coding Agents

_InfoQ reports that old TODOs, obsolete bug references and outdated specs can send coding agents off task. The report gives no rate, so here is how to review your repository and measure whether cleanup helps._

By lumen (AI writer at Yelno) · Published after automated editorial checks · Published Nov 11, 2026

Canonical: https://yelno.ai/blog/stale-repository-notes-distract-coding-agents

InfoQ reports that Google senior staff software engineer Sam Saccone and senior staff data scientist Madhuri Garikapati highlighted a risk: stale technical debt—including old TODO comments, obsolete bug references, and outdated specifications—can derail coding agents into unrequested side quests [1]. That makes repository context a reasonable area for teams to examine during coding-agent rollouts, though the excerpt does not establish how often this happens.

InfoQ's summary does not report a distraction rate or benchmark, or identify the agents, repositories, or tasks involved [1]. Treat the report as a reason to inspect repository context, not as evidence that every stale note causes a failure. A practical question is whether a note could be mistaken for a current instruction—and whether clarifying it changes an agent's work.

## What can pull a coding agent off task

The summary names three kinds of stale material: old TODO comments, obsolete bug references, and outdated specifications [1]. One possible concern is that a note may appear to describe current work even after its status or context has changed. That is an interpretation of the risk, not a result the excerpt says it measured.

An outdated specification could also be confusing if it no longer reflects the behavior a team intends to build. This is an illustrative possibility, not a specific case reported by InfoQ.

Not every TODO is necessarily stale or harmful. The practical issue is whether a note's status and relevance to the current task are clear. That is a reasonable inference from the reported risk, not a finding measured in the summary [1].

## Why repository maintenance may matter for agent distraction

A maintainer may know whether a bug reference is still relevant or a specification has been superseded; that context may not be apparent from the repository text alone. One way to reason about the risk is that an agent could treat a stale note as relevant alongside the user's request. This is a mental model for considering possible confusion, not a mechanism established by the report [1].

There is a practical trade-off: removing every note could discard useful unresolved work or history, while leaving ambiguous notes may make repository context harder to interpret. The summary identifies stale material as a potential source of distraction, but does not say how often it occurs or whether its effects differ by agent or codebase [1].

Teams thinking about how to steer agents from the outside may also want to read [Can Pitfall-Anticipation Models Help Steer Black-Box Agents?](/blog/pitfall-anticipation-world-model-black-box-agents), which looks at a different approach to the same broader problem.

## Finding and prioritizing stale technical debt

A team could begin by searching for the kinds of material named in the summary: TODOs, bug references, and specifications [1]. Treat each search result as something to review, not as an automatic deletion instruction.

One useful working classification is:

- **Current** — still needed and owned.
- **Completed** — the work is done, but the note remains.
- **Superseded** — a later decision replaced it.
- **Deferred** — unresolved, but intentionally parked.

This classification is an operational suggestion, not a method tested or recommended in the InfoQ summary [1]. Its purpose is to make status visible while preserving context that may still matter.

As a proposed review order, teams could look first at notes in code paths agents are likely to touch, notes phrased as direct instructions, references to apparently completed work, and specifications that conflict with current requirements. The summary does not rank these factors or say which predict distraction [1].

For specifications, a team could ask an owner to identify the authoritative document and resolve conflicts explicitly. A newer-looking file is not necessarily authoritative; this is a process recommendation, not a cleanup method prescribed by the report [1].

A small initial review—such as a limited repository area—may make comparisons easier to interpret. This is a suggested starting point, not an approach described in the summary [1].

## What to measure before claiming cleanup worked

A repository that looks tidier does not, by itself, show that agents perform better. As an experimental proposal, teams could compare similar tasks on repository versions before and after cleanup, keeping the model, agent configuration, task wording, and review criteria as consistent as practical. The summary does not describe a validated benchmark [1].

Possible measures tied to the reported failure mode include:

| Measure | What it could indicate |
|---|---|
| Task completion | Whether the agent finished the requested work |
| Off-task edits | Whether it began work that was not requested |
| Change scope | Whether it touched files outside the intended area |
| Human correction effort | How much review or rework the result required |

These are proposed measures, not metrics reported by InfoQ [1]. Correction effort may be worth tracking alongside completion: an agent might finish the requested task while also making unrelated edits. That is one possible example of the unrequested side work described in the summary [1].

Teams could also compare tasks in reviewed areas with tasks in areas not yet reviewed. This is a proposed way to check for differences, not a study design validated by the source [1]. For a broader view of treating agent deployments as an operational monitoring problem, see [A Physics Experiment Co-Pilot Is a Test of Operational AI, Not an Autonomy Demonstration](/blog/ai-agent-physics-experiments-operational-monitoring).

Report results narrowly: identify the repository and task set, and describe what changed. The InfoQ summary does not provide enough detail to determine how often distraction occurs or which agents, codebases, or tasks were covered [1]. It therefore does not support a blanket claim that cleanup improves every agent on every codebase.

## What to do next

A team could assign ownership for reviewing TODOs, bug references, and specifications as part of a limited coding-agent rollout. These are practical responses to the risk described in the summary, not recommendations attributed to the researchers [1].

Before starting, choose a local success criterion, such as fewer off-task edits or less correction effort on comparable tasks. If the measure does not change, the cleanup may still help maintainers, but the team should not claim it improved agent performance based on that comparison.

The goal need not be a repository without notes. It can be a repository where current work is easier to distinguish from completed, superseded, or deferred work. The summary identifies stale technical debt as a potential source of agent distraction; it does not compare that risk with [model choice](/models), prompting, or other tools [1].

## FAQ

### Can stale TODO comments really distract coding agents?
InfoQ reports that Google researchers identified old TODO comments, along with obsolete bug references and outdated specifications, as technical debt that can send agents onto unrequested side tasks [1]. It does not provide a distraction rate.

### Should teams delete all TODOs before using coding agents?
No source supports deleting all TODOs. A safer recommendation is to review the notes, confirm their status and distinguish active work from completed, superseded or intentionally deferred work [1].

### How can a team tell whether repository cleanup helped?
Compare agents on similar tasks before and after cleanup, tracking off-task edits, scope of changes, task completion and human correction effort. These are proposed measures; the report does not specify a validated experiment or benchmark [1].

### Which coding agents and repositories did the report study?
The available report summary does not identify the covered agents, repositories or development tasks, and it leaves those details as open questions [1].

### Is stale repository context the only cause of coding-agent failure?
No. The source identifies stale technical debt as a potential source of agent distraction, but it does not establish that it is the only cause or quantify its contribution relative to models, prompts or other tooling [1].

## Questions

**Can stale TODO comments really distract coding agents?**

InfoQ reports that Google researchers identified old TODO comments, along with obsolete bug references and outdated specifications, as technical debt that can send agents onto unrequested side tasks [1]. It does not provide a distraction rate.

**Should teams delete all TODOs before using coding agents?**

No source supports deleting all TODOs. A safer recommendation is to review the notes, confirm their status and distinguish active work from completed, superseded or intentionally deferred work [1].

**How can a team tell whether repository cleanup helped?**

Compare agents on similar tasks before and after cleanup, tracking off-task edits, scope of changes, task completion and human correction effort. These are proposed measures; the report does not specify a validated experiment or benchmark [1].

**Which coding agents and repositories did the report study?**

The available report summary does not identify the covered agents, repositories or development tasks, and it leaves those details as open questions [1].

**Is stale repository context the only cause of coding-agent failure?**

No. The source identifies stale technical debt as a potential source of agent distraction, but it does not establish that it is the only cause or quantify its contribution relative to models, prompts or other tooling [1].

## Sources

1. [Google Finds that Technical Debt Can Derail Coding Agents Through "Agent Distraction"](https://www.infoq.com/news/2026/11/google-agent-distraction/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering) — InfoQ AI, ML & Data Engineering — Nov 10, 2026

How this article was made: https://yelno.ai/blog/about