Technische Migration mit KI: Ein Versprechen und was es braucht, um es zu halten

Nach ersten positiven Erfahrungen mit einem kleinen Prototyp, einem Projekt mit 10.000 Lines of Code (LOC), wagten wir uns an „the real thing“: Die technische Migration eines internen Systems mit 100.000 LOC von Spring Boot zu Quarkus. Wir hatten eine ganze Reihe von Vorbedingungen, die unser erstes „richtiges“ Projekt erfüllen musste, die bloße Erlaubnis, KI einzusetzen, war nur eine davon. Zunächst wechselt bei dieser Umstellung nur das Framework, nicht die Programmiersprache. Das erschien uns deutlich einfacher, als es etwa der Umstieg von Java auf C# wäre. Außerdem hatte das Projekt bereits eine sehr gute Architektur mit zehn sauber getrennten Modulen anstelle des Big Balls of Mud, der manche Legacy-Projekte beschreibt. Auch die Code-Qualität war überzeugend.

Lernziel 1: Keine Big Bang Migration

Zu Beginn ließen wir unseren ersten KI-Agenten, wir nennen ihn Agent Alpha, verschiedene Pläne entwickeln, wie wir jedes einzelne der 10 Module migrieren können. Dabei gaben wir unterschiedliche Randbedingungen vor, beispielsweise, dass er Quarkus-native Bibliotheken verwenden soll oder das Spring Boot Compatibility Layer, das die bekannten Spring Boot APIs unterstützt. Letztere Bedingung erwies sich als Herausforderung, mehr dazu später.

Zunächst stellten wir fest, dass Agent Alpha dem Motto „nicht kleckern, sondern klotzen“ anhing und eine Big Bang Migration vorschlug. Wir mussten ihn erst dazu bringen, einen Migrationspfad zu entwickeln, in dem man möglichst parallel arbeiten kann. Denn wir hatten uns entschieden, gemäß dem Strangler-Pattern jedes Modul einzeln zu migrieren. Schließlich erhielten wir ein Schaubild für die Migration, mit dem wir arbeiten konnten. Dachten wir. Bis wir einen Blick auf das automatisierte Testen warfen.

Lernziel 2: Teste nicht, das Testen weg zu lassen

It takes two to test: Agent Alpha und Agent Beta

Mit Code und Tests ist es ein wenig wie mit Wasser und Seife – wenn das Ergebnis sauber sein soll, brauchst du beides. Unser KI-Agent Alpha sah das anders. Und als wir sahen, dass die bestehenden Tests alle in Spring Boot geschrieben waren, war klar, dass wir einen weiteren Agenten Beta brauchen, der neue, technologie-unabhängige Tests aufsetzt. Das ist nicht so simpel, wie es scheint. Es nützt nichts, die KI zu fragen, ob sie getestet habe, die Antwort ist im Zweifelsfall immer ein „ja“, trotzdem sind dann Tests rot oder es kompiliert einfach nichts. Auch ein Prompt mit der Anforderung, es dürfe nur grüne Tests geben, führt ins Leere. Denn unser Agent Beta fing daraufhin an, schrittweise Tests einfach zu löschen, weil Tests, die nicht mehr existieren, auch nicht rot sind. Das ist logisch, aber nur aus KI-Sicht.

Nach unserer Erfahrung muss man das automatisierte Testing relativ brutal in die KI hinein prompten und die KI an die Hand nehmen wie einen Juniorpartner. Sie braucht Blaupausen, also müssen wir Software Engineers alles, was man zum ersten Mal sieht, manuell reviewen.

Lernziel 3: Lass‘ deine KI-Agenten nicht hängen

Bei der Ausführung der Migration haben wir die KI erstmal einfach machen lassen. Wenn sie allerdings mehr als 30 min an einer Aufgabe festhing, war es an der Zeit, sich einzuschalten. Ein Beispiel war der unermüdliche Durchhaltewillen unseres Agenten, als er versuchte, zur Datenbank-Anbindung den Spring Boot Compatibility Layer zu verwenden. Hier wird eine an sich positive Eigenschaft, die häufig sehr hohe Code-Treue der KI, zum Nachteil. Denn in diesem Fall versuchte unser Agent, unseren Vorgaben folgend, die Spring Boot Queries unter Verwendung des Quarkus Spring-Compability-Layer zu migrieren. Nur kam er hier leider zu keiner Lösung, im Gegenteil: Viele Queries waren kaputt und wir mussten zurück auf Los. Eine erste Analyse brachte uns zur Vermutung, dass einzelne unserer Queries, die nicht dem Jakarta Standard genügen, in Kombination mit der Verwendung des Spring-Compability-Layer unseren Agenten verwirrt hatten. Bei dem Versuch, das Problem zu lösen, wurden schrittweise auch funktionierende Queries in Mitleidenschaft gezogen. Als nächstes gaben wir der KI die Empfehlung, stattdessen die quarkus-native Lösung Panache zu verwenden, was funktionierte.

