Große Portierungen gelten in der Softwareentwicklung als unangenehmste Kategorie von Projekten: viel Aufwand, wenig sichtbarer Nutzen, hohes Risiko. Genau deshalb bleiben gewachsene Codebasen oft jahrelang auf einer Technologie stehen, die niemand mehr freiwillig wählen würde. Ein Bericht über ein Migrationsprojekt bei GitHub zeigt, dass sich diese Rechnung gerade verschiebt: Rund 800.000 Codezeilen wurden dort von TypeScript und Node.js nach Rust überführt – mit KI-Unterstützung, die das Vorhaben überhaupt erst wirtschaftlich vertretbar gemacht hat. Die menschliche Kontrolle blieb dabei unverzichtbar.

Warum Portierungen normalerweise liegen bleiben

Eine Sprachmigration erzeugt im Idealfall kein einziges neues Feature. Das Produkt verhält sich hinterher genauso wie vorher, nur eben auf einer anderen technischen Grundlage. Der Nutzen liegt in Eigenschaften, die sich schlecht in Roadmap-Punkte übersetzen lassen: Laufzeitverhalten, Speicherbedarf, Wartbarkeit, Verfügbarkeit von Entwicklerinnen und Entwicklern für die jeweilige Sprache.

Dem steht ein Aufwand gegenüber, der linear mit der Codemenge wächst. Bei sechsstelligen Zeilenzahlen ist die manuelle Übersetzung in der Regel kein realistischer Vorschlag mehr, weil sie Teams über Monate bindet, die parallel das laufende Geschäft bedienen müssen. Das Ergebnis kennt man aus vielen Unternehmen: Die Migration steht seit Jahren auf der Liste und wird jedes Jahr verschoben.

Was sich durch KI-Unterstützung ändert

Sprachmodelle sind bei genau dieser Art von Arbeit vergleichsweise stark. Eine Portierung ist in weiten Teilen eine Übersetzungsaufgabe mit klarer Vorlage: Die Zielstruktur ist bekannt, die gewünschte Semantik steht im Ausgangscode, und es existieren typischerweise Tests, an denen sich das Ergebnis prüfen lässt. Anders als bei Neuentwicklungen muss das Modell nicht erraten, was gemeint ist – es muss Bestehendes übertragen.

Das verschiebt die Kostenseite deutlich. Wenn ein erheblicher Teil der mechanischen Übersetzungsarbeit automatisiert abläuft, verlagert sich der Personaleinsatz von der Erzeugung zur Prüfung. Ein Projekt, das vorher an der schieren Menge gescheitert wäre, wird dadurch planbar.

Die Prüfschicht bleibt

Der zentrale Punkt des GitHub-Berichts ist jedoch nicht die Automatisierung, sondern ihre Grenze: Ohne menschliche Kontrolle war das Ergebnis nicht tragfähig. Das deckt sich mit dem, was sich bei KI-gestützter Codearbeit generell beobachten lässt.

Generierter Code sieht plausibel aus. Er kompiliert häufig, er liest sich sauber, und er trifft den Stil der Zielsprache. Ob er in allen Randfällen das Gleiche tut wie das Original, ist damit nicht gesagt. Besonders heikel sind Stellen, an denen sich die Sprachen konzeptionell unterscheiden – etwa im Umgang mit Nebenläufigkeit, mit Fehlerbehandlung oder mit dem Lebenszyklus von Objekten. Genau dort entstehen Abweichungen, die keine Testsuite automatisch aufdeckt, wenn die Tests selbst aus der alten Welt stammen.

Praktisch bedeutet das: Die eingesparte Zeit landet nicht vollständig auf der Habenseite. Ein Teil davon wandert in Review, in zusätzliche Tests und in das gezielte Nachziehen von Stellen, an denen die Automatik an ihre Grenzen stößt.

Übertragbar auf mittelständische Codebasen

Die wenigsten Unternehmen stehen vor einer Portierung dieser Größenordnung. Die Struktur des Problems ist aber dieselbe, wenn eine ältere PHP-Anwendung auf eine aktuelle Version gehoben, eine TYPO3-Instanz über mehrere Hauptversionen migriert oder eine selbstgebaute Extension auf ein aktuelles API-Modell umgestellt werden soll.

Für solche Vorhaben lassen sich aus dem Vorgehen einige Punkte ableiten:

  • Testabdeckung zuerst. Automatisierte Übersetzung ist nur so verlässlich wie die Prüfung, die dahinter steht. Wo keine Tests existieren, sollten sie vor der Migration entstehen – gegen das alte System, solange es noch läuft.
  • In Schnitten arbeiten. Module mit klaren Grenzen lassen sich einzeln überführen und einzeln abnehmen. Das hält die Reviewlast pro Schritt beherrschbar.
  • Review als eigenes Arbeitspaket einplanen. Die Prüfung ist kein Anhängsel, sondern der Teil des Projekts, der die Qualität bestimmt. Sie gehört mit eigener Zeit und eigenen Zuständigkeiten in die Planung.
  • Kritische Bereiche identifizieren. Zahlungsabwicklung, Rechtevergabe, Datenexporte: Wo Fehler teuer werden, braucht es manuelle Tiefenprüfung statt Stichproben.

Was das für die Projektplanung heißt

Die interessante Konsequenz ist weniger technischer als wirtschaftlicher Natur. Migrationen, die bisher mit dem Argument „zu teuer, zu lange“ vertagt wurden, gehören neu bewertet. Eine Kalkulation aus dem Jahr 2022 bildet den heutigen Aufwand für solche Vorhaben nicht mehr zuverlässig ab.

Gleichzeitig ändert sich nichts an der Verantwortung für das Ergebnis. Ein Team, das eine Codebasis übernimmt, muss sie verstehen – unabhängig davon, wer oder was den ersten Entwurf geschrieben hat. Wer KI-gestützte Migration einkauft, kauft eine schnellere Erzeugung, keine Abkürzung bei der Qualitätssicherung.

Für Web- und Softwareprojekte verschiebt sich damit vor allem die Frage, die am Anfang steht: nicht mehr, ob eine Modernisierung überhaupt finanzierbar ist, sondern wie viel Prüfaufwand ein bestimmter Systembereich rechtfertigt. Wer eine gewachsene Plattform betreibt und einen Relaunch vor sich herschiebt, sollte die Machbarkeit neu durchrechnen – und im selben Zug Budget für Tests und Review festschreiben, bevor die eingesparte Entwicklungszeit anderweitig verplant ist.

Quellen