How do I stop a coding agent rebuilding a feature that already exists?

You ask for a CSV download on the billing page. The agent adds a new export service, but the project already has one for reports. The result may work in a demo while creating two authorization paths and two file formats to maintain. Before the agent writes code, ask it to show where the current behavior lives, what can be reused, and what it still needs to learn. Then judge the change in the running product and final diff.

Search for the behavior before choosing a design

Start from the user-facing words: the billing page label, download button, route, error text, and any existing CSV export. Ask the agent to search the actual checkout and report file paths, callers, tests, and the branch it inspected. A repository-wide search can find a helper that has a different name from the feature request. GitHub's code navigation can trace symbols and references in supported languages; local text search can inspect the working tree you will edit. Neither a vague memory of the codebase nor a single search result proves that a component is active. Follow the route or import chain from the running page to the code that supplies it.

Find the page and the existing export path before proposing a new service.
Check whether the candidate is used by the current app, an old route, a test fixture, or a different product.
Record the checkout and branch; another worktree can contain a different implementation.

Ask for a short reuse decision

For the billing example, the agent should compare the existing reports exporter with the requested CSV: who may export, which rows are included, column names, timezone, escaping, and file naming. It may be right to reuse the helper, extend it, or build a separate path. Have it name the evidence for that choice before editing. A broad instruction such as 'never write a new helper' can force bad reuse; the useful rule is to show what was checked and why the chosen boundary fits. If the agent finds a package that could supply the feature, review its necessity and dependency cost before accepting a new install.

A decision record for the billing CSV example.
Candidate	Evidence to inspect	Possible decision
Existing reports exporter	Callers, access check, row mapping, CSV escaping, tests	Reuse or extend if its contract fits
Billing page's current download path	Route, button handler, permissions, error states	Connect to the existing path if it already owns the action
New export service	Distinct security or data contract that existing code cannot satisfy	Add only with a documented reason and focused tests

Give one bounded implementation task

After the inventory, specify one observable outcome: a permitted billing user downloads the expected rows; an unauthorized user cannot; the current reports export still works. Name the files or behavior that should stay intact, but let the agent explain if the search shows a different owner. In Canopy, keep the research and implementation attached to the same project and checkout, then inspect the changed files against the inventory. A second agent can review the reuse decision independently, but a second terminal tab alone does not isolate its edits. Use a separate worktree for independent code changes.

Ask for a plan that names the existing path and the smallest proposed change.
Have the agent stop for a decision if the access rule or CSV contract is unclear.
Keep the acceptance checks in the task, not only in the conversation summary.

Verify the live result and final diff

Run the app from the same checkout and test the billing download with safe sample data. Check the CSV header, rows, empty state, error state, and authorization boundary. Re-run a reports export to catch a regression in shared code. Then review the final diff for duplicate endpoints, helpers, dependencies, and files unrelated to the task. An agent's claim that it reused code is weaker than the imports, call path, tests, and observed behavior. A green build does not show that the exported data or access rule is correct.

Confirm the page, service process, branch, and PR head refer to the same change.
Inspect the final commit after any reviewer-requested revision.
If the implementation remains unclear, ask a qualified reviewer to decide before merging.

Leave a small map for the next session

Once the feature is accepted, record the active route, export helper, access rule, test command, and owner in the project's ordinary documentation or task handoff. Keep that map short and link to the source; stale, exhaustive catalogs can mislead the next agent. Project instructions such as CLAUDE.md can supply stable conventions to Claude Code, but they do not replace checking today's code and branch. Do not write an unverified claim about the architecture into shared instructions just because an agent said it was true.

Copyable resources

Read before you build

Use a read-only first pass. Replace the example with the exact behavior and project paths in your repository.

Task: Add a CSV download to the billing page. Do not edit yet.
Checkout and branch you inspected: [ ]
Search for the page, current download route, existing CSV/export helpers, callers, and tests.
Return: active path from UI to data; possible reuse candidates with file paths; access and data contracts; unknowns; smallest proposed change.
Stop if the existing export's contract or billing access rule is unclear.
After I approve the approach: implement only the agreed change. Test an allowed user, a denied user, the expected CSV rows, and the existing reports export. Show the running result, commands and outcomes, and the final changed-file list.

Frequently asked questions

Should I put 'always reuse existing code' in my agent instructions?

Ask for an evidence-based reuse check. Existing code may be obsolete or have the wrong security or data contract; force-fitting the new task into it can be as harmful as duplicating it.

Can a project map prevent the agent from forgetting the codebase?

A short, maintained map can direct the initial search. It cannot prove that the mapped code is still active in the current branch; check source paths and callers before editing.

What if the agent already built a duplicate feature?

Preserve the diff, compare both paths and their contracts, and choose one reviewed implementation. Run the affected journeys before removing anything; do not delete the older path solely because the new one passes a demo.

Browse more Canopy questions →