Coding Agents Need Explicit Task Boundaries

Summary

A coding agent can produce a correct patch for work nobody requested. Our recommendation is to make task scope an explicit acceptance condition, alongside correctness and cost.

Google’s November 6 report on agent distraction provides a concrete reason to test that condition. It examines agents following bug references encountered in code. The findings are observational evidence from Google’s environment, not a universal performance forecast.

Key Updates

Unrequested work has several forms. Google reports that 41% of unprompted bug detours pursued closed tickets, while 57% concerned still-open bugs. An open ticket therefore does not establish that investigating it belongs to the current task.

Detours correlate with substantial overhead. After adjusting for factors including developer, task type, model tier and files read, Google reports 70% more steps, 77% more tokens and 105% more wait time in sessions with unprompted bug detours. These are conditional estimates, not increases across every coding session or savings promised by cleanup.

Cleanup itself requires judgment. Google describes examining ticket and code history before proposing removal of obsolete comments, with human review. It does not present a randomized trial establishing the resulting reduction in distraction. Primary report.

Why It Matters

Our earlier Agent Cost Savings Need Quality Checks argued for checking outcomes when reducing spend. This follow-up adds a separate acceptance question: did the run stay within the requested work?

For example, a passing test suite would not by itself justify an unrelated refactor discovered during a bug fix. Nor would a useful explanation of a second issue establish that the delay was acceptable. A review needs the original request as well as the final diff.

This suggests two distinct responsibilities. Repository maintainers can keep comments accurate. Workflow owners can define when a newly discovered issue should be reported, investigated as a dependency, or proposed as a separate task. Cleaner context cannot settle that decision for them.

There is also a risk in optimizing for silence. An agent should still surface a relevant defect or blocker. The target is a clear connection between each action and the authorized objective, with separate work recorded for a later decision.

Builder Takeaway

Run a bounded comparison before changing a team's agent instructions or comment-cleanup policy:

• Choose representative past tasks and preserve their original requests, starting commits and acceptance tests.
• Classify extra investigations as necessary dependencies, useful findings to report, or unrelated work. Review the classification against the request, not just the ticket's status.
• Compare the current workflow with one that requires a brief scope check before pursuing an unrelated issue. Record unrequested edits, completion quality, duration and total cost per accepted task.
• Review proposed comment removals with a maintainer. Retain explanations that still document a constraint, even when the linked ticket is closed.
• Keep the previous instructions available. Expand only if task completion remains acceptable and unwanted detours decline.

These are proposed checks, not experiments performed for this article. The decision to adopt them should rest on local evidence; the reported overhead percentages are not a savings target.