Prevent AI Coding Agents From Creating Duplicate Code

AI coding agents can add a second helper, repeat an existing feature, or introduce abstractions that make a codebase harder to maintain. A few project rules and a review process help steer them toward reusing what is already there and making only the smallest change needed.

What You’ll Need

• Access to the repository and its existing tests, formatting rules, and project documentation.
• A way to give your coding agent persistent project instructions, such as a repository guidance file or the agent’s documented instruction settings.
• A clean working tree or a record of existing changes, so you can distinguish the agent’s edits from yours.

Step-by-Step

1. Establish a baseline before asking for changes. Check the project status and current branch, then inspect the relevant files and recent history. Identify existing components, functions, utilities, and tests related to the task. Search by feature name and key terms; if the repository has a symbol or reference search, use it to find definitions and call sites. This gives you concrete examples to point the agent toward and reduces the chance of overlooking an existing implementation.
2. Describe the outcome, not a preselected implementation. State what a user or system should be able to do, the constraints, and how you will know the change is complete. For example, request support for a particular input using the existing validation flow, rather than immediately asking for a new validator. Mention relevant edge cases and compatibility requirements. Avoid prescribing new files, layers, or helpers unless you have established that they are needed.
3. Ask for inspection and a reuse plan first. Before code changes, have the agent identify the relevant existing implementation, explain what can be reused, and list the smallest set of files it expects to change. Ask it to point out any apparent gap that requires new code. Review that plan; correct it if it misses a suitable utility or proposes a parallel implementation. For large tasks, approve one small phase at a time instead of letting the agent make a broad, speculative rewrite.
4. Make repository-specific instructions explicit. Put durable guidance in the project’s established instruction location. Tell the agent to search before adding code, extend existing patterns where appropriate, avoid duplicate helpers and dependencies, and explain why any new abstraction is justified. Include practical boundaries, such as “do not create a second date formatter” or “keep this change within the existing service.” Do not rely on a generic instruction alone: name the files or modules that matter for this task.
5. Set a minimal-change expectation. Ask for the smallest coherent patch that satisfies the stated behavior. Request that the agent avoid unrelated cleanup, speculative flexibility, copied code, and new dependencies unless a concrete requirement calls for them. A minimal patch is easier to review, test, and revert. It is not a demand to cram unrelated responsibilities into one function: reuse should preserve the project’s design and make the result understandable.
6. Have the agent verify before it reports completion. Ask it to run the relevant tests and project checks, inspect its own diff, and summarize files changed, existing code reused, and any new helper or dependency added with a reason. Tests can reveal behavior problems, but they do not prove that code is non-duplicative. Require a separate comparison against the baseline and related implementations.
7. Review the diff for parallel solutions. Look for new functions or files whose names or behavior resemble existing ones, repeated validation or formatting logic, duplicated constants, unnecessary wrappers, and dependency additions. Check whether callers can use the existing function, or whether a small extension to it would be clearer. Also inspect whether tests duplicate existing coverage or fail to exercise the new behavior. Ask the agent to explain questionable additions before accepting them.
8. Revise, retest, and keep the change focused. If you find duplication, ask for a targeted correction: identify the existing implementation, state what should be reused or removed, and preserve the required behavior. Then review the new diff and rerun relevant checks. If the agent’s proposed refactor is broad or risky, separate it from the requested feature and handle it in its own change.

Common Mistakes

• Giving only a broad prompt. “Build a settings page” leaves room for the agent to invent components and data flows. Name the existing page, state the desired behavior, and set boundaries.
• Assuming tests catch duplication. Two implementations can produce the same passing results. Search the code and review the diff as well as running tests.
• Forbidding all new code. A genuine requirement may need a new function or component. Require a clear reason and a check for existing alternatives, rather than blocking necessary changes.
• Accepting a large cleanup with a small feature. Broad refactors make it harder to tell whether the requested change works. Keep unrelated modernization separate.
• Using vague, generic repository instructions. “Write clean code” does not tell an agent where the established implementation lives. Add specific paths and patterns, and keep them current.

Tips

• Point to one or two representative files and say which parts of their pattern should be followed. This is more useful than asking the agent to imitate the whole codebase.
• Ask the agent to distinguish “existing code to reuse,” “code that must change,” and “new code justified by a gap.” That makes its plan easier to check.
• Use narrow tasks and reviewable commits or patches. Smaller changes make duplicate behavior easier to spot and simpler to undo.
• When two implementations appear similar, compare their callers, inputs, error behavior, and ownership before merging them. Similar-looking code may serve different responsibilities.
• Keep project guidance concise and revise it when the codebase changes. Stale instructions that point to removed or superseded utilities can encourage duplication.

Troubleshooting

The agent keeps adding a new helper. Stop before accepting the change. Give it the path and name of the existing helper, ask it to compare responsibilities and call sites, then request a patch that reuses or appropriately extends it. If the existing helper cannot meet the requirement, ask for the specific limitation and a narrowly scoped alternative.

The agent changes too many files. Ask for a file-by-file explanation of why each change is necessary. Revert unrelated edits or restart from a clean working tree with a smaller task. Preserve any work you need before resetting or discarding changes.

It cannot find the relevant code. Check that the agent can access the repository and that its search scope includes the right packages or directories. Provide paths, entry points, and useful terms, then ask it to search definitions and usages before editing.

Tests pass but you still see duplication. Treat this as a review issue, not a test failure. Compare the new code with related implementations, decide whether they share the same responsibility, and ask for a focused reuse change. Add or update tests only when needed to protect behavior after consolidation.

Instructions are ignored or conflict. Check for contradictory task prompts, repository guidance, and tool-specific settings. Remove ambiguity, put durable rules in the documented instruction location, and repeat the relevant constraint in the task. If the agent still misses it, use a smaller task and inspect its plan before allowing edits.

Frequently Asked Questions

Can a coding agent reliably detect all duplicate code?
No. Search and similarity checks can find candidates, but they cannot always tell whether similar code has the same purpose. Human review of responsibilities and callers remains important.

Should I tell the agent not to create any new files?
Usually not. A new file may be the right home for a genuinely new responsibility. Ask the agent to justify it and check for an appropriate existing location first.

Is a repository instruction file enough?
No. Persistent guidance helps, but each task still needs context: the intended behavior, relevant paths, constraints, and a review of the proposed change.

When should existing code be extended instead of reused as-is?
Extend it when the new behavior belongs to the same responsibility and the change remains clear. If extension would make the utility confusing or couple unrelated features, a separate implementation may be better.

What should I check before merging an agent’s change?
Review the diff, compare new logic with nearby code, verify the tests and project checks, and confirm that every added helper, file, or dependency has a concrete purpose.

Related

• Streaming Services Under $8 a Month
• AI-Generated Code in Production: Risks and Safe Deployment
• What Global Tech Leaders Think About AI