Die kleinen KI-Agenten möchten aus dem Labyrinth abgeholt werden…

Zu kontrollieren, wann es Zeit ist für einen Stash und eine Kurskorrektur bei der KI; das ist auch eine ökonomische Frage. KI kann viele Stunden lang versuchen, ein Problem zu lösen, das sie nicht lösen kann. Das wird, Stichwort API-Kosten, schnell teuer.

Lernziel 4: Einfach Vergessen kannst du vergessen!

Ein weiterer Weg, der KI zu helfen, sobald sie festhing, bestand bei uns darin, sie drei Lösungsideen entwickeln zu lassen. Wenn keine davon funktionierte, sollte sie alle in ein Markdown File (ISSUES.md) ablegen. Sobald wir wieder für einen Review verfügbar waren, haben wir die KI angewiesen, mit uns über die offenen Issues zu chatten, damit sie erfährt, was unsere Vorschläge bzw. Anweisungen dazu waren. Auf diese Weise haben wir einen Feedbackzyklus etabliert. Funktionierende Lösungen dagegen kamen als Blaupause in die Claude.md, das projektspezifische Gedächtnis. So eine Konfigurationsdatei, die Claude automatisch bei jedem Start lädt, ist unerlässlich. KI selbst vergisst sonst den Kontext bereits, wenn man einen neuen Chat aufmacht.

Die Frage des Kontextspeichers ist auch Grund für das Vorgehen in kleinen, überschaubaren Tasks. KI kann immer nur eine bestimmte Anzahl an Tokens verarbeiten. Unabhängig davon, wie gigantisch diese Anzahl jeweils klingen mag, sie würde mit 100.000 LOC definitiv gesprengt. Code verbrennt sozusagen viele Tokens, sobald der Speicher überläuft, wird die KI „dumm“ und produziert Unfug.

Lernziel 5: Kontrolliere, mit wem und wo deine Agenten Umgang haben

It’s a small world – bei den KI-Agenten finden wir das gut

Gute Agenten sind isolierte Agenten, finden wir. Einfach, weil du grundsätzlich keine unschönen Spekulationen darüber anstellen möchtest, was für Dateien die KI vielleicht auf deinem Rechner ausführt, wenn sie sich gerade verselbstständigt. Deshalb raten wir dringend dazu, eine Virtual Machine zu verwenden oder Docker oder Dev-Container in Visual Studio Code oder IntelliJ. Stellt sicher, dass die Agenten in Umgebungen unterwegs sind, in denen ihr die Zugriffe reguliert und kontrolliert. Ein „YOLO“ (You Only Live Once) Modus mag zwar dahingehend verführerisch klingen, weil er repetitive Klicks spart, aber wir persönlich raten davon komplett ab.

Alle Lernziele erreicht. Und was bringt jetzt der KI-Einsatz?

Mit einem Wort: Geschwindigkeit, mindestens um den Faktor 2, weil KI quasi als zusätzliche/r Entwickler arbeitet, oft ist der Faktor auch wesentlich höher. Jedes Projekt besteht aus einzigartigen Aufgaben wie den Überlegungen zu Sicherheitsaspekten und der grundlegenden Analyse am Anfang. Überall da, wo Denkarbeit über das Problem selbst nötig ist, sind erfahrene Software Engineers – und nur sie – gefragt. Die KI wird dann sehr nützlich, wenn sie einmal Gelerntes skalieren soll. Im Wieder-Ausführen einer Aufgabe nach einer bekannten Blaupause ist sie unwahrscheinlich schnell. Außerdem kann sie in kürzester Zeit kleine Prototypen erstellen, die wir routinierten Devs dann überprüfen und danach festlegen, wie es weitergeht. Der „plan mode“ von Claude wurde einer unserer Hauptwege, einen ausführbaren Plan zu bekommen und ihn zu Reviewen, ehe die KI ihn ausführt. Diese Reviews sind elementar. Je erfahrener und handwerklich versierter die Devs sind, die die KI steuern, umso schneller geht das Projekt voran. Das klingt trivial, wird aber im Zuge der allgemeinen KI-Begeisterung manchmal vergessen.

Tatsächlich machen repetitive Aufgaben einen Großteil vieler Projekte aus, bei unserem war es definitiv der Fall. Deswegen hatten wir unser System in wenigen Wochen statt Monaten migriert, bei – dank unserer Kontrolle – hohem Qualitätsstandard. Unser persönliches Fazit lautet daher: Ist es eine gute Idee, eine technische Migration einfach einer KI zu überlassen? Ganz sicher nicht. Ist es eine gute Idee, als erfahrene Devs mit KI-Agenten zu arbeiten, um effizienter zu werden? Ja, unbedingt. Wir haben es ausprobiert.