Lesen der gesamten Codebasis jenseits des Kontextfensters

Ein Modell, das eine Million Zeilen annimmt, kann deshalb noch lange kein System mit einer Million Zeilen verstehen. Die Kapazität beantwortet nur, ob der Text hineinpasst. Sie sagt nichts darüber aus, ob das Modell die richtige Definition findet, einen indirekten Aufrufer mit einem Nebeneffekt verbindet oder erkennt, dass ein JCL-Schritt die Bedeutung des gestarteten COBOL-Programms verändert.

Bei der Umschreibung von Legacy-Systemen ist dieser Unterschied besonders wichtig. Eine örtlich plausible Übersetzung kann kompilieren und trotzdem den Monatsabschluss beschädigen, weil das alte Verhalten über Quelldateien, Copybooks, Datenbank-Trigger, Jobsteuerung, Bildschirmvalidierung und Produktionskonventionen verteilt ist. All das in einen Prompt zu stecken, ersetzt ein Auslassungsproblem durch ein Unterscheidungsproblem. Der Kontext enthält die Antwort, doch dem Modell fehlt eine verlässliche Struktur, um die Tatsachen zu bestimmen, die eine Änderung steuern.

Das Lesen der gesamten Codebasis ist deshalb ein Systemproblem und keine Funktion der Prompt-Größe. Es braucht ein dauerhaftes Modell des Repositorys, explizite Wege durch Abhängigkeiten, gestuftes Schlussfolgern und ausführbare Belege dafür, dass das erzeugte System sich wie das alte verhält.

Ein Kontextfenster misst Kapazität, nicht Verständnis

Ein langes Kontextfenster nennt die maximale Eingabe, die ein Modell unter bestimmten Bedingungen annehmen kann. Es verspricht weder gleichmäßiges Erinnern noch stabiles Schlussfolgern im gesamten Fenster oder korrekte Verknüpfungen zwischen weit entfernten Fakten. Das sind getrennte Fähigkeiten. Sie als eine Kennzahl zu behandeln, ist der erste Konstruktionsfehler.

Nelson Liu und seine Mitautoren machten das Positionsproblem in der Arbeit Lost in the Middle konkret. Bei Fragen über mehrere Dokumente und beim Abruf von Schlüssel-Wert-Paaren war die Leistung oft am höchsten, wenn relevantes Material am Anfang oder Ende der Eingabe stand. Sie sank, wenn dasselbe Material in die Mitte wanderte. Die Arbeit beweist nicht, dass jedes heutige Modell bei jedem langen Programm versagt. Sie beweist aber, dass eine erfolgreiche Aufnahme kein guter Ersatzmaßstab für verlässliche Nutzung ist.

Code macht die Sache schwieriger als gewöhnliche Prosa. Ein Repository enthält Tausende wiederkehrende Formen: Getter, Validatoren, Datensatzlayouts, Fehlerzweige, generierte Dateien und fast identische Batch-Schritte. Das Modell muss ähnlich aussehende Fakten unterscheiden und zugleich Beziehungen verfolgen, die im Text nie nebeneinander stehen. Ein Absatz CALCULATE-TAX und ein Absatz CALCULATE-TAX-OLD können fast alle Tokens teilen und verschiedene Aufrufer haben. Ähnlichkeit hilft, beide zu finden. Sie entscheidet nicht, welcher die Transaktion steuert.

Token-Zahlen verbergen auch die Kosten der Darstellung. Quelltext ist nur eine Ebene. Eine brauchbare Analyse braucht Symbolidentitäten, Aufrufkanten, Datenfluss, Build-Metadaten, Schemas, Konfiguration, Tests und Beobachtungen aus laufender Software. Wenn ein Anbieter sagt, sein Kontextfenster fasse das Repository, fragen Sie, was ausgeschlossen wurde, in welcher Reihenfolge die Dateien stehen, wie sprachübergreifende Kanten codiert wurden und wie das System Behauptungen aus dieser Eingabe prüft. Die Fenstergröße beantwortet keine dieser Fragen.

