Die Testsuite ist die Migration
Niemand hört gern, dass die erste Phase einer KI-gestützten Modernisierung darin besteht, Tests von Hand zu schreiben. Es ist zugleich die einzige Fassung des Projekts, die wir funktionieren gesehen haben — und der Grund hat mit Modellen nichts zu tun.
Was tatsächlich gefragt wurde
Ein fünfzehn Jahre alter Dienst, eine Sprachversion außerhalb des Supports und der Vorschlag, einen Assistenten übersetzen zu lassen. Der Code ist nicht riesig, und die Übersetzung selbst liegt gut im Bereich dessen, was heutige Modelle verlässlich leisten.
Die Frage, die niemand gestellt hatte, lautet, woran man erkennen würde, ob das übersetzte System sich gleich verhält. Eine nennenswerte Testsuite gab es nicht, und das Verhalten des alten Systems war durch das alte System definiert — eine Zirkeldefinition, bis jemand es aufschreibt.
Warum die Tests zuerst kommen
Weil eine Migration ohne sie keine Migration ist, sondern eine Neuschreibung mit angehängter Hoffnung. Jeder Unterschied, den die Übersetzung einführt, ist unsichtbar, bis er einen Nutzer erreicht — und die Unterschiede, die Modelle einführen, sind klein und inhaltlich statt groß und offensichtlich: eine Ganzzahldivision, eine Konvention zur Behandlung leerer Werte, eine Sortierung, die zufällig war.
Liu und Kollegen veröffentlichten 2025 MigrationBench, einen Benchmark für Code-Migration auf Repository-Ebene — und Repository-Ebene ist das entscheidende Wort. Eine Datei zu übersetzen ist ein anderes Problem, als ein System zu migrieren, und das zweite wird davon beherrscht, ob das Verhalten im Ganzen erhalten bleibt.
Was wir zuerst testen
Nicht den Code. Die Grenzen: was an jeder äußeren Schnittstelle hinein- und herausgeht, aus dem Produktionsverkehr aufgezeichnet, wo es geht, und von Hand geschrieben, wo nicht. Ein Charakterisierungstest, der festhält, was das System heute tut — einschließlich des Verhaltens, das niemand beabsichtigt hat.
Dieser letzte Teil ist wesentlich und unangenehm. Ein fünfzehn Jahre altes System hat Fehler, auf die sich nachgelagerte Systeme inzwischen stützen, und eine Migration, die sie still behebt, zerstört etwas. Wir halten das heutige Verhalten fest, markieren die verdächtigen Fälle und holen zu jedem eine Entscheidung ein, statt versehentlich etwas zu verbessern.
| Phase | Wer macht es |
|---|---|
| Charakterisierungstests an der Grenze | Wir und ihre Entwickler, von Hand |
| Übersetzung der Blattmodule | Assistent, geprüft |
| Übersetzung der Kernmodule | Assistent, sorgfältiger geprüft |
| Gewünschte Verhaltensänderungen | Eigenes Projekt, nach der Migration |
Blätter vor Stämmen
Wir migrieren zuerst Module mit wenigen Abhängigen, prüfen gegen die Tests und arbeiten uns nach innen. Das ist gewöhnliche Refactoring-Disziplin und wiegt mit einem Assistenten schwerer als ohne — denn eine falsche Übersetzung tief im Abhängigkeitsgraphen erzeugt Fehler weit entfernt von ihrer Ursache.
Es erzeugt außerdem einen stetigen Strom überprüfbaren Fortschritts, was kaufmännisch zählt. Eine Migration, die vier Monate ohne Vorzeigbares läuft, ist eine Migration, die im dritten Monat gestoppt wird — unabhängig davon, wie gut sie läuft.
Was wir untersagt haben
Dass der Assistent beim Übersetzen irgendetwas verbessert. Nicht die Benennung, nicht die Struktur, nicht eine offensichtlich alberne Schleife. Jede Verbesserung ist ein Verhaltensrisiko in einer Phase, deren ganzer Zweck darin besteht, dass sich das Verhalten nicht ändert — und Verbesserungen sind genau das, was ein Modell ungefragt anbietet.
Die Anweisung ist ausdrücklich, und die Prüfung achtet darauf. Zwei der ersten zwanzig Pull Requests enthielten eine ungefragte Aufräumaktion, beide harmlos, beide aus Prinzip abgelehnt — danach hörte das Muster auf.
Was die sechs Wochen eingebracht haben
Zweihundertvierzig Charakterisierungstests, von denen elf ein Verhalten dokumentierten, das der Kunde als Fehler ansah. Die Migration selbst dauerte danach rund sieben Wochen, wobei ein Assistent den größten Teil der Übersetzung übernahm, und die Tests fingen neunzehn Verhaltensunterschiede — vier davon hätten wir durch Lesen nicht gefunden.
Das Verhältnis ist der Punkt. Sechs Wochen unspektakuläres Testschreiben machten eine siebenwöchige Migration möglich und überprüfbar; ohne sie hätten dieselben sieben Wochen etwas erzeugt, das niemand hätte abnehmen können.
Wo das nicht gilt
Bei Systemen mit bereits guter Testsuite, wo die erste Phase kurz ist und das Ganze deutlich günstiger. Und bei Systemen, deren Verhalten wirklich nicht erhaltenswert ist — dort ist das ehrliche Projekt eine Neuschreibung mit neuen Anforderungen und keine Migration, und der Assistent hilft bei etwas ganz anderem.
Diese beiden zu unterscheiden ist der größte Wert des ersten Gesprächs. Wer sagt migriere das, meint meist eines von beidem und hat sich nicht entschieden, welches — und die Antwort ändert sowohl die Kosten als auch, wer beteiligt sein muss.
Was wir nicht behaupten
Wir behaupten nicht, der Assistent habe den schweren Teil erledigt. Er hat die Menge erledigt, schnell und überwiegend richtig, und der schwere Teil war zu entscheiden, was richtig heißt, und etwas zu bauen, das es prüfen kann. Diese Arbeit lässt sich nicht durch das automatisieren, was automatisiert wird.
Wir behaupten auch nicht, neunzehn Unterschiede seien eine gute oder schlechte Quote. Es ist ein Projekt, ein Sprachpaar, eine Codebasis — die einzige Aussage, die wir daraus ableiten, ist, dass die Zahl nicht null war und wir es nicht gewusst hätten.