Skip to main content

03.16Rule

Reuse before create

How AR Labs stops AI coding agents duplicating code: search before writing, re-read before each edit, and sweep for the same bug after a race fix.

A cabinet of drawers, one pulled out holding a gear that already does the job, under a large magnifying glass.A parts cabinet of mint drawers with one drawer pulled out, holding a gear that already does the job, under a large violet magnifying glass.RULE03.15SEARCHBEFORE YOUWRITEDRAWINGENG-03.15SUBJECTreuse before createSHEET15 OF 26 · AR LABSFOUNDREUSE · EXTEND · PARAMETERISE
On this page
  1. The problem it prevents
  2. How it works
  3. Sweep after a race or lifecycle fix
  4. Adopting it

Reuse before create is the rule at AR Labs that an AI coding agent (an AI agent that writes code, such as Claude Code or Codex) looks for existing code before writing new code, because agent-written code duplicates far more than human code. Before an agent writes a new function, class or pattern, it searches the codebase for something that already does the job, and reuses, extends or parameterises what it finds. During rapid fix-and-retry work it re-reads each file before editing it. After fixing a race condition in one place, it searches for every other place with the same shape and fixes those too.

The problem it prevents

A spec describes what to build; the codebase describes how this project builds things. During planned work the spec dominates the agent's attention and the codebase is read once. During fix-and-retry work attention narrows further, to the immediate problem. Both modes produce duplicates: a near-copy of a function that already exists, a hand-rolled version of a utility the project already has, an existing handler bypassed because the agent called a lower-level function directly. Published research on agent-written pull requests finds markedly more redundancy than in human code (see the code review gate for the study), and review cannot always catch it, because the code being duplicated is not in the diff.

How it works

FIG. 01
flowchart TD
  N["About to write a function, class or pattern"] --> S["Search the codebase by verb"]
  S --> Q{"Something similar exists?"}
  Q -->|"yes"| R["Reuse, extend or add a parameter"]
  Q -->|"no"| W["Write it and say it is new"]
  1. Search by verb, not by name. Look for what the code does (speak, stop, cancel, navigate), because an existing helper may be named differently from the one you were about to write.
  2. If something similar exists, reuse it, extend it or add a parameter. Do not create a parallel version.
  3. If nothing exists, go ahead, and note that what you are introducing is new.

During fix-and-retry work, three habits apply:

  • Re-read the file before every edit. Do not edit from memory of an earlier read. The file may have changed, and memory drifts from what is on disk.
  • Re-read the pattern file you are following before each round of fixes. By the third round, details read at the start of the session have faded.
  • Widen before narrowing. Before writing new code for a fix, ask whether the codebase already solves the problem. The fix for a missing behaviour is often a call to something that exists.

Typical failures it catches, all from voice-app work:

  • An agent asked to add a "speak, then stop" behaviour writes speakAndStop() as a copy of an existing speakAndListen(), when a single parameter on the existing function would have done it.
  • An agent hand-writes polling for the end of text-to-speech playback when the project already has a speak() helper that handles it.
  • An agent calls a low-level startVoiceRecognition() directly and bypasses the existing microphone handler, which also asks for permission.
  • A fix pass focused on one overlay forgets to render the error state a neighbouring screen already handles.

Sweep after a race or lifecycle fix

When a fix lands for a race or teardown bug in one user of a shared resource (an audio track, a media player, a socket, a callback), search at once for every other user of that resource and apply the same guard.

The recorded case: a race in tearing down a text-to-speech audio track was fixed in the one place it crashed. No wider search followed. Three identical unguarded callbacks survived in a sibling class, and one of them later crashed on a test device during manual verification.

A review limited to the diff cannot catch this, because the vulnerable code sits outside the diff. Only a deliberate search at the time of the fix can. Search by the resource and the shape of the failure, then fix everywhere before moving on.

# After fixing an unguarded onCompletion callback in PlayerScreen:
grep -rn "onCompletion\|setOnCompletionListener" app/src/

Adopting it

The rule costs one search before each new function and one re-read before each edit. Put it where your agent reads it for every source file, not in a document it may never open, and add the sweep step to your bug-fix checklist: a fix for a race or teardown bug is not finished until every other user of the same resource has been checked.