Der praktische Abnahmetest ist einfach: Verschieben Sie die entscheidende Datei an eine andere Position, fügen Sie irrelevante, aber ähnliche Dateien hinzu und wiederholen Sie die Aufgabe. Ändert sich die Antwort, hat das System eine Sequenz gelesen, keine Codebasis.

Ein weiterer Test prüft die Zusammensetzung. Fragen Sie, woher ein Feld stammt, wo es verändert wird und welcher externe Effekt von seinem Endwert abhängt. Stellen Sie die Fragen danach einzeln und vergleichen Sie den zusammengesetzten Pfad. Ein Leser, der jede lokale Frage beantwortet, aber die Identität entlang der Kette nicht bewahrt, kann suchen, aber kein System verstehen. Dieser Fehler fällt leicht durch, weil jede einzelne Antwort richtig klingen kann.

Retrieval übersieht Beziehungen ohne gemeinsamen Wortschatz

Der Abruf von Chunks funktioniert bei Fragen, deren Antwort der Suchanfrage ähnelt. Programmverhalten hängt jedoch oft von Beziehungen statt von gemeinsamen Wörtern ab. Der Aufrufer kann einen allgemeinen Namen verwenden, über eine Tabelle dispatchen, einen Prozedurnamen zusammensetzen, ein Ereignis veröffentlichen, eine Stored Procedure aufrufen oder die Kontrolle an einen Scheduler geben. Eine Vektorsuche nach dem Fachkonzept kann den Aufgerufenen finden und trotzdem den Aufrufer übersehen, der das entscheidende Flag liefert.

Nehmen wir eine Abrechnungsregel in COBOL. Der sichtbare Absatz liest eine Kontoklasse und berechnet eine Gebühr. Ein JCL-Schritt wählt am letzten Geschäftstag einen anderen Eingabedatensatz. Ein Copybook legt zwei Felder im Datensatz übereinander, und ein PL/SQL-Trigger unterdrückt die Gebühr für migrierte Konten. Keines dieser Artefakte muss die Formulierung aus dem Ticket wiederholen. Wer nur den Absatz abruft, erzeugt eine saubere, falsche TypeScript-Funktion.

SWE-bench hat eine verwandte Tatsache in kleinerem Maßstab erfasst: Reale Korrekturen verlangen oft abgestimmte Änderungen über Funktionen, Klassen und Dateien hinweg. Der ursprüngliche Aufbau verglich Retrieval mit dem Zugriff auf die Dateien, die der menschliche Patch geändert hatte. Darin steckt eine nützliche Warnung. Eine bessere Generierung kann Belege nicht zurückholen, die die Retrieval-Stufe nie geliefert hat, und bei einer laufenden Migration gibt es keine Orakel-Dateiliste.

Das Fachgebiet vermischt außerdem Such-Recall und Verhaltensvollständigkeit. Such-Recall fragt, ob ein bekannter relevanter Eintrag in der Ergebnismenge erscheint. Verhaltensvollständigkeit fragt, ob das System jedes Artefakt gefunden hat, das ein beobachtetes Ergebnis erklärt. Den ersten Wert kann man mit markierten Chunks messen. Den zweiten kann man nur durch Nachverfolgung und Tests belegen.

Ein Repository-Leser sollte mehrere Wege in einem gemeinsamen Belegspeicher zusammenführen:

• lexikalische Suche nach exakten Bezeichnern, Literalen, Datensatznamen und Fehlercodes;
• semantische Suche nach Konzepten mit anderem Wortschatz;
• Symbolauflösung und Aufrufverfolgung für explizite Programmstrukturen;
• Datenfluss- und Schema-Kanten für Werte über Prozedurgrenzen hinweg;
• Laufzeit-Traces für dynamischen Dispatch, Konfiguration und externe Effekte.

Das sind keine fünf konkurrierenden Retriever. Jeder deckt eine andere Fehlerklasse auf. Das System sollte festhalten, warum es ein Artefakt ausgewählt hat, welche Kante dorthin führte und was ungeklärt bleibt. Eine sortierte Tüte von Chunks ohne Herkunft verführt das Modell dazu, Retrieval-Konfidenz in erfundene Gewissheit zu verwandeln.

