Google finds coding agents chasing unrelated TODOs
Google’s November 6 Agent Distraction report describes coding agents pursuing bugs beyond their assigned tasks. Its analysis links these detours with higher resource use, highlighting a practical concern for teams delegating software work.
What Google measured
Across millions of file-reading sessions, 13% encountered TODO or FIXME bug references. That measures exposure, not derailment. Secondary action followed 6% of encounters, and 83% of those actions were unprompted. Among unprompted detours, 41% concerned closed tickets and 57% concerned open ones.
After statistical controls, detours were associated with 70% more steps, 77% more tokens and 105% more waiting. This observational analysis does not establish causation or a universal rate for coding agents.
Google’s cleanup agents examined bug and code history before proposing obsolete-comment removals for human review. Closed status alone was insufficient.
Why context selection matters
Anthropic’s September 2025 context-engineering guidance provides useful background. It recommends selecting information for its relevance to the intended outcome rather than filling the available window. The company describes context as something that needs repeated curation as an agent collects tool results and conversation history.
Its suggested approach includes clear instructions, tools with distinct purposes and targeted retrieval. Agents can retain references to files or other information and load details when needed, instead of receiving entire collections upfront. Anthropic also notes the trade-off: runtime exploration takes time and can itself lead to dead ends without suitable guidance.
For longer assignments, the company discusses summarizing conversation history, keeping persistent progress notes and delegating focused research. These are design options for managing context, not evidence that a particular configuration eliminates unrelated work. The guidance predates Google’s report and does not independently validate its numerical findings.
Give the agent a bounded assignment
GitHub’s Copilot task guidance makes the assignment itself a practical starting point. It recommends a clear problem statement, acceptance criteria and directions about relevant files. An issue assigned to the agent should be written with the same care as a prompt, rather than assuming that a brief label provides enough direction.
The documentation also describes a staged workflow: research the repository, agree on a plan, then review changes before opening a pull request. Repository instructions can explain build commands, test procedures and project conventions. This gives the agent a defined way to check whether its work meets the project’s expectations.
GitHub advises starting with simpler tasks while learning what the agent handles well. Broad refactors, ambiguous requests and work demanding substantial domain knowledge may be better kept with a developer. That advice is product guidance, not a measured remedy for Google’s observed detours.
A practical review checklist
Our reading is that teams need an explicit decision point between discovering additional work and authorizing it. A developer fixing a checkout display bug might welcome a note about a nearby issue without wanting that issue folded into the same patch. Recording the discovery separately keeps the observation useful while making the expanded workload a conscious choice.
For a trial workflow, state the requested outcome and the checks required to accept it. Ask for unrelated findings in a separate section of the final report. During review, compare each changed file with the agreed plan and question edits that have no clear connection to the requested result.
Choose measurements that cover the work you want to understand. As our Langfuse AI Gateway coverage explains, model-call records do not automatically include every retrieval or tool execution. Token totals alone can leave important parts of an agent’s activity unobserved.
Measure that workflow locally before claiming savings. Useful records include whether the requested task passed review, which extra changes needed removal and how much reviewer intervention was necessary. A shorter run that misses a requirement is not an improvement. The goal is a completed, reviewable assignment with a scope the team understands.
