Die zweite Spur: warum Agenten im Bestandssystem Code doppeln

Coding-Agenten setzen im Bestandssystem oft eine zweite Implementierung neben den vorhandenen Pfad. Der Beitrag erklärt das Phänomen, belegt es mit einer eigenen Auswertung von Korrektur-Findings aus der Git-Historie eines Branches und beschreibt einen Prüfprozess mit Vorab-Gate, unabhängigem Auditor und maschinenlesbarem Verdict.

FC
Frank Csehan
28. Juni 2026 · 13 min Lesezeit

Wenn ein Coding-Agent ein Ticket abarbeitet, baut er sehr häufig eine zweite Implementierung neben den vorhandenen Pfad, ohne den bestehenden zu benutzen. Das Feature funktioniert, die Tests werden grün, und im Repository liegt eine unentdeckte Logik jetzt doppelt: einmal alt, einmal neu, beide leicht verschieden. In der Forschung heißt das Phänomen semantic duplication oder redundante Reimplementierung. Ich nenne es hier die zweite Spur: Der Agent legt eine neue Fahrspur an, obwohl daneben schon eine validierte existiert.

Warum der Agent doppelt

Die Ursache ist ein Grounding-Problem, also eine Lücke zwischen dem, was der Agent von der Codebasis sieht, und dem, was tatsächlich da ist. Ein Sprachmodell liest das Repository Datei für Datei in einem begrenzten Kontextfenster. Eine globale Karte der Struktur hat es nicht. Liegt der passende bestehende Pfad gerade außerhalb des geladenen Kontexts, leitet das Modell die Logik neu her, die es schon gibt. In einem großen, über Jahre gewachsenen System ist die Wahrscheinlichkeit dafür hoch, weil der relevante Code mit höherer Quote außerhalb des Fensters liegt als in einem kleinen, frischen Projekt.

Dazu kommt der Zuschnitt der Tickets. Ein knapper Auftrag wie „Implementiere X" führt leichter zu einem neuen Helfer als die Vorgabe, X in den bestehenden Pfad einzubinden und alle betroffenen Oberflächen zu belegen. Ein grün laufender Test beweist oft zu wenig. Er zeigt, dass der neue Pfad funktioniert. Ob der eigentliche Produktpfad ihn überhaupt aufruft, prüft er nicht.

Belegt ist das inzwischen mit Daten. Die Untersuchung „More Code, Less Reuse" (arXiv 2601.21276, 2026) hat KI-erzeugte und menschliche Pull Requests anhand objektiver Code-Metriken verglichen. KI-generierte Änderungen enthalten danach mehr duplikativen Code und greifen seltener auf bestehende Funktionen zurück. Im Bestandssystem ist das teuer, weil jede Kopie später separat gepflegt, getestet und verstanden werden muss.

Korrekturen aus einem Branch

Ich sehe das in allen Feature-Implementierungen in meiner recht großen (ca. 600K LoC) Codebasis. In meinen Projekten durchläuft jedes Feature standardmäßig einen festen Review-Prozess aus Implementierung, unabhängigem Audit und harten Gates; diese Auswertung ist ein Beispiel daraus. Über die Review-Artefakte eines Branches und die zugehörigen Fix-Commits ließen sich viele konkrete Korrektur-Findings aus der Git-Historie zählen, also Stellen, an denen ein erster Agentenlauf etwas falsch gemacht hatte und ein nachgelagerter Schritt es korrigieren musste. Die Quote ist hoch: Über gut fünfzig ausgewertete Commits brauchten je nach Zählweise zwischen 75 und 86 Prozent der geprüften Implementierungseinheiten eine Korrektur, einen neuen Zuschnitt oder ein erneutes Review. Die häufigsten Klassen verteilen sich so:

RangKorrekturklasseAnteil
1Tests/Gates deckten den Claim nicht hart ab27,8 %
2Ticket-/Scope-/Dependency-Vorgaben waren widersprüchlich oder nicht befolgt22,2 %
3Bestehender Produktpfad/Surface nicht vollständig verdrahtet16,7 %
4Runtime-/Datenvertragsbug: Merge, Default, Codable, Hash16,7 %
5Dokumentations-/Schema-/Evidenzdrift16,7 %