Chunk-Grenzen verursachen einen weiteren stillen Verlust. Eine Prozedurdeklaration kann in einem Chunk landen, während Vorbedingung, Fehlerbehandlung oder benachbarte Datendefinition in einem anderen liegen. Größere Chunks behalten mehr lokalen Kontext, senken aber die Präzision und belegen mehr Prompt-Platz. Überlappung kopiert Text, ohne Programmstruktur wiederherzustellen. Parser-gerechte Chunks verbessern den Kompromiss, doch selbst eine vollständige Funktion zeigt keine Scheduler-Bedingung und keinen Trigger-Effekt anderswo. Nach dem ersten Treffer muss Retrieval den Graphen erweitern. Es sollte anhand geklärter Fragen stoppen und nicht nach einem willkürlichen Top-k.

Verdünnte Aufmerksamkeit bleibt im größeren Prompt

Mehr relevantes Material kann eine Antwort verschlechtern, wenn das Modell unter zu vielen plausiblen Fakten auswählen muss. In der technischen Praxis bedeutet verdünnte Aufmerksamkeit, dass der entscheidende Beleg mit Boilerplate, doppelten Implementierungen, toten Zweigen, generiertem Code, Kommentaren zu einer alten Version und Tests mit veraltetem Verhalten konkurriert.

Eine verbreitete Empfehlung lautet, das ganze Repository in den Prompt zu legen und das Modell zu sorgfältiger Prüfung aufzufordern. Sie ist beliebt, weil dadurch eine sichtbare Pipeline-Komponente verschwindet. Es gibt keinen Index abzustimmen und keinen Retriever zu beschuldigen. Die Einfachheit ist nur äußerlich. Das Modell wählt weiterhin aus, tut dies nun aber in einem undurchsichtigen Inferenzlauf. Dort können Sie weder übersehene Kandidaten prüfen noch einen Weg wiederholen.

Die Repository-Reihenfolge wird damit unbeabsichtigt zur Richtlinie. Alphabetische Dateireihenfolge bevorzugt bestimmte Module. Eine Reihenfolge nach Abhängigkeiten verlangt schon vor dem Prompt einen Abhängigkeitsgraphen und bestätigt damit den Analysebedarf. Wahrscheinliche Dateien an beide Enden zu stellen, nutzt ein Benchmark-Muster aus, statt Verständnis nachzuweisen. Wichtige Dateien zu wiederholen, verschwendet Kapazität und kann veraltete Duplikate übergewichten.

LongBench v2 nahm Repository-Verständnis in Aufgaben mit sehr langen Eingaben auf und stellte fest, dass direkte Antworten schwierig blieben. Methodisch ist eine andere Lehre interessanter: Längeres Schlussfolgern und zusätzlicher Inferenzaufwand können so wichtig sein wie die angegebene Eingabegröße. Eine Migrationsarchitektur sollte Zwischenarbeit deshalb aus dem Modell herausziehen. Eine einzige Generierung sollte nicht zugleich das System entdecken, das Zieldesign bestimmen, Code erzeugen und Parität bescheinigen.

Sie können die Verdünnung mit einer kleinen Auswertung sichtbar machen. Wählen Sie eine Änderung, deren steuernde Fakten einen Aufrufer, einen Konfigurationswert und einen Nebeneffekt umfassen. Führen Sie sie mit der kleinsten Belegmenge aus und ergänzen Sie dann zehn Gruppen plausibler Ablenkungen aus demselben Repository. Erfassen Sie für jeden Lauf den behaupteten Aufrufpfad, angeführte Symbole, Patch und Testergebnis. Es geht nicht um eine allgemeingültige Punktzahl. Sie wollen herausfinden, ob zusätzlicher Kontext die Beschreibung des Verhaltens verändert, obwohl das Programm unverändert blieb.

