The second lane: why agents duplicate code in existing systems

Coding agents in existing systems often place a second implementation next to the existing path. This article explains the phenomenon, backs it with my own analysis of correction findings from a branch's Git history, and describes a review process with a planning gate, an independent auditor, and a machine-readable verdict.

FC
Frank Csehan
June 28, 2026 · 14 min read

When a coding agent works through a ticket, it often builds a second implementation next to the existing path without using that path. The feature works, the tests go green, and the repository now contains one piece of logic twice: one old, one new, both slightly different. In research, the phenomenon is called semantic duplication or redundant reimplementation. I call it the second lane here: the agent opens a new lane although a validated one already exists beside it.

Why the agent duplicates

The cause is a grounding problem, a gap between what the agent sees of the codebase and what is actually there. A language model reads the repository file by file in a limited context window. It has no global map of the structure. When the matching existing path lies outside the loaded context, the model derives logic again that already exists. In a large system that has grown over years, the relevant code often sits outside the window.

Ticket shape adds to the problem. A terse request such as “implement X” tends to create a new helper. A safer instruction wires X into the existing path and documents every affected surface. A green test often proves too little. It shows that the new path works. It does not check whether the actual product path calls it.

Data now backs this observation. The study “More Code, Less Reuse” (arXiv 2601.21276, 2026) compared AI-generated and human pull requests using objective code metrics. According to the paper, AI-generated changes contain more duplicative code and reuse existing functions less often. In an existing system, that is expensive because every copy has to be maintained, tested, and understood separately later.

Corrections from a branch

I see this in all feature implementations in my fairly large codebase, about 600K LoC. In my projects, every feature runs through a fixed review process by default: implementation, independent audit, and hard gates. This evaluation is one example of that process. From the review artifacts of one branch and the corresponding fix commits, many concrete correction findings could be counted from the Git history, meaning places where a first agent run got something wrong and a downstream step had to correct it. The rate is high: across just over fifty evaluated commits, depending on how one counts, between 75 and 86 percent of the reviewed implementation units needed a correction, a different scope, or another review. The most frequent classes break down like this:

RankCorrection classShare
1Tests/gates did not hard-cover the claim27.8%
2Ticket/scope/dependency requirements were contradictory or ignored22.2%
3Existing product path/surface not fully wired16.7%
4Runtime/data-contract bug: merge, default, Codable, hash16.7%
5Documentation/schema/evidence drift16.7%

The second lane from the first section sits here at rank 3, “existing product path/surface not fully wired”. In the measurement, it appears as its own error class at just under 17 percent. By “claim” in the first row, I mean an asserted result, for example an agent’s statement that an acceptance criterion is fulfilled. The distribution adds detail beyond the correction count. It shows which type of error a downstream reviewer can catch at all and which type arises before implementation. I treat the second lane separately here because, in a later production setting, it is the most expensive and hardest problem area to correct. Production errors in those places are extraordinarily hard to find and fix. This evaluation also documents the need to establish a review and audit agent as a fixed part of the development pipeline.

Every class in the table is a finding from the audit model. The corrections come from its review artifacts and from the fix commits that followed. The distribution is therefore the reviewer’s balance sheet, a record of what an independent model caught before it could move into a later state of the system. Without that review pass, the defects would initially have gone through because the implementation itself had reported them as done.

For the most frequent class, just under 28 percent, the reviewer found insufficient tests. The implementation had delivered tests that only kept the happy path green and produced no red counter-evidence. A trigger matrix, for example, did not cover the triggers it claimed to check, and a negative test did not even create the failure case. The correction in each case was to build the tests so they fail when the claim is false. A team that accepts its own work misses this class because a green run looks like evidence.

The second-largest class, just over one fifth, was in the specification. Tickets were ambiguous or cyclically cut, a dependency was not marked as a hard precondition, a final gate was scoped too narrowly, and the scope of two tickets did not match the actually released state. The reviewer found these contradictions by comparing tickets, README, and dependencies.

