Answer
When should an agent inspect the existing code instead of writing new code?
Before writing anything that the system might already do, and always before changing behaviour it did not establish the current shape of.
Before writing anything the system might already do, and always before changing behaviour whose current form it has not read. Writing first produces duplicates that work and changes that fit nothing around them.
The default tendency is to generate, because generating is what these systems are for and because a plausible implementation is always available. That is right for genuinely new behaviour and wrong for two very common cases: the capability already exists somewhere in the system, and the behaviour being changed has a current form that the change must fit.
The duplicate is the more insidious of the two because it works. A second date formatter, a second retry helper, a second way of validating an address: each functions correctly, each will be maintained separately, and each will diverge. The cost is invisible at the moment of creation and appears later as a bug fixed in one place and not the other. Since the check is a search that takes seconds, the sensible default is to search before implementing anything that sounds like a utility.
The second case is modification without inspection. Changing behaviour requires knowing what the behaviour currently is, including the parts that look accidental. Special cases in existing code frequently encode something real — a customer with an unusual arrangement, a legacy format, a bug elsewhere that is being compensated for — and code rewritten without reading tends to remove exactly those, because they look like noise.
There is a third and less obvious case: matching how the system already does things. Even for genuinely new code, reading two or three neighbouring implementations establishes the conventions that no document states — how errors are handled, how things are named, what layer does what. A change that ignores these is locally correct and fits nothing, which is the failure that tests do not catch and reviewers find tiring.
Against all this, reading has a cost and it is not always worth paying. For a small, self-contained, obviously new piece of work, a search-first policy is friction with no yield. The rule that survives is proportional: search before implementing anything that sounds general, read before modifying anything, and sample neighbouring code when working in an unfamiliar area. All three are cheap and none is a blanket policy of reading everything.
The instructional form matters. An agent told to check whether this already exists before implementing behaves differently from one told to be careful about duplication, because the first names an action and the second names an attitude. This is the general pattern for anything you want an agent to actually do.
The second implementation of something always works, which is why nobody notices it for a year.
Siddharth Sharma, Context Theory
Related questions
What if the existing implementation is bad?
Then the choice between extending it and replacing it is a decision worth surfacing rather than making inside a task. Quietly writing a better second version is the worst available outcome, because the system now has both and nobody agreed to that. Report the finding, propose the replacement, and let it be a change of its own.
Does reading first slow things down significantly?
A search is seconds and reading two neighbouring files is a couple of minutes, against a duplicate that costs maintenance for years. The cases where it genuinely does not pay are small, obviously novel pieces of work, and those are easy to recognise. The friction people report usually comes from applying a blanket policy rather than a proportional one.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A duplicate implementation functions correctly, is maintained separately and diverges over time, so the cost is invisible at creation and surfaces as a defect fixed in one location and not the other. | Searching a mature codebase for multiple implementations of a common utility and comparing their behaviour. |
| Software | Apparently accidental special cases in existing code frequently encode a real constraint such as a legacy format or a compensation for a defect elsewhere, and code rewritten without being read removes them because they resemble noise. | Tracing the origin of a special case in existing code through version history before removing it. |
| Response | Reading two or three neighbouring implementations establishes conventions that no document states, and a change ignoring them is locally correct while fitting nothing, which tests do not detect. | Comparing a generated change's error handling and naming against adjacent modules. |
| Buying behaviour | A proportional rule — search before implementing anything general, read before modifying, sample neighbours in unfamiliar areas — captures the benefit without the friction of a blanket read-everything policy. | Timing the search and neighbour-reading steps against the maintenance cost of a known duplicate. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one