Prompt-Zusammenfassungen heilen das Problem nicht von selbst. Zusammenfassung ist eine verlustbehaftete Relevanzentscheidung, bevor die spätere Aufgabe bekannt ist. Eine Zusammenfassung für die Architekturentdeckung kann Rundungsregeln auslassen, die bei einer Fehlerkorrektur gebraucht werden. Nutzen Sie Zusammenfassungen als Wegweiser, heften Sie sie an die beschriebenen Quellentitäten und lassen Sie die Aufgabe die Originalbelege wieder öffnen. Eine Zusammenfassung darf nie der einzige verbliebene Bericht über ein Modul sein.

Vor der Generierung braucht das Repository eine typisierte Karte

Die Analyse der gesamten Codebasis beginnt mit einer typisierten, abfragbaren Darstellung des Systems. Ein flacher Vektorindex ist darin nützlich, kann aber nicht diese Darstellung sein. Die dauerhafte Einheit ist eine Entität mit Identität, Ort, Sprache und Kanten zu anderen Entitäten.

Mindestens sollte die Karte Dateien, Symbole, Einstiegspunkte, Aufrufe, Lese- und Schreibzugriffe, Schemas, Jobs, Bildschirme, Tests, Konfigurationsschlüssel und externe Schnittstellen enthalten. Kanten brauchen Typen, weil calls, loads dynamically, writes field und runs after verschiedenes Schlussfolgern verlangen. Konfidenz und Herkunft gehören an jede Kante. Eine vom Compiler abgeleitete Aufrufkante darf nicht genauso aussehen wie eine vom Modell vermutete Verbindung.

In Legacy-Repositorys gehören Sprachgrenzen zur Semantik. JCL wählt Programme und Datensätze. CICS-Maps verbinden Bildschirme mit Feldern. RPG-Programme hängen von Display Files ab. VB6-Formulare enthalten Event-Verdrahtung außerhalb normaler Prozeduren. Classic ASP mischt Markup, Skript, Sitzungszustand und Datenbankzugriff. PL/SQL-Pakete können Effekte hinter Triggern und Synonymen verbergen. Ein Parser für die Hauptsprache sieht nur einen Teil des ausführbaren Systems.

Die Karte braucht auch negative und ungeklärte Fakten. Wenn sich das Ziel eines dynamischen Aufrufs statisch nicht bestimmen lässt, speichern Sie den Ausdruck und die Kandidatenmenge, statt still einen auszuwählen. Definieren zwei Copybooks denselben Datensatznamen unter verschiedenen Build-Optionen, behalten Sie beide Varianten und die Auswahlbedingung. Unbekanntes sollte Trace-Anfragen oder Paritätsfälle erzeugen, keine geratenen Prosatexte.

Ein kompakter Belegdatensatz könnte so aussehen:

{
  "claim": "late fee is suppressed for migrated accounts",
  "path": ["BILLJOB", "FEE-CALC", "ACCT_FEE_TRIGGER"],
  "evidence": ["jobs/bill.jcl:88", "src/fee.cbl:412", "db/account.sql:219"],
  "conditions": ["RUN_MODE=MONTH_END", "account.migrated=true"],
  "unresolved": ["dynamic dataset alias at BILLIN"]
}

Dieser Datensatz ist kein Prompt-Trick. Er ist eine prüfbare Behauptung, die eine andere Stufe anfechten kann. Wenn die Generierung FEE-CALC ändert, kann das System betroffene Einstiegspunkte finden, die ungeklärte Datensatzbindung anfordern und Tests für die Bedingung auswählen. Ohne Karte muss jeder Prompt diese Fakten neu entdecken und wird sie jedes Mal anders entdecken.

Auch die Darstellung braucht Versionen. Generierter Code, Quell-Commits, Schema-Snapshots und aufgezeichnete Traces müssen dieselbe Revisionsgrenze teilen. Sonst kann der Graph einen Aufrufer vom Dienstag mit einem am Mittwoch ersetzten Aufgerufenen verbinden und ein System beschreiben, das nie existierte. Inkrementelle Analyse sollte abgeleitete Kanten ungültig machen, sobald sich ihre Quelle ändert, und abhängige Behauptungen neu berechnen. Cache-Wiederverwendung ohne Herkunft ist schnell, bis sie den falschen Build zertifiziert.