At rank 3, the second lane appeared as a surface that was not fully attached to the shared backbone. A second entry point had been decoupled from the shared resolver that a first one already used; alternative bootstrap paths lost data along the way; in one place a second resolution lane appeared next to the existing path without reusing it. The correction was a shared helper and proof that all surfaces use the same backbone.

The remaining two classes concerned data contracts and drift. In data contracts, the issues were a missing safe default, empty deltas that overwrote existing values, and serialization that was ambiguous. In drift, schema, app help, and reference state diverged from the actual code; that blocked releases because agents use exactly these artifacts as contract sources.

Across all classes, the audit model is the place where a problem becomes visible that a self-accepting development team would have passed on unchecked. The measurement justifies the second reviewer across the whole distribution.

Implementer and auditor as a refutation process

Against the second lane and the other error classes, a division of labor helps. I run it in my projects as a gate process. One agent implements along the ticket, repository rules, and existing paths. A second agent with fresh context tries to refute the claim. Hard gates, re-runs, greps, and artifacts decide the result. The implementer’s self-summary does not count as evidence. A fail or an inconclusive stops the merge.

The adversarial stance matters. A second model that only reads the same soft summary and nods it through helps little. It becomes useful when it greps code paths, follows call sites, reruns tests, compares baselines, and looks deliberately for red counter-evidence.

A model mix helps as well, for example Claude or Opus as implementer and a Codex or GPT model as auditor. Different families have different strengths, search patterns, and error profiles, and a model that accepts its own output judges too leniently. The actual safety gain comes from separating role and context, from the refutation mandate, from hard gates and reproducible re-runs, and from fail and inconclusive actually stopping the merge.

The major providers follow a similar direction. The relevant line consists of several pieces: explore the codebase before code is written; define a plan and clear done criteria; support the change with tests and review; inspect the diff with fresh context; return findings to the implementer and review again after correction.

OpenAI describes a planning phase first for difficult Codex tasks. Codex is supposed to gather context, clarify open questions, and build a plan before implementation begins. For large repositories, OpenAI names four fields for the task: goal, context, constraints, and a clear “Done when”. The last point is central for brownfield work because “done” is tied to observable states, such as passing tests, changed behavior, or a reproduced bug that no longer reproduces afterwards. According to the documentation, the review loop includes tests, relevant checks, confirmation of the result, and a diff review for bugs, regressions, and risky patterns. The review surface can inspect uncommitted changes, branch diffs, and individual commits; inline comments on the diff become working context for Codex again. OpenAI uses subagents for bounded checks: exploration, tests, triage, or review perspectives such as security, test gaps, and maintainability. Applied to the second lane, this means: the auditor reads the diff, tests, and task. The implementer’s success story is only a claim to be checked.

Anthropic is the most explicit about this pattern. In the Claude Code best practices, there is an adversarial review step: before completion, a subagent should review the diff in fresh context and report gaps. The reviewer sees the diff and the criteria, but no long implementation rationale. For correctness checks, Anthropic points to /code-review, which reviews the current diff for bugs in a fresh subagent and returns findings to the running session. Anyone who wants to check against a plan should name the plan, the diff, and the finding criteria explicitly, such as implemented requirements, tested edge cases, and scope adherence. The implementation session can then correct the findings and trigger review again. This creates the cycle I describe here as implementer-audit-feedback-correction.

Google provides evidence more through GitHub and CI workflows. The official run-gemini-cli action names pull request reviews, issue triage, code analysis, and code changes as use cases. The PR review example runs automatically for new pull requests or manually through @gemini-cli /review, gathers PR data and changed files, runs the Gemini analysis, and posts review comments back to the PR. The example prompt limits comments to changed diff lines, requires verifiable findings, severity classification, and concrete suggestions. In the Gemini CLI repository itself, the process documentation separates issue and PR: the issue describes what and why, the PR describes how the implementation works. CI checks linting, tests across several platforms, and coverage; PR automation checks the connection between issue and PR. Checkpointing adds to the correction path because Gemini CLI can create snapshots before AI file changes and restore files together with conversation state.