Die zweite Spur aus dem ersten Abschnitt steht hier auf Rang 3, „Bestehender Produktpfad/Surface nicht vollständig verdrahtet". In der Messung taucht sie als eigene Fehlerklasse mit knapp 17 Prozent auf. Mit „Claim" meine ich in der ersten Zeile ein behauptetes Ergebnis, etwa die Aussage eines Agenten, ein Akzeptanzkriterium sei erfüllt. Die Verteilung sagt mehr aus als die bloße Tatsache, dass korrigiert werden musste. Sie zeigt, welche Art von Fehler ein nachgelagerter Prüfer überhaupt fangen kann und welche schon vor der Implementierung entsteht. Ich gehe hier auf die zweite Spur gesondert ein, da diese in einem späteren Produktionssetting die teuerste und am schwersten zu korrigierende Baustelle ist. Fehler in der Produktion an solchen Stellen sind außerordentlich schwer zu finden und zu beheben. Diese Auswertung dokumentiert zusätzlich die notwendige systematische Etablierung eines Prüf- und Auditagenten als festen Bestandteil der Entwicklungspipeline.

Jede Klasse in der Tabelle ist ein Fund des Audit-Modells. Die Korrekturen stammen aus seinen Review-Artefakten und aus den Fix-Commits, die darauf folgten. Die Verteilung ist damit die Bilanz des Prüfers, eine Aufstellung dessen, was ein unabhängiges Modell gefangen hat, bevor es in einen späteren Stand des Systems gewandert wäre. Ohne diesen Prüflauf wären die Defekte zunächst durchgegangen, denn die Implementierung selbst hatte sie als erledigt gemeldet.

Bei der häufigsten Klasse, knapp 28 Prozent, fand der Prüfer unzureichende Tests. Die Implementierung hatte Tests geliefert, die nur den Happy Path grün hielten und keinen roten Gegenbeweis erzeugten. Eine Trigger-Matrix etwa deckte nicht die Auslöser ab, die sie zu prüfen vorgab, und ein als negativ angelegter Test stellte den Fehlerfall gar nicht erst her. Die Korrektur war jeweils, die Tests so zu bauen, dass sie fehlschlagen, wenn der Claim falsch ist. Diese Klasse übersieht ein Team, das seine eigene Arbeit abnimmt, weil ein grüner Lauf wie ein Beleg aussieht.

Die zweitgrößte Klasse, gut ein Fünftel, lag in der Spezifikation. Tickets waren mehrdeutig oder zyklisch geschnitten, eine Abhängigkeit war nicht als harte Vorbedingung markiert, ein Abschlussgate war zu eng gefasst, und der Scope zweier Tickets passte nicht zum tatsächlich freigegebenen Stand. Diese Widersprüche fand der Prüfer im Abgleich von Tickets, README und Abhängigkeiten.

Auf Rang 3 zeigte sich die zweite Spur als Oberfläche, die nicht vollständig am gemeinsamen Backbone hing. Ein zweiter Einstiegspunkt war vom gemeinsamen Resolver abgekoppelt, den ein erster bereits nutzte; alternative Bootstrap-Pfade verloren unterwegs Daten; an einer Stelle entstand eine zweite Auflösungs-Lane neben dem bestehenden Pfad, ohne ihn wiederzuverwenden. Die Korrektur war ein gemeinsamer Helfer und der Nachweis, dass alle Oberflächen denselben Backbone nutzen.

Die beiden übrigen Klassen betrafen Datenverträge und Drift. Bei den Datenverträgen ging es um einen fehlenden sicheren Default, um leere Deltas, die bestehende Werte überschrieben, und um eine Serialisierung, die nicht eindeutig war. Bei der Drift liefen Schema, App-Hilfe und Referenzstand gegen den tatsächlichen Code; das blockierte Freigaben, weil Agenten genau diese Artefakte als Vertragsquelle nutzen.

Über alle Klassen hinweg ist das Audit-Modell die Stelle, an der ein Problem sichtbar wird, das ein selbst abnehmendes Dev-Team ungeprüft weitergereicht hätte. Die Messung rechtfertigt den zweiten Prüfer damit über die gesamte Verteilung hinweg.