Das Lesen der gesamten Codebasis braucht Stufen

Ein verlässlicher Leser trennt Entdeckung, Verhaltensmodellierung, Zieldesign, Implementierung und Verifikation. Die Stufen dürfen iterieren, aber jede erzeugt Artefakte, die die nächste einschränken. So löscht eine flüssige Generierung keine Unsicherheit, die zuvor entdeckt wurde.

Die Entdeckung inventarisiert Sprachen, Build-Pfade, Einstiegspunkte, Schemas, Jobs und externe Grenzen. Sie parst alles Parsbare, zeichnet Fehler auf und verbindet sprachübergreifende Artefakte. Das Ergebnis ist eine Repository-Karte mit einer expliziten Liste blinder Stellen.

Die Verhaltensmodellierung beginnt bei beobachtbaren Operationen statt bei Dateien. Für jeden Einstiegspunkt verfolgt das System Bedingungen, Zustandsänderungen, Ausgaben und Nebeneffekte. Es gruppiert doppelte Wege für dieselbe Regel und trennt ähnliche Wege mit unterschiedlichen Vorbedingungen. Daraus entsteht eine Menge von Verhaltensbehauptungen, die an Belegen hängen.

Das Zieldesign entscheidet danach, wo dieses Verhalten in Go-Services, Rust-Kernels, TypeScript-Clients oder Postgres hingehört. Hier unterscheidet sich eine Umschreibung von einer Transliteration. Eine Absatz-für-Funktion-Konvertierung kann den Kontrollfluss bewahren und zugleich globalen Zustand, Dateikopplung und Scheduler-Annahmen mitschleppen. Das Design sollte Verhalten an der Grenze erhalten und die interne Struktur bewusst ändern.

Die Implementierung verarbeitet begrenzte Arbeitspakete aus der Karte. Ein Paket enthält Zielverhalten, relevante Quellentitäten, vorgelagerte Aufrufer, nachgelagerte Effekte, Einschränkungen, Unbekanntes und verlangte Paritätsfälle. Das Modell darf weitere Belege anfordern. Es darf eine fehlende Kante nie mit einer selbstsicheren Vermutung füllen.

Die Verifikation läuft fortlaufend und nicht erst nach einem heldenhaften letzten Merge. Fehler aktualisieren das Verhaltensmodell oder decken einen Defekt im Ziel auf. Diese Rückkopplung zählt, weil die Quellanalyse allein nicht entscheiden kann, ob ein seltsamer Zweig tot ist, eine regulatorische Ausnahme enthält oder nur durch Produktionsdaten erreicht wird.

Dieses Stufendesign setzt Modellaufmerksamkeit dort ein, wo sie eine definierte Aufgabe hat. Modelle können unordentlichen Code gut deuten und Implementierungen vorschlagen. Das umgebende System liefert Identität, Gedächtnis, Traversierung und einen Richter, der keine Prosa bewertet.

Auch die menschliche Prüfung sollte diesen Artefakten folgen. Ingenieure sollten strittiges Verhalten und Zielverträge prüfen, statt Tausende erzeugte Zeilen nach einer semantischen Änderung abzusuchen. Eine Stufe darf weitergehen, wenn ihre Behauptungen Belege haben, ihr Unbekanntes Verantwortliche hat und die nötigen Prüfungen existieren. Eine Freigabe polierter Prosa gehört nicht in dieses Tor.

Laufzeitbelege finden, was statisches Lesen verpasst

Statische Analyse beschreibt mögliches Verhalten. Aufgezeichnete Ausführung zeigt Verhalten, das mit bestimmten Eingaben tatsächlich auftrat. Eine ernsthafte Umschreibung braucht beides, denn jede Quelle deckt die blinden Stellen der anderen ab.

Statische Analyse kann Zweige aufzählen, die keine Aufzeichnung erreicht hat. Sie kann einen Schreibzugriff in einem Fehlerpfad finden, einen vierteljährlichen Batch-Job oder eine Bildschirmaktion, die im jüngsten Traffic fehlt. Laufzeit-Traces klären dynamische Aufrufe, echte Konfigurationswerte, Datensatz-Aliasse, zur Laufzeit erzeugtes SQL und die Reihenfolge externer Effekte. Keine Quelle ist allein die ganze Wahrheit.

Teams schlagen oft Testabdeckung als Ersatz vor. Bestehende Tests sind nützliche Belege, aber alte Systeme haben oft schmale Unit-Suites, umgebungsabhängige Integrationsskripte oder keine automatisierten Tests für jene Verhaltensweisen, die den Betrieb sichern. Bestehende Tests zu bestehen, beweist Kompatibilität mit den Tests und nicht mit dem Produktionssystem.

Ein Paritätsharness gibt dem Vergleich eine konkrete Form. Erfassen Sie eine Eingabe an einer stabilen Systemgrenze, spielen Sie sie gegen die alte und neue Implementierung ab, normalisieren Sie nichtdeterministische Werte und vergleichen Sie Ausgaben samt Nebeneffekten. Ein Ergebnis lässt sich ohne Interpretation darstellen:

case: invoice/month_end/migrated_account
old: status=200 body_sha256=7c... ledger_rows=0 notices=1
new: status=200 body_sha256=7c... ledger_rows=1 notices=1
verdict: FAIL side_effect.ledger_rows expected 0 got 1

Dieser Fehler verweist zurück auf die Behauptung zur Gebührenunterdrückung und ihren Belegpfad. Das Team kann prüfen, ob der neue Code das Trigger-Verhalten verpasst hat, ob das Replay-Setup das Konto nicht als migriert markierte oder ob Normalisierung einen Unterschied in der Quelle versteckte. Eine allgemeine Aussage wie „Ausgaben unterscheiden sich“ würde das Modell erneut durchs ganze Repository jagen.

Aufgezeichneter Traffic verlangt Sorgfalt. Geheimnisse und personenbezogene Daten brauchen eine zur Umgebung passende Behandlung, und destruktive Effekte müssen beim Replay isoliert oder virtualisiert werden. Auch die Abdeckung braucht ein Inventar: Welche Einstiegspunkte, Geschäftsperioden, Fehlerklassen und Konfigurationsvarianten enthält der Korpus? Eine Million wiederholte Erfolgsanfragen deckt den seltenen Abschlusslauf nicht ab.

Vergleichsregeln brauchen dieselbe Prüfung wie erfasste Eingaben. Zeitstempel, erzeugte IDs, ungeordnete Zeilen und umgebungsspezifische Pfade können Normalisierung brauchen, doch jede Regel blendet einen möglichen Unterschied aus. Speichern Sie jede Regel als Code, begründen Sie ihre Sicherheit und prüfen Sie, dass sie keine relevante Änderung verdeckt. Wenn ein anderer Batch die Reihenfolge alter Datensätze nutzt, würde Sortieren vor dem Vergleich Parität erfinden.

Paralleles Lesen braucht gemeinsamen Zustand

Ein Repository auf Agenten aufzuteilen, spart nur dann Zeit, wenn alle in ein gemeinsames, konsistentes Systemmodell schreiben. Zehn unabhängige Zusammenfassungen erzeugen zehn Vokabulare, doppelte Schlüsse und Lücken an Grenzen, von denen jeder Bearbeiter annahm, jemand anders werde sie prüfen.

Parallele Bearbeiter sollten explizite Graphbereiche oder Fragen übernehmen. Einer kann Job-zu-Programm-Kanten klären, während ein anderer Datenbankeffekte kartiert und ein dritter externe Endpunkte klassifiziert. Jeder schreibt Entitäten, typisierte Kanten, Belege und Konflikte in denselben Speicher. Entitätsidentitäten müssen stabil bleiben, damit CUSTOMER-REC in einem Copybook und der durch drei Programme gereichte Puffer unter derselben Build-Bedingung als dasselbe Layout erkannt werden.