For the second lane, this yields a process that none of the providers describes as a ready-made rule. The agent that writes new code has first delivered only a local proof. It has shown that its new lane works. The missing evidence is often elsewhere: does the existing product path use this lane? Are all surfaces wired? Does a consumer use the new signal in the live path? Does the test cover the claim or only the newly built helper? These questions have to appear before implementation and in the audit. Before implementation, the Second-Lane-Grep forces evidence of existing code, config, test, or runtime paths. After implementation, the auditor checks the diff against plan, scope, and existing call sites. The finding goes back to the implementer, the correction lands in a new commit, and only another gate turns that state into something fit for release.

My gate template tightens these provider pieces. It combines OpenAI’s plan, done, and review concepts, Anthropic’s fresh adversarial review context, and Google’s PR and CI automation into a workflow with plan/spec review before code, Second-Lane-Grep, Claim-Gate, independent verdict artifact, correction by the implementer, and re-review. The cross-model rule is not stated that way in any of the provider sources. I use it as an additional hardening step because a different model family often brings different search paths and error profiles.

A concrete review workflow

The workflow starts before implementation. For an epic, I create a plan/spec review gate. This gate produces no product code. It checks all implementation tickets against the epic README and against each other.

Only after that does the first agent implement. It wires in the existing backbone, justifies new abstractions, treats producer and consumer together, checks all affected surfaces, and carries tests and artifacts along. Self-acceptance does not count.

The planning gate writes its result into a machine-readable verdict artifact, for example in my projects as e2e-live/baseline/txxxx-plan-gate/VERDICT.json:

{
  "verdict": "fail",
  "planner_family": "gpt",
  "reviewer_family": "claude",
  "findings": [
    {
      "severity": "blocking",
      "artifact": "tickets/T1234.md",
      "finding": "Acceptance criterion AC-2 names no falsifying test."
    }
  ],
  "commitSHA": "..."
}

In the final audit, an independent model reads ticket, diff, tests, README, schema, and artifacts itself. It reruns the central gates, greps for dead and duplicate paths, and compares the existing product path with the new one. The verdict uses the same basic shape and records the fields implementer_family and auditor_family.

On fail or inconclusive, the artifact contains blocking findings with file or artifact evidence. Before the merge, these findings are dispositioned: blocking, non-critical, or deferred. A public performance claim needs its own Claim-Gate.

The most effective single rule shifts the burden of proof. A solution that creates a second implementation next to an existing path without wiring that path in does not count as reviewable. The implementer has to show that a new path is necessary and fully wired; “the second path does no harm” is insufficient.

The operational cross-model rule in my gate: the auditor runs on a different model family than the implementer. The verdict artifact records implementer_family and auditor_family. If both are equal or one value is missing, the verdict is inconclusive. The planning gate uses planner_family and reviewer_family in the same way.

Checklist against the second lane

Per ticket or review artifact, a few checks are enough to find a second lane.

Limits of the process

The workflow has weaknesses that need to be understood.

The auditor can adopt the same assumptions as the implementer. If it reads the same ticket, the same summary, and the same logic, the errors correlate. Fresh context helps against that, as do a different model family, an explicitly adversarial prompt, and a ban on taking the development summary as the sole source.

Gates can be soft. A gate that checks only happy paths can even stabilize a second-lane error. The green status of the new path then hides that the actual product path stayed defective. That is why every claim needs a test that would have been red without the fix.

Artifacts drift as well. Tickets, README, schema, snapshots, and code diverge over time, and because agents use artifacts as steering sources, this drift leads directly to wrong decisions. My own evaluation lists documentation, schema, and evidence drift as a separate correction class at just under 17 percent.

Conclusion

The provider guidance from OpenAI, Anthropic, and Google supports the direction: planning before implementation, tests tied to claims, diff review, CI, and a route from findings into correction commits. The concrete design comes from my gate process. The corrections from my own branch are a small sample, but every class in them is a finding from the audit model, and the high intervention rate shows that a substantial share of implementations was not immediately correct without review. The process works when it is run as an evidence-based refutation process. A green test suite by itself does not prove that the product path calls the new code; the audit has to provide that evidence. Whether the pattern holds across more projects would require a larger study.

Sources

AI Agentic Coding Brownfield Code Review Quality Gates Software Engineering