Implementierer und Auditor als Widerlegungsprozess

Gegen die zweite Spur und gegen die übrigen Fehlerklassen hilft eine Arbeitsteilung, die ich in meinen Projekten als Gate-Prozess führe. Ein Agent implementiert entlang Ticket, Repo-Regeln und bestehender Pfade. Ein zweiter Agent mit frischem Kontext versucht, den Claim zu widerlegen. Über das Ergebnis entscheiden harte Gates, Re-Runs, Greps und Artefakte. Die Selbstzusammenfassung des Implementierers zählt dabei nicht als Beleg. Ein fail oder ein inconclusive hält den Merge an.

Der Punkt ist die adversariale Haltung. Ein zweites Modell, das nur dieselbe weiche Zusammenfassung liest und sie abnickt, bringt wenig. Es zahlt sich erst aus, wenn es Codepfade grept, Call-Sites verfolgt, Tests erneut laufen lässt, Baselines vergleicht und gezielt nach rotem Gegenbeweis sucht.

Ein Modellmix, etwa Claude oder Opus als Implementierer und ein Codex- oder GPT-Modell als Auditor, hilft zusätzlich. Verschiedene Familien haben verschiedene Stärken, Suchmuster und Fehlerprofile, und ein Modell, das seinen eigenen Output abnimmt, urteilt zu milde. Der eigentliche Sicherheitsgewinn liegt aber woanders. Er entsteht aus der Trennung von Rolle und Kontext, aus dem Widerlegungsauftrag, aus harten Gates und reproduzierbaren Re-Runs und daraus, dass fail und inconclusive den Merge tatsächlich aufhalten.

Die großen Anbieter gehen ähnliche Wege. Die relevante Linie entsteht aus mehreren Bausteinen: Codebasis erkunden, bevor Code entsteht; einen Plan und klare Done-Kriterien festlegen; die Änderung durch Tests und Review belegen; den Diff mit frischem Kontext prüfen; Findings an den Implementierer zurückgeben und nach der Korrektur erneut prüfen.

OpenAI beschreibt für Codex bei schwierigen Aufgaben zuerst eine Planphase. Codex soll Kontext sammeln, offene Fragen klären und einen Plan bauen, bevor die Implementierung beginnt. Für große Repositories nennt OpenAI im Auftrag vier Felder: Ziel, Kontext, Constraints und ein klares „Done when". Der letzte Punkt ist für Brownfield-Arbeit zentral, weil „fertig" an beobachtbare Zustände gebunden wird, etwa bestandene Tests, verändertes Verhalten oder einen reproduzierten Fehler, der danach ausbleibt. Zur Review-Schleife gehören nach der Dokumentation Tests, relevante Checks, Bestätigung des Ergebnisses und eine Diff-Prüfung auf Bugs, Regressionen und riskante Muster. Die Review-Fläche kann uncommitted changes, Branch-Diffs und einzelne Commits prüfen; Inline-Kommentare am Diff werden wieder Arbeitskontext für Codex. Subagenten nutzt OpenAI für abgegrenzte Prüfungen: Exploration, Tests, Triage oder Review-Perspektiven wie Sicherheit, Testlücken und Wartbarkeit. Auf die zweite Spur übertragen heißt das: Der Auditor liest Diff, Tests und Auftrag. Er übernimmt die Erfolgserzählung des Implementierers nur als zu prüfende Behauptung.

Anthropic ist bei diesem Muster am explizitesten. In den Claude-Code-Best-Practices steht eine adversariale Review-Stufe: Vor dem Abschluss soll ein Subagent den Diff in frischem Kontext prüfen und Lücken melden. Der Reviewer sieht den Diff und die Kriterien, aber keinen langen Herleitungsverlauf der Implementierung. Für Korrektheitsprüfungen verweist Anthropic auf /code-review, das den aktuellen Diff in einem frischen Subagenten auf Bugs prüft und Findings in die laufende Session zurückspielt. Wer gegen einen Plan prüfen will, soll Plan, Diff und Finding-Kriterien ausdrücklich nennen, etwa erfüllte Anforderungen, getestete Edge Cases und Einhaltung des Scope. Danach kann die Implementierungssitzung die Findings korrigieren und den Review erneut auslösen. Damit entsteht der Zyklus, den ich hier als Implementer-Audit-Feedback-Korrektur beschreibe.