Konflikte sind nützliche Ergebnisse. Wenn statisches Parsing sagt, ein Aufrufer erreiche eine Prozedur, aber Traces einen zweiten dynamischen Weg zeigen, sollte das System beide behalten und eine Klärung einplanen. Hängen zwei Agenten verschiedene fachliche Bedeutungen an dasselbe Feld, sieht ein Prüfer den Streit, bevor erzeugter Code eine Interpretation einbaut.

Nebenläufigkeit braucht auch abhängigkeitssensible Planung. Es bringt wenig, Ersatz für ein nachgelagertes Modul zu erzeugen, solange sein Eingabevertrag strittig bleibt. Unabhängige Komponenten dürfen vorankommen, aber Änderungen über ungeklärte Kanten sollten warten oder klar als vorläufige Schnittstellen markiert sein.

Die Aussage über eine Million Zeilen wird erst in diesem Modell glaubwürdig. CodeHero liest jede Sprache im Baum parallel und nutzt eine gemeinsame Darstellung des Gesamtsystems, statt jeden Prompt als isolierte Lesesitzung zu behandeln. Diese architektonische Tatsache zählt. Die Zahl gleichzeitiger Agenten sagt allein nichts über Verständnis aus.

Die Prüfansicht sollte zeigen, wie ein Schluss zustande kam: Quellorte, Graphpfad, Trace-Fälle, konkurrierende Deutungen und der nachgelagerte Code, der ihn verbraucht. Ein Fortschrittsbalken für Führungskräfte reicht dem Ingenieur nicht, der entscheiden muss, ob eine Zahlungsregel die Umschreibung überlebt hat.

Gemeinsamer Zustand bedeutet nicht einen riesigen Prompt für alle Bearbeiter. Gemeint ist ein transaktionaler Belegspeicher mit stabilen Bezeichnern und Versionsprüfungen. Bearbeiter können begrenzte Ausschnitte verarbeiten und Fakten nur dann zusammenführen, wenn die Quellrevision noch stimmt. So vermeidet man isolierte Agenten, die einander vergessen, und ein globales Gespräch, in dem niemand weiß, welche Behauptung noch aktuell ist.

Architekturqualität und Verhaltensparität sind getrennte Tore

Eine Umschreibung kann beobachtetes Verhalten treffen und trotzdem die alte Architektur schlecht reproduzieren. Sie kann auch modern aussehen und das System an seinen Grenzen verändern. Das sind getrennte Tore, und keines darf das andere ausgleichen.

Verhaltensparität bewertet Anfragen, Dateien, Nachrichten, Datenbankänderungen, relevante zeitliche Reihenfolge und Fehlerverhalten. Architekturprüfung bewertet Modulgrenzen, Zustandsverantwortung, Idiome der Zielsprache, Fehlerbehandlung, Beobachtbarkeit, Auslieferbarkeit und den Abbau alter Kopplung. Eine gewichtete Punktzahl aus beidem kann einen tödlichen Fehler verstecken. Jedes Tor muss für sich bestehen.

Auch diesen Unterschied verwischen Repository-Demos oft. Syntaktisch korrektes Go aus COBOL zu erzeugen, zeigt Übersetzung. Batch-gekoppelten Zustand durch explizite Services zu ersetzen und dabei das Abschlussverhalten zu erhalten, zeigt Modernisierung. Dafür braucht man Repository-Karte, Betriebsbedingungen und Paritätsbelege. Codegenerierung allein kann das nicht nachweisen.

Legen Sie Prüfkriterien vor der Implementierung fest. Für eine Servicegrenze erfassen Sie erlaubte Aufrufer, Anfrage- und Antwortverträge, Transaktionsverantwortung, Retry-Verhalten und Paritätsfälle. Für einen numerischen Rust-Kernel erfassen Sie Eingabebereiche, Rundung, Überlauf und Referenzvektoren. Für einen TypeScript-Client erfassen Sie, wem Validierung gehört und was der Server erzwingt. Das sind technische Entscheidungen und keine Details, die aus dem zufällig höchstplatzierten Quell-Chunk folgen dürfen.

