Der Archäologe und sein Copilot: Malykhin diszipliniert das LLM auf Java 1.5

In einfachen Worten

Ein LLM, das auf Legacy-Code losgelassen wird, produziert Antworten, die klingen richtig, aber nicht zum Projekt passen. Die funktionierende Disziplin: den Assistenten zwingen, von Beweisen - Code, Tests, Artefakte - auszugehen, statt von seinem Gedächtnis.

Der Archäologe bei der Arbeit

Nik Malykhin berichtete am 16. Juli 2026 auf martinfowler.com von seiner Modernisierung einer Java 1.5-Basis in eine aktuelle Umgebung. Der Kontext ist nicht alltäglich: Moderne Analyse- und Refactoring-Tools mögen Java 1.5 nicht, und viele lehnen den Eintritt ab. Sein erster Reflex - den Assistenten direkt nach Korrekturen zu fragen - produzierte das, was Malykhin als "plausible" Antworten beschreibt, die "did not hold up in the codebase": Es sieht aus wie gutes Java 1.5, aber es entspricht nicht dem tatsächlichen Repository.

Die Wende ist methodischer Natur. Statt den LLM als Autor zu verwenden, nutzte Malykhin ihn als Analytiker und Prüfer, indem er jeden Schritt im Repository verankerte: sorgfältiges Lesen des bestehenden Codes, Validierung von Hypothesen anhand von Tests und Ausführungsverläufen, Verweigerung, schneller zu arbeiten, als der Code selbst es zulässt. Die Botschaft des Artikels ist einfach: Die Modernisierung von Legacy mit einem LLM geht nicht schneller als ein Archäologe, sie geht genauso langsam, aber mit weniger Lücken in der Demonstration.

Under the hood

Das Muster trägt mehrere Namen in der modernen Agentenausrüstung - evidence-first prompting, grounded reasoning, retrieval-first - aber es basiert auf derselben Regel: Jede Aussage des Assistenten muss auf einem Artefakt des Repositories (eine Datei, eine Zeile, ein Test) basieren. Das Fehlen dieser Einschränkung ist das, was die kostspieligsten "False Positives" eines LLM auf Legacy produziert: APIs, die später als die Zielversion sind, Methoden, die nicht existieren, Phantom-Imports.

So what

Für Teams, die mit Legacy arbeiten, dient der "Copilot" nicht zum Schreiben, sondern zum Finden. Die wahre Produktivität kommt daher, den LLM lesen zu lassen, nicht ihn raten zu lassen. Das Korollar für einen CTO: Die guten Metriken eines von KI unterstützten Modernisierungsprojekts sind nicht "generierte Zeilen", sondern "Hypothesen, die durch den Code selbst widerlegt werden". Der Unterschied zwischen den beiden ist der zwischen einem erfolgreichen Legacy-Projekt und einem Projekt, das wieder in Schulden zurückfällt.