Google liefert den Beleg stärker über GitHub- und CI-Abläufe. Die offizielle run-gemini-cli Action nennt Pull-Request-Reviews, Issue-Triage, Codeanalyse und Codeänderungen als Einsatzfälle. Das PR-Review-Beispiel läuft automatisch bei neuen Pull Requests oder manuell über @gemini-cli /review, sammelt PR-Daten und Changed Files, führt die Gemini-Analyse aus und postet Review-Kommentare zurück in den PR. Der Beispielprompt begrenzt Kommentare auf geänderte Diff-Zeilen, verlangt verifizierbare Findings, Severity-Einstufung und konkrete Vorschläge. Im Gemini-CLI-Repository selbst trennt die Prozessdokumentation Issue und PR: Das Issue beschreibt Was und Warum, der PR das Wie der Umsetzung. CI prüft Lint, Tests über mehrere Plattformen und Coverage; eine PR-Automation kontrolliert die Verknüpfung zwischen Issue und PR. Checkpointing ergänzt den Korrekturpfad, weil Gemini CLI vor AI-Dateiänderungen Snapshots anlegen und Dateien samt Gesprächszustand wiederherstellen kann.

Für die zweite Spur ergibt sich daraus ein Prozess, den keiner der Anbieter als fertige Regel beschreibt. Der Agent, der neuen Code schreibt, hat zunächst nur einen lokalen Beweis geliefert. Er hat gezeigt, dass seine neue Spur funktioniert. Der fehlende Beleg liegt oft an anderer Stelle: Nutzt der bestehende Produktpfad diese Spur? Sind alle Oberflächen verdrahtet? Hat ein Consumer das neue Signal im Live-Pfad? Deckt der Test den Claim oder nur den neu gebauten Helfer? Diese Fragen müssen vor der Implementierung und im Audit auftauchen. Vor der Implementierung erzwingt der Second-Lane-Grep den Nachweis bestehender Code-, Config-, Test- oder Runtime-Pfade. Nach der Implementierung prüft der Auditor den Diff gegen Plan, Scope und bestehende Call-Sites. Das Finding geht zurück an den Implementierer, die Korrektur landet in einem neuen Commit, und erst ein erneutes Gate macht daraus einen freigabefähigen Stand.

Meine Gate-Schablone verschärft diese Anbieterbausteine. Sie verbindet OpenAIs Plan-, Done- und Review-Begriffe, Anthropics frischen adversarialen Review-Kontext und Googles PR-/CI-Automation zu einem Ablauf mit Plan-/Spec-Review vor dem Code, Second-Lane-Grep, Claim-Gate, unabhängigem Verdict-Artefakt, Korrektur durch den Implementierer und Re-Review. Die Cross-Model-Regel steht so in keiner der Anbieterquellen. Ich nutze sie als zusätzliche Härtung, weil eine andere Modellfamilie oft andere Suchpfade und Fehlerprofile mitbringt.

Ein konkreter Prüfablauf

Der Ablauf beginnt vor der Implementierung. Für ein Epic lege ich ein Plan-/Spec-Review-Gate an. Dieses Gate erzeugt keinen Produktcode. Es prüft alle Implementierungstickets gegen die Epic-README und gegeneinander.

Erst danach implementiert der erste Agent. Er bindet den bestehenden Backbone ein, begründet neue Abstraktionen, betrachtet Producer und Consumer zusammen, prüft alle betroffenen Oberflächen und zieht Tests wie Artefakte mit. Eine Selbstabnahme gilt nicht.

Das Vorab-Gate schreibt sein Ergebnis in ein maschinenlesbares Verdict-Artefakt, in meinen Projekten zum Beispiel als e2e-live/baseline/txxxx-plan-gate/VERDICT.json:

{
  "verdict": "fail",
  "planner_family": "gpt",
  "reviewer_family": "claude",
  "findings": [
    {
      "severity": "blocking",
      "artifact": "tickets/T1234.md",
      "finding": "Akzeptanzkriterium AC-2 nennt keinen falsifizierenden Test."
    }
  ],
  "commitSHA": "..."
}

Im Abschluss-Audit liest ein unabhängiges Modell Ticket, Diff, Tests, README, Schema und Artefakte selbst. Es lässt die zentralen Gates erneut laufen, grept nach toten und doppelten Pfaden und vergleicht den bestehenden Produktpfad mit dem neuen. Das Verdict nutzt dieselbe Grundform und hält die Felder implementer_family und auditor_family fest.

Bei fail oder inconclusive enthält das Artefakt blockierende Findings mit Datei- oder Artefaktbelegen. Vor dem Merge werden diese Findings disponiert: blockierend, unkritisch oder zurückgestellt. Ein öffentlicher Leistungs-Claim braucht ein eigenes Claim-Gate.

Die wirksamste einzelne Regel verschiebt die Beweislast. Eine Lösung, die eine zweite Implementierung neben einem vorhandenen Pfad erzeugt, ohne ihn einzubinden, gilt nicht als prüffähig. Der Implementierer muss belegen, dass ein neuer Pfad nötig und vollständig verdrahtet ist; ein „der zweite Pfad schadet ja nicht" reicht nicht.

Die operative Cross-Model-Regel in meinem Gate: Der Auditor läuft auf einer anderen Modellfamilie als der Implementierer. Das Verdict-Artefakt hält implementer_family und auditor_family fest. Sind beide gleich oder fehlt ein Wert, lautet das Verdict inconclusive. Für das Vorab-Gate gelten entsprechend planner_family und reviewer_family.

Checkliste gegen die zweite Spur

Pro Ticket oder Review-Artefakt reichen wenige Prüfungen, um eine zweite Spur aufzuspüren.

Grenzen des Prozesses

Der Ablauf hat eigene Schwachstellen, die man kennen muss.

Der Auditor kann dieselben Annahmen übernehmen wie der Implementierer. Liest er dasselbe Ticket, dieselbe Zusammenfassung und dieselbe Logik, korrelieren die Fehler. Dagegen helfen frischer Kontext, eine andere Modellfamilie, ein ausdrücklich adversarialer Prompt und das Verbot, die Dev-Zusammenfassung als alleinige Quelle zu nehmen.

Gates können weich sein. Ein Gate, das nur Happy Paths prüft, kann einen Second-Lane-Fehler sogar stabilisieren. Der grüne Status des neuen Pfades verdeckt dann, dass der eigentliche Produktpfad defekt geblieben ist. Deshalb braucht jeder Claim einen Test, der ohne den Fix rot wäre.

Artefakte driften ebenfalls. Tickets, README, Schema, Snapshots und Code laufen mit der Zeit auseinander, und weil Agenten Artefakte als Steuerungsquelle nutzen, führt diese Drift direkt zu falschen Entscheidungen. Die eigene Auswertung führt Dokumentations-, Schema- und Evidenzdrift als eigene Korrekturklasse mit knapp 17 Prozent.

Fazit

Die Anbieterhinweise von OpenAI, Anthropic und Google stützen die Richtung: Plan vor der Implementierung, Tests mit Claim-Bezug, Review am Diff, CI und ein Rückweg aus Findings in Korrektur-Commits. Die konkrete Ausgestaltung stammt aus meinem Gate-Prozess. Die Korrekturen aus dem eigenen Branch sind eine kleine Stichprobe, aber jede Klasse darin ist ein Fund des Audit-Modells, und die hohe Interventionsrate zeigt, dass ein erheblicher Teil der Implementierungen ohne Review nicht sofort korrekt war. Der Prozess wirkt, wenn er als evidenzbasierter Widerlegungsprozess geführt wird. Eine grüne Testsuite belegt für sich noch nicht, dass der Produktpfad den neuen Code aufruft; diesen Nachweis muss der Audit erbringen. Ob sich das Muster über mehr Projekte hält, müsste eine größere Erhebung zeigen.

Quellen

KI Agentic Coding Brownfield Code Review Quality Gates Software Engineering