Agent builds a new parallel implementation that reintroduces an already-solved bug instead of discovering and using the existing working tool

Open 💬 0 comments Opened Jun 29, 2026 by Mig-Sornrakrit

Summary

Faced with a task that an existing, correct tool/script in the repo already performed, the agent built a new parallel implementation instead of discovering and using the existing one. The new implementation diverged from the working path and reintroduced a defect the existing tool had already solved — costing hours and creating a regression the user had to catch ("you already have a working path — use it").

What happened (abstracted)

  1. The repo already contained a working tool/script for the task, with the correct configuration (a key option deliberately set to the value that produces the right output).
  2. The agent did not search for that existing tool. It wrote a new routine for the same task.
  3. The new routine used the wrong configuration (the default / opposite of the option the existing tool deliberately set), reintroducing a bug the existing tool had already fixed.
  4. The agent then spent multiple rounds debugging its own new routine — while running the existing tool would have produced the correct result immediately.
  5. The user had to point out that a working path already existed.

Why this is a problem

  • Reinventing an existing, correct path is pure waste, and the new path silently drops the hard-won settings the original encoded.
  • The agent debugged its own self-inflicted regression for hours instead of using the proven tool.
  • It compounds: every new parallel path is another place to get the configuration wrong, and another thing to maintain.

Suggested behavior

  1. Before writing a routine for a task, search the repo for an existing tool/script/path that already does it (grep by function name / keyword / sibling module) and prefer using or extending it.
  2. If an existing path exists, diff the intended approach against it — especially any configuration/flags it deliberately sets — before writing anything new.
  3. Treat "I'll write a fresh driver/harness/script" as a red flag when an analogous one likely exists; find it first.
  4. When the same family has a working sibling, mirror the sibling's settings rather than re-deriving them.

Environment

  • Claude Code 2.1.177

View original on GitHub ↗