How should teams stop AI code agents from creating duplicate logic?

Make reuse a required decision, not an optional habit

Duplicate logic usually appears when an agent is rewarded for producing a working answer too quickly. Teams should treat reuse as a required decision step: before new code is accepted, the agent has to show what it searched, what it found, and why an existing module, package, or library was not suitable. That turns “should we reuse this?” into an auditable workflow gate rather than a vague expectation.

When you require the agent to justify non-reuse, you also create an artefact that reviewers can challenge. If the agent cannot name a candidate implementation, that is a sign the task was under-specified or the search step was bypassed. If it can name one but still chooses to duplicate logic, the burden shifts to the reviewer to verify that the gap is real, not just convenient.

One practical pattern is to force the agent to cite the search scope in the change request: repository path, package name, shared utility, or service boundary it checked. That makes hidden duplication harder to slip through and gives humans a concrete place to inspect before the code becomes part of the long-term codebase.

What makes duplicate logic hard to spot in AI-generated code

AI code agents are good at producing locally correct code, but they are often weak at recognising that the problem already has a house style, shared helper, or canonical abstraction. Without a reuse check, they may recreate validation, mapping, auth handling, feature flags, or business rules in slightly different forms. The result is not just repetition, but divergence: future fixes land in one copy and miss the others.

This is why the issue is partly organisational, not just technical. A search tool can surface similar code, but only a workflow gate can require the agent to explain why the existing path was not taken. That explanation matters because duplicate logic often looks reasonable in isolation and becomes expensive only after it has spread across services or branches.

If your codebase already has weak module boundaries, the agent will mirror that weakness. The control therefore works best when teams also maintain clear ownership for shared logic, stable package boundaries, and naming that makes reuse discoverable. Search alone is not enough if the underlying code structure hides the reusable path.

How to make the control enforceable in day-to-day engineering

Use the gate at the point where code is proposed, not after merge. A good implementation asks for three pieces of evidence before approval: what existing implementation the agent considered, what search path it used to find candidates, and why the candidate could not be reused. That can be captured in a pull request template, agent instruction file, or pre-merge checklist, as long as it is mandatory and reviewable.

Reviewers should look for two common failure modes: false novelty, where the agent duplicates logic because it did not search deeply enough, and false reuse, where it reuses code that is close but not semantically correct. The control is effective when the agent’s justification is specific enough that a human can tell the difference quickly.

For teams using AI coding assistants, this pairs well with a broader policy on code provenance and review gates. NHIMG’s AI-Generated Code Review Guide explains how provenance markers, branch rules, and blocking gates help keep generated code visible before review, while Vibe Coding Policy Template shows how to make reuse expectations part of the operating policy rather than an informal norm.

Risk and Threat Considerations

Duplicate logic creates a quiet security and maintenance risk because every copy becomes a separate future change point. When business rules, validation, or permission checks are copied into multiple places, fixes and hardening often reach only one version. AI agents can accelerate that spread by generating plausible duplicates faster than reviewers can notice them.

Failure mechanism: The agent bypasses an existing implementation, creates a new copy of the same logic, and the organisation later updates or secures only one branch of the duplicated behaviour.

Impact: Divergent logic increases defect surface, makes audits harder, and can leave inconsistent security decisions in production, especially where duplicated code governs sensitive workflows or access checks.

Practitioner Guidance

What to verify: Do not accept “I did not find anything reusable” without a concrete search trail. The minimum acceptable evidence is the existing module or package name, the search terms or file paths checked, and the reason reuse was rejected.

Decision rule: If the agent cannot identify the reuse candidate it considered, treat the change as incomplete, not merely unconvincing. If it identifies a candidate but cannot explain the semantic gap, force a human review of whether the new logic is actually necessary.

What good looks like: The agent proposes extension or refactoring of existing code by default, and new logic is only introduced when the team can see why the canonical path could not safely absorb the change.

Practitioner takeaway: The goal is not to ban new code, but to make reuse the default and duplication an explicitly justified exception.

Related resources from NHI Mgmt Group

• How should organisations govern AI agents and copilots without creating duplicate security controls?
• What is the difference between code scanning and runtime identity monitoring?
• Why are AI agents creating a new category of secrets risk?
• How should security teams govern AI agents without creating a manual review bottleneck?