Akzeptieren Sie „Das Modell hat das ganze Repository gesehen“ nicht als Beleg für eines der Tore. Verlangen Sie den Pfad vom Einstiegspunkt zum geänderten Verhalten, die ungeklärten Kanten darauf, die Zielentscheidung als Ersatz der alten Kopplung und die bestandenen Replay-Fälle. Kann das System diese vier Dinge nicht liefern, hat es Code ohne vertretbare Erklärung des Systems erzeugt.

Betriebliche Gleichwertigkeit kann mehr umfassen als Antworttexte. Batch-Stichtage, Sperrreihenfolge, Retry-Grenzen, Rundungsmodi, Dateicodierung und der Versandzeitpunkt von Nachrichten können vertraglich sein, wenn ein anderes System davon abhängt. Das Verhaltensinventar sollte markieren, was exakt übereinstimmen muss, was innerhalb einer Grenze abweichen darf und welche Abweichungen ein Verantwortlicher bewusst genehmigt hat. Jeden Unterschied als Fehler zu behandeln, blockiert Modernisierung. Jeden unbequemen Unterschied als Verbesserung zu bezeichnen, gibt Parität auf.

Prüfen Sie den Leser mit veränderten Belegen

Die beste Bewertung für einen Repository-Leser prüft Stabilität unter Änderungen, die die Antwort nicht beeinflussen sollten. Eine einzelne gelungene Demo sagt wenig aus, weil Dateireihenfolge, Anfrageformulierung und Chunk-Auswahl gerade diesen Fall begünstigt haben können.

Bauen Sie eine Menge von Repository-Fragen auf, deren Antworten mehrere Artefakte stützen. Nehmen Sie direkte Aufrufe, dynamischen Dispatch, durch Konfiguration gewählte Varianten, Datenbankeffekte, Batch-Reihenfolge, toten Code mit Ähnlichkeit zu aktivem Code und Sprachgrenzen auf. Erfassen Sie zu jeder Frage den erwarteten Belegpfad und nicht bloß eine Prosaantwort.

Verändern Sie danach die Eingabe kontrolliert:

1. Ordnen Sie Dateien und Ergebnisse der Graphtraversierung neu, ohne Inhalte zu ändern.
2. Fügen Sie fast identische tote Implementierungen und veraltete Kommentare hinzu.
3. Benennen Sie lokale Bezeichner um und bewahren Sie Struktur und Verhalten.
4. Entfernen Sie ein notwendiges Artefakt und prüfen Sie, ob das System Unsicherheit meldet.
5. Ergänzen Sie einen Laufzeit-Trace, der der statischen Hypothese widerspricht.

Bewerten Sie Beleg-Recall, Pfadkorrektheit, Umgang mit Unsicherheit, erzeugte Änderung und Paritätsergebnis getrennt. Ein Leser, der über den falschen Weg zur richtigen Antwort kommt, ist fragil. Ein System, das nach dem Entfernen eines Belegs keinen Schluss zieht, kann besser sein als eines, das seine ursprüngliche Antwort beibehält.

Kosten und Latenz gehören in die Bewertung, dürfen Genauigkeit aber nicht ersetzen. Erfassen Sie Parsing-Zeit, Indexaktualisierung, Graphtraversierung, Modellaufrufe, Replay-Zeit und menschliche Prüfzeit. Inkrementelle Änderungen sollten betroffene Entitäten und Tests aktualisieren, statt ein vollständiges Neulesen auszulösen. So wird das Lesen der gesamten Codebasis zu einer Betriebsarchitektur statt zu einer teuren Startdemo.

Die Abnahmefrage lautet nicht, ob ein Modellaufruf eine Million Zeilen fassen kann. Sie lautet, ob das System Verhalten erklären, irrelevanten Kontext aushalten, fehlende Belege offenlegen, ein bewusstes Zieldesign erzeugen und die neue Implementierung gegen die alte beweisen kann. Ein größeres Fenster kann an mehreren Stellen helfen. Es ersetzt nie die nötige Technik drumherum.