andrena entwickelt – KI-gestützte Migration
Intro – Teaser-Ausschnitte aus der Folge
Florian: Gerade dieser Repetitive – mach was Ähnliches nochmal für alle anderen Dateien-Teil. Da kann man einfach massiv Kosten und Zeit einsparen und KI auch wunderbar einsetzen, wenn man der KI sozusagen sagen kann: hier ist eine Blaupause, für diese fünf Dateien wurde es erfolgreich gemacht, so sah es vorher aus, so sah es nachher aus.
Jochen: Verschiedene Varianten – und immer wieder nicht zum Ergebnis kommen. Und irgendwann hat sich der Agent halt komplett im Kreis gedreht, über Stunden. Das ist alles nicht so schlimm, aber es hat halt auch einiges an API-Kosten verbrannt, bis ich am nächsten Mal wieder draufschaue, was macht der da gerade eigentlich.
Florian: Es ist auf jeden Fall ein deutlich spürbarer Performance-Verlust, wenn man die KI einschränkt. Es ist auf jeden Fall eine aktive Abwägung zwischen Performance und Security. Dieses alte Lied von Security und Usability sind schwer vereinbar – schlägt auch hier voll zu.
[Jingle: „andrena entwickelt – der Podcast von andrena objects, von EntwicklerInnen für EntwicklerInnen.”]
Begrüßung und Vorstellung
Daniel: Willkommen zu einer weiteren Folge andrena entwickelt. Heute zu Gast: Florian und Jochen. Mein Name ist Daniel, ich bin bei andrena seit über sechs Jahren als Softwareentwickler. So, Florian, willst du dich mal kurz vorstellen?
Florian: Ja, hallo zusammen, mein Name ist Florian. Ich bin seit ziemlich genau zehn Jahren Softwareentwickler bei andrena. Habe mich in der Zeit mit verschiedenen Technologien, von Cloud-Technologien wie Azure zu Frontend-Technologien wie Vue, beschäftigt. Und das neueste Tool in meinem Werkzeugkasten ist KI-gestütztes Entwickeln, insbesondere agentenbasiert.
Daniel: Jochen, möchtest du dich auch kurz vorstellen?
Jochen: Ja, ich bin seit 20 Jahren bei andrena und inzwischen auch in der Rolle als – einerseits Entwickler, immer noch in den Projekten – auch als Geschäftsleiter. Habe mich nach ein paar Jahren verschiedener Java-Projekte mehr auf die .NET-Umgebung spezialisiert. Dort natürlich dann auch jetzt heutzutage viel mit Cloud-Systemen zu tun. Und mache schon seit vielen Jahren auch Migrationsprojekte von allen möglichen Technologien, naheliegenderweise dann eher Richtung .NET. Und ja, vor einiger Zeit – zusammen mit Florian – haben wir da ein paar Experimente gemacht, wo wir dann auch Migrationen durchgeführt haben, jetzt eben mit KI-Tool-Unterstützung, mit agentic Coding. Und ich finde das total spannend.
Die Experimente: Was wurde migriert?
Daniel: Perfekt, ihr habt ja gerade schon auch das Thema dieser Folge eingeleitet. Es soll darum gehen um Migration mit Unterstützung von KI oder auch komplett durch KI – das werden wir hier erfahren. Aber Jochen, du hast jetzt gerade eben ja schon erwähnt, ihr habt da Experimente gemacht. Kannst du mal erklären, was das für Experimente waren? Waren das irgendwelche kleinen Beispielprojekte oder hattet ihr da schon irgendwas Größeres, was auch wirklich in Produktion irgendwo läuft? Und wie sah das aus?
Jochen: Na gut, als Einstieg haben wir natürlich nur ein Beispiel genommen, das erstmal überschaubar war, um überhaupt mit dem Tooling vertraut zu werden und auch verschiedenste Varianten auszuprobieren. Das war dann etwas im Frontend-Bereich: ein System von React, in meinem Fall, nach Angular. Wir haben es in verschiedene Frontend-Frameworks migriert. Plus minus 10.000 Lines of Code – das war auch eher so ein bisschen, um Erfahrungen zu sammeln.
Dann haben wir uns dann den „Next Big Thing” gewagt: ein internes System bei uns, bei andrena, das es immerhin schon auf 100.000 Lines of Code bringt. Also schon ein bisschen mehr in die Waagschale geworfen, um dort dann mal eine technische Migration wirklich möglichst realitätsnah unter echten Bedingungen auszuführen. Wir haben uns das Leben vielleicht ein bisschen leichter gemacht, weil es ein andrena-System war. Das heißt, die Qualität war vom Ausgangssystem eigentlich gut. Es hätte eigentlich gar keine Migration gebraucht, aber es ging uns mehr darum, über die Methodik – und wie weit sind einfach die technischen Tools, wie weit sind die heutzutage schon, was taugen die, wo gibt es noch Probleme – um da einfach Erfahrung zu sammeln.
Erfahrungen mit dem kleinen Projekt (React → Angular)
Daniel: Gut, also ihr habt zwei interne Projekte – wenn ich das nochmal richtig zusammenfasse – umgesetzt, beziehungsweise migriert. Du hattest jetzt als Beispiel konkreter genannt, dass ihr von React auf Angular ein Projekt migriert habt. Was waren da so die Erfahrungen? Was sind so quasi das, was du gelernt hast? Jetzt, Jochen – ich weiß nicht, ob Florian da auch beteiligt war, aber gerne kann da auch Florian antworten. Was war so das, was ihr mitgekriegt habt? Was hat die KI gut gemacht? Wo habt ihr selber noch nachjustieren müssen? Was waren so die Learnings jetzt in dem kleinen ersten Projekt?
Florian: Also erstmal: das wirklich Positive ist, dass die KI mit einfachen Prompts und Verwendung von Standardfunktionalitäten von KI-Agenten in der Lage war, ein kleines Projekt mit 10.000 Zeilen Code zu migrieren – innerhalb von zwei Tagen mit einem Entwickler. Das ist einfach sehr, sehr positiv hervorzuheben. Wir haben das Projekt vor Jahren mal manuell migriert, händisch. Und das ging so ungefähr zwei bis drei Wochen mit mehr als einer Person, mit circa zwei Personen. Das ist einfach ein sehr, sehr großer Performance-Gewinn und eine Zeitersparnis. Und das ist erstmal das Wichtigste.
Probleme gab es natürlich auch auf dem Weg der Migration. Prinzipiell vom Ansatz her haben wir mit unterschiedlichen Technologien gearbeitet. Ich habe mit Claude gearbeitet. Ich habe den Plan-Mode verwendet, um Pläne erstellen zu lassen. Habe den händisch angepasst bei Dingen, die uns nicht gefallen haben. Und habe dann agentenbasiert die Migration durchführen lassen.
Im Ergebnis gab es vor allem in der UI Bugs. Ein Learning ist auf jeden Fall, dass es geholfen hätte, der KI Tests zur Verfügung zu stellen oder die KI Tests schreiben zu lassen, die das Frontend besser abtesten – zum Beispiel mit Playwright – damit die KI selbst validieren kann, ob das Frontend noch funktioniert. Oder der KI alternativ Zugriff auf den Browser zu geben, damit sie selbstständig die App starten und testen kann und validieren kann, ob noch alles funktioniert. Das ist aus meiner Sicht so der Hauptfehler, den ich gemacht habe.
Jochen: Ja, da kann ich gerade einhaken. Also ich denke, bei jeder klassischen Migration sagen wir das eigentlich immer gebetsmühlenartig: macht erst ein Testsicherheitsnetz, sozusagen, über die Anwendung, an der du dann das Ganze auch sozusagen benchmarkst – wie weit bist du schon mit deinem Migrationsstatus? Und genau diese Fortschrittskontrolle, die war jetzt bei diesem kleinen Projekt nicht so gravierend; beim Größeren – wenn wir dazu sprechen kommen – da war das ein viel eklatant wichtigerer Part. Aber nichtsdestotrotz: das sicherzustellen ist schon wichtig, auch bei kleinen Sachen. Und da sollte man nicht unter den Teppich kehren und denken, ach, die KI macht das schon. Unsere Erfahrungen deuten da eher immer genau das Gegenteil. Die vermeldet im Zweifelsfall immer: „Ich habe es geschafft, ich habe es gemacht” – mit beliebigen Ergebnissen und einer kleinen Prise Halluzinationen darf auch immer gern dabei sein, dass es halt vielleicht nicht mal kompiliert oder die Hälfte der Tests noch rot ist.
Also diese Quality Gates, die für uns eigentlich bei der agilen Softwareentwicklung selbstverständlich sind, die muss man dort einfach methodisch wieder auf eine andere Art und Weise mit reinbringen, mit reinstreuen. Und wie es der Florian auch genannt hat: also irgendwelche Tests, High Level, die jetzt End-to-End mit Playwright – könnten helfen.
Was bei mir zum Teil zum Beispiel passiert war: er hat das ganz schön migriert, aber es sah halt wirklich vom UI, wenn man dann draufgeschaut hat und gestartet, Kraut und Rüben aus – also das CSS-Styling war wirklich kaputt. Anders kann man es nicht sagen. Und in der Verzweiflung habe ich dann was ausprobiert, was tatsächlich extrem gut geholfen hat – das war dann eher eine positive Überraschung. Ich mache einfach Screenshots an der Altanwendung und habe gesagt: hey, so soll das bitte schön am Ende aussehen. Und dann hat er die ganzen Styles und Spacings und Margins und Ausrichtungen angepasst. Auf einmal hat es ausgesehen. Also das war dann eher eine positive Überraschung, dass du wirklich auch mit Screenshots, Mockups und irgendwelchen Anwendungsscreens da rangehen kannst und die KI da wirklich was mit anfangen kann.
Ein anderer kleiner Nebeneffekt – ich meine, die Modelle und was die können ist total im Fluss; wir sprechen jetzt von Herbst letzten Jahres. Ich hatte eine Zeit lang – ich will jetzt nicht auf speziellen Anbietern rumhacken oder sonst wie, wer es jetzt besser ist; da gibt es ja die Benchmarks, wo man das schauen kann – nur den kleinen Fehler gemacht, zeitgleich, dass ich mal auf ein schwächeres Modell drauf losgelassen habe. Das migriert munter, aber halt auch ziemlich viel Müll produziert. Also viele Endpoints oder irgendwelche Funktionsnamen halluziniert, die gar nicht in der Codebase abgedeckt waren. Und das musste man dann alles wieder mit Trial-and-Error und Debug-Loops reparieren.
Aber nichtsdestotrotz gab es auch den Faktor, wo Sachen gut gelaufen sind und richtig Speedups rauskamen – so, wie es der Florian genannt hat. Das war bei uns allen, die wir es probiert haben, unisono. Wir haben es parallel gemacht, dass jeder so sein Learning hatte. Nach zweieinhalb Tagen ist man da durchgekommen, das Ding war migriert – und das war dann schon ein tolles Ergebnis. Aber immer mit verschiedenen Vorgehensweisen und mit verschiedenen Quirks, mit denen man sich dann auch auseinandersetzen musste. Das war selber eben, denke ich, für die Lernkurve und wo es in den Risiken und Nebenwirkungen von der Vorgehensweise ganz gut war, das dann auch zu sammeln und zu dokumentieren.
Vergleich KI-Migration vs. händische Migration
Daniel: Sehr schön. Was Florian gerade eben erwähnt hat – beziehungsweise ein bisschen genauer: also ihr habt jetzt zwei, zweieinhalb Tage habe ich rausgehört, gebraucht, mit der KI zu migrieren. Ich habe aber auch jetzt von dir, Florian, explizit gehört, ihr habt das vor einer Zeit auch mal händisch gemacht, und habt da so zwei bis drei Wochen gebraucht. Was mich da jetzt ein bisschen interessieren würde: habt ihr die Ergebnisse von damals mal verglichen, was da so rauskam?
Florian: Also es gibt ein paar Unterschiede. Damals haben wir von Angular 1 auf React migriert. Das war auch ein bisschen eine größere technologische Umstellung, weil wir den Code teilweise aufgeräumt haben. Das hat uns mit Sicherheit ein bisschen ausgebremst, sozusagen, im Vergleich zu der Migration, die wir jetzt gemacht haben.
Was die Code-Qualität angeht, die dabei rausgekommen ist: ist die händische Migration aus meiner Sicht ein bisschen sauberer. Die Agenten, bei mir im Speziellen, wenn ich Properties heruntergereicht habe in Child-Components – darin ist die KI nicht so gut, diese Strecken aufrechtzuhalten. Und die KI löst das Problem, indem sie Komponenten inlined. Und dadurch sinkt einfach die Code-Qualität, weil man kleine, schön gekapselte Funktionalitäten dann auf einmal in ein paar größeren Komponenten dann wiederfindet. Selbst bei so einem kleinen Projekt merkt man nach einer KI-Migration, dass die Qualität etwas abnimmt. Und am Ende kann man dann im Prinzip nochmal einen Teil der Zeit – ich sag mal ein, zwei Stunden waren es jetzt bei den zwei, zweieinhalb Tagen – nochmal darauf verwenden, die suboptimalen Migrationen der KI wieder rückgängig zu machen.
Wie geht die KI mit sauberem Code um?
Daniel: Du hast jetzt gerade gesagt, die KI vereinfacht sich den Weg, damit sie damit halt umgehen kann. Ist das im Umkehrschluss, dass eigentlich das, was wir als sauberen Code bezeichnen, irgendwie nicht ideal ist, um da mit Agenten drauf loszulassen? Oder ist das jetzt nur ein Problem aktuell, wie jetzt bei der Migration mit dem Agenten und der Codebase umgegangen wurde?
Jochen: Boah, da spielt wahrscheinlich ein ganzes Sammelsurium mit rein. Also zum einen sind ja die ganzen Modelle irgendwo antrainiert worden, auf sehr, sehr, sehr viele Codebases. Und haben da vielleicht dann implizit auch gutes oder schlechtes Verhalten übernommen. Auf der anderen Seite – ich denke, das ist jetzt unabhängig von den Migrationsgeschichten; ich denke mal, bei dir wird es ähnlich sein im Projekt, wo ich jetzt auch jetzt im Kontext mit KI-Agenten arbeite – sie richten sich eigentlich sehr stark nach dem, was ich schon als Ökosystem, als Umgebung habe. Also das ist ja diese klassische Stärke: ich sehe irgendwelche Patterns und leite daraus ab. Und das heißt: wenn ich ein sehr gut wohlstrukturiertes System habe mit Codebase, wird ja auch in ähnlicher Struktur das weitergeführt – im Guten und im Schlechten. Also darin sind die LLMs – das ist so, was die immer machen – auf dieser Ausgangsbasis interpolieren: wenn das schon so aussieht, was wäre das Nächste, wenn ich es erweitere, wie es aussehen sollte.
Und das natürlich bei einer Migration ist insofern auch spannend, weil das heißt im Umkehrschluss: die Ausgangsgrundlage – wie gut oder schlecht die Qualität des Systems, das ich migrieren will – hat massiv Einfluss darauf, was die KI daraus fabriziert. Also wenn ich da einen Monolith mit Spaghetti-Code reinstecke, dann kriege ich wahrscheinlich nicht gerade ein sehr schönes Ergebnis am Ende raus, weil es sich einfach erstmal – wenn ich ihm nicht explizit konträre Anweisungen und Prompts gebe – erstmal an dem orientiert, was es einfach vor sich liegen hat, und an dem sozusagen weitermachen möchte von der Struktur.
Und das ist dann das Spannende, weil oft haben wir ja die Not, eine Migration zu machen, weil eben das Kind im Brunnen gefallen ist. Und dann schaue ich: wie fixe ich das wieder, wie verbessere ich das? Und da muss man vielleicht die Phasen auch trennen – so wie du es gerade auch hast klingen lassen: erstmal sozusagen den rein mechanischen Hub von Plattform-Technologie X nach Y in Kauf nehmen, dass die Qualität vielleicht gar nicht besser wird oder sogar ein bisschen leidet – und dann eher weitere Runden mit Umbau- und Refaktoring-Maßnahmen drehen.
Man kann das natürlich auch versuchen in place sozusagen durchzubeißen. Also was ich vor allem bei dem größeren Projekt später gezeigt habe, was ziemlich wichtig ist: dass du an einem kleinen Slice und einer Art vertikalen Durchstich mal verprobst, explizit sozusagen, von Vorher. Das setzt natürlich voraus, dass du eine gewisse geeignete Modularisierung von deinem Problem hinbekommst und hast, wo du das so proben kannst. Wenn du das hinbekommst: sozusagen von dem Ausgangsstand – du hast, was weiß ich, ein System mit zehn Modulen – schnappst du eins davon raus und assistiert mit der KI zusammen baust du das um in den Zielzustand, in die neue migrierte Welt. Dann hast du damit so eine Art Blaupause geschaffen, wo dann eben die KI das wieder sehr gut und sehr einfach adaptieren und ausrollen kann auf die ganzen anderen Code-Parts. Also sie braucht irgendwo immer Beispiele, Anleitungen.
Ich meine, das kriegst du auch so, wenn du irgendwie was mit ChatGPT – egal in welcher Domäne – machst: das ist ja immer, wenn du gute Ergebnisse willst, liefere ihr auch Beispiele, wie soll es sein, was du haben willst. Und das gilt bei Code tatsächlich genauso. Du musst dir praktisch genau diese Anleitung, diese Beispiele geben: welches Ergebnis möchtest du haben? Und je konkreter und genauer du das vorgibst, umso mehr kriegst du die Ergebnisse in dieser Richtung.
Das größere Projekt: Spring Boot → Quarkus
Daniel: Ihr habt ja jetzt beide schon mal dieses größere Projekt – wir hatten jetzt gerade lange Zeit über das Frontend-Migrationsprojekt gesprochen, das ihr als Experiment gemacht habt. Ihr habt aber auch ein größeres, aktuell auch bei andrena produktiv eingesetztes System mal auf eine andere Technologie migriert. Willst du da mal kurz mal eingehen, damit wir da so ein bisschen einen Überblick haben, was ihr da getan habt? Weil jetzt wurde ein paar Mal drauf referenziert.
Florian: Im Prinzip ist das eine Migration von einem Framework gewesen. Wir sind mit Java und Spring Boot gestartet und haben zu Java mit Quarkus migriert. Grund war einfach, dass wir nicht einen zu großen Sprung technologisch machen wollten – zum Beispiel zu einer komplett anderen Programmiersprache. Im Nachhinein hätte das vielleicht gar nicht so einen Riesenunterschied gemacht. Auf jeden Fall wollten wir es uns erstmal nicht zu schwer machen.
Und wie Jochen auch schon gesagt hat: das Wichtigste war, dass wir einen guten Startpunkt hatten mit schon modularisiertem Code. Und dadurch hatten wir eben die Möglichkeit, die KI gezielt so zu prompten und ihr gezielt Anweisungen zu geben, dass sie schrittweise migrieren soll, dass sie zuerst mit den Basismodulen anfangen soll und danach mit den Modulen, die darauf aufbauen. Dadurch konnten wir eben schrittweise migrieren. Und ich glaube, das war auch einer der Schlüssel dazu, dass das gut klappt.
Jochen: Ja, ich würde da vielleicht noch Anmerkungen dazu. Du – insbesondere, das haben wir dann als Team zusammen durchgeführt – hattest da einige Vorleistungen reingesteckt, überhaupt das mal zu analysieren von der Ausgangstechnologie und der Frameworks, die wir verwenden: welche möglichen Smooth-Migration-Pfade gibt es denn da? Also es gibt bei Quarkus sozusagen einen Spring-Boot-Compatibility-Layer. Der hat viel versprochen – in der Praxis ein bisschen weniger gehalten, als wir erhofft hatten. Den wollten wir halt einfach nehmen, dass wir nicht alles in einem Wupp gleich komplett umschreiben müssen, auch mit den ganzen Annotations, mit den Framework-spezifischen Sachen – sondern dass das Quarkus-Ökosystem trotzdem auch noch mit Spring-Boot-Artefakten umgehen kann, zu einem gewissen Grad. Also einfach den Schmerz, dass man noch viel kleinteiliger Schritt-für-Schritt-Migration. Da gab es ein paar Pitfalls, wo es dann leider gar nicht so gepasst hat, wie es versprochen war.
Aber nichtsdestotrotz war das ein guter Schritt, erstmal zwei, drei Tage für das Gesamtsystem eine Analyse reinzustecken. Also das, was ich auch in der klassischen Welt, wenn ich eine Migration mache, auch machen sollte und niemals überspringen sollte, sondern erstmal mir das Gesamte anzuschauen, durchleuchten und überlegen: wirklich einen Schlachtplan. Wie komme ich denn Schritt für Schritt zu diesem Umbau, zu dieser Migration, zum Zielsystem? Auch da ist natürlich die KI wieder wunderbar, sehr große, schöne Pläne einem zu erzeugen mit hunderten oder tausenden von Tasks – was dann tatsächlich ganz neue, interessante Probleme aufwirft.
Ich nenne nur das Passwort einfach: das Kontextfenster, das so ein LLM heutzutage hat. Ja, die wachsen stetig. Wir sprechen von – sagen wir mal im Schnitt – mal 200.000 Tokens. Der Neueste schreit dann immer, dass jetzt alle auf eine Million hochgehen oder noch größer. Klingt nach sehr vielen. Wird immer gesagt: ich kann ganze PDF-Dokumente reinschmeißen. Aber so eine große Codebase mit 100.000 Lines of Code hat locker das Potenzial, solche Context-Fenster zu zerfetzen. Und wenn mir das Context-Fenster überläuft, dann wird das Modell, der Agent sozusagen vergesslich und produziert im Zweifelsfall nur noch Blödsinn – weil er gar nicht mehr weiß, was er eigentlich machen sollte und nicht mehr die nötigen Informationen hat, weil die einfach wie bei einem Overflow weg sind.
Deswegen ist bei so einem großen System, wie du es auch schon gesagt hast, Florian: die Modularisierung ganz essentiell wichtig. Die Divide-and-Conquer-Strategie, dass ich das Problem in kleinere Teile zerlegen kann, um es wieder beherrschbar zu machen. Und auch da bietet es sich an – ich denke, das haben wir jetzt in der Phase noch nicht ganz total in Angriff genommen, es war im Plan so: wenn ich ein Modul hatte, dann könnte ich später die anderen alle total parallel mit parallelen Agents – da kanns es zum Teil vielleicht zumindest in der Zeit noch ein bisschen am Tooling. Da tut sich sehr viel bei allen Anbietern. Und das ist auch auf jeden Fall der Weg in die Richtung, wo man hingehen will, weil dann kriege ich einfach noch ganz andere Speedups in Zukunft, wenn das zuverlässig und gut läuft – dass ich dann wirklich zehn parallele Agents habe, die mir auf verschiedenen Worktrees zum Beispiel die ganzen Tasks abarbeiten und das dann alles wieder zusammenbringen. Das ist aber noch ein bisschen Zukunftsmusik. Also da war man in der Phase noch nicht – das war eher ein rein sequenzielles Abarbeiten. Aber das hat schon ganz gut funktioniert, weil ich dann eben diese kleineren Einheiten habe.
Florian: Ja, das Einzige, was ich parallelisiert habe, war das Testschreiben. Ich wollte gerne noch Framework-unabhängige Tests. Also wir hatten davor nur Spring-Boot-Tests, und ich wollte gerne Tests mit REST-assured oder einer ähnlichen Technologie, die sozusagen während der kompletten Migration unverändert bleiben können. Und die habe ich parallel zur eigentlichen Migration schreiben lassen. Da ist Git-Worktrees ein wunderbares Tool, um eben mit mehreren Branches von demselben Projekt lokal zu arbeiten und verschiedene Dinge der KI vorzugeben.
Ansonsten – genau wie Jochen gesagt hat – ist halt das Modularisieren entscheidend. Und ich glaube auch in Zukunft wird es noch entscheidender für den Speedup. Und in dieser Voranalyse ist es, glaube ich, besonders wichtig, sich darüber bewusst zu werden, welche Vorarbeiten man machen muss. Wenn das Projekt einfach ein großer Big Ball of Mud ist, dann macht es vielleicht nicht Sinn, im ersten Schritt direkt eine Migration zu machen, sondern im ersten Schritt Module zu erkennen und zu isolieren, die man dann schrittweise abarbeiten kann.
Es ist auch einfach entscheidend, möglichst kleine Schritte zu machen, direkt nach jedem Schritt zu committen. Die KI kriegt nicht jeden Schritt perfekt hin und manchmal rennt sie sich auch einfach fest. Und es ist einfach ein sehr nützliches Tool, den Quatsch, den die KI in der letzten Stunde fabriziert hat, wegzuwerfen und zu sagen: mach einfach mit derselben Idee nochmal oder mit kleinen Anpassungen im Prompt, wo man der KI sozusagen erklärt: das hast du letztes Mal gemacht, das hat nicht geklappt, überleg dir was anderes – und sie es dann nochmal probieren zu lassen. Und je größer halt diese Schritte sind, diese Pakete, die man an die KI übergibt, desto größer ist das Risiko, dass man, wenn man eine Stunde später nachguckt, was die KI eigentlich getan hat, dass man feststellt, dass man alles wegwerfen muss und nochmal machen muss. Und genau um dieses Risiko zu reduzieren, ist es wichtig, kleinteilige Aufgaben zu finden.
Jochen: Ja, vor allem gibt es Versprechen im Raum: die KI kann ja weiterarbeiten, wenn ich dann offline bin oder schon ins Bett gehe, und über Nacht macht die einfach weiter. Klingt gut. In der Praxis war es manchmal dann doch noch ein bisschen ernüchternd. Also ich hatte eine Anekdote, wo ich einfach was habe umbauen lassen, und er ist dann dummerweise in eben so eine Diskrepanz reingerannt: so sollte es eigentlich funktionieren, so sagt es auch im Internet, jede Doku – aber es funktioniert halt nicht mit dieser Spring-Compatibility-Layer in der Persistenz. Und er hat verschiedene Sachen ausprobiert, verschiedenste Varianten – und immer wieder nicht zum Ergebnis kommen. Und irgendwann hat sich der Agent halt komplett im Kreis gedreht, über Stunden. Ich würde sagen, ist nicht so schlimm, aber es hat halt auch einiges an API-Kosten verbrannt, bis ich am nächsten Morgen wieder draufschaue, was macht der da gerade eigentlich.
Kosten der KI-Migration
Daniel: Weil du gerade das Thema Kosten angesprochen hast – und das ja immer so ein Thema ist, auf das öfters geschaut wird, wenn es auch um das Thema KI geht: habt ihr da grobe Hausnummern, was ihr jetzt in dem Fall für die Migration des Frontends oder die Migration jetzt dieses Spring Boot auf Quarkus, was für Größenordnungen reden wir? Über wie viele Tage, wie viel Zeit habt ihr da reingesteckt? Weil das ist ja auch eine relevante Größe, wenn man so über den Einsatz von KI nachdenkt, weil man bezahlt nicht nur den Entwickler, sondern man bezahlt auch noch diese API-Kosten an die Anbieter.
Florian: Also erstmal: haben wir pro Request bezahlt. Theoretisch gibt es auch Lizenzmodelle, wo man eine Flatrate kauft für, ich sag mal, 200 Euro im Monat. Das haben wir nicht getan. Bei dem kleinen Migrationsprojekt haben wir drei unterschiedliche Ansätze gewählt, und die Preise waren zwischen 20 und 80 Euro KI-Kosten und zwei bis zweieinhalb Tage Menschenarbeit.
Der Haupt-KI-Kostentreiber war der Task-Master. Der unterteilt die Aufgaben einfach in sehr, sehr kleine Schritte. Das ist eine Erweiterung, die wir in Claude eingebunden hatten. Und das Hauptproblem am Task-Master für eine kleine Migration war: der arbeitet sehr kleinteilig, der führt sehr regelmäßig die Tests aus und überprüft die Test-Outputs. Test-Outputs haben sehr, sehr viele Tokens, weil sie sehr, sehr verbose sind. Und dadurch gibt es einfach sehr, sehr schnell höhere Kosten. Das ist bei einem kleinen Projekt nicht so nötig, sag ich mal. Dieses strikte Vorgehen – da hat es sich nicht so mega bezahlt gemacht aus meiner Sicht. Aber je größer das Projekt, desto vorteilhafter ist dieses strikte Vorgehen und je komplexer auch die Aufgabe. Da, denke ich, lohnt sich das Vorgehen dann immer stärker und wird immer relevanter, je komplexer und größer die Migration ist.
Jochen: Ja, da kann ich nur zustimmen. Also auch gerade bei der Großen, die Fehler – ich meine, das ist nicht unerwartet – und wenn ich da nicht arg auf die Qualitätssicherung und Kontrolle achte, dass die Tests halt immer grün sind für jedes Teilmodul oder für jede Layer, und dann einfach weitermache, dann summieren die sich auf. Das ist wenig überraschend, denke ich mal. Aber es ist halt ein reales Problem im Umgang mit agentic Coding, dass die KIs – ich gebe halt vor: okay, bevor du sagst, diese Story oder dieser Umbau des Moduls ist abgeschlossen, müssen alle Tests 100 % grün sein. Klingt erstmal gut – und irgendwann vermeldet die KI Erfolg. Aber es kann halt sein: zwar ein paar Tests rot, die hat sie dann einfach gelöscht, weil die stören halt, die kriegt sie nicht grün – dann löscht man die halt. Oder andere lustige Effekte. Oder es sagt, es ist alles gut, und dann führe ich selber mal aus, und es sind halt nur 95 % grün. „Aber die 5 % – das ist doch nichts.” Also so eine Fasselei schimmert immer wieder durch.
Und da wäre es dann wahrscheinlich bei einem Größeren, wenn man das nochmal angeht, von den Learnings: würde ich da auch rein investieren, Hooks zum Beispiel bei Claude reinzusetzen oder anderen, wo ich praktisch einfach vor meinem Prozess-Pipeline, das Pipeline, bevor irgendwas gepusht oder sonst wie wird, das automatisch erzwungen wird – also gar nicht der KI überlassen, sondern einfach vom Tooling drumherum erzwingen, solche Qualitätsschritte, Quality Gates durchzuführen, und nicht zu sagen: der eigenen Beurteilung, mache ich das jetzt oder nicht oder wie habe ich gerade Lust drauf. Das ist leider im Moment noch ein bisschen der Stand der Dinge. Kann sich natürlich auch in den nächsten Monaten hoffentlich noch verbessern, dass die KI das auch mehr ernst nimmt – nicht nur als eine Option. Aber das sind halt so kleine Sachen, die immer wieder stören können im Ablauf.
Daniel: Also wir haben ja jetzt gerade Zahlen gehört von 20 bis 80 Euro für diese Migration des kleinen Projektes. Hört sich jetzt für mich erstmal nicht nach so dem großen Kostenfaktor in einem Projekt an. Es sind aber halt Kosten, die nicht direkt auf eine Arbeitskraft abgewälzt werden. Natürlich, sie produziert sie irgendwo. Also würde ich damit annehmen, dass die Kosten jetzt nicht unbedingt das K.O.-Kriterium dafür sind, die KI einzusetzen.
Jochen: Sie sind auch nicht vernachlässigbar, sagen wir mal so. Also bei dem Größeren, über ein paar Wochen, redet man eher dann in der Größenordnung vielleicht plus minus 1.000 Euro, was sich dann schon zusammenlemmert. Ich meine, selbst wenn ich eine Subscription nehmen würde, so für 200 Dollar, dann habe ich wieder den Kampf mit Rate Limits, was ich bei aktuellen Kontexten, wo ich arbeite, tatsächlich erlebe. Also es ist noch nicht so, dass man eine Art Flatrate hat, wo ich so viel machen kann, wie ich will und dann klappt das einfach. Die Limits sind da, und wenn ich über die hinaus will, dann fallen schon API-Kosten an. Aber natürlich, wenn ich das vergleiche mit einem Tagessatz von einem Entwickler, dann ist das eigentlich ein günstiger Begleiter. Einfach – sind Toolkosten. Sind nicht null, aber auch nicht astronomisch.
Florian: Der Hauptvorteil ist, glaube ich: es gibt einfach bei den meisten Migrationen repetitive Aufgaben. Nachdem man einmal eine Lösung gefunden hat – ein Schema F, das für ein Problem, was man migrieren muss, funktioniert – muss man das einfach für hunderte Dateien nochmal anwenden in ähnlicher Weise. Und da ist einfach ein Entwickler viel teurer als eine KI und viel langsamer. Und gerade dieser Repetitive – mach was Ähnliches nochmal für alle anderen Dateien-Teil. Da kann man einfach massiv Kosten und Zeit einsparen und KI auch wunderbar einsetzen, wenn man der KI sozusagen sagen kann: hier ist eine Blaupause, für diese fünf Dateien wurde das erfolgreich gemacht, so sah es vorher aus, so sah es nachher aus. Schreib mir mal einen Plan auf, wie das bei den fünf Dateien funktioniert hat. Dann erzeugt die KI ein Dokument: ich muss diese zehn Schritte machen. Das reviewt man manuell und guckt, ob die KI das richtig zusammengefasst hat. Dann lässt man die KI das auf die nächsten fünf Dateien ausführen, guckt, ob die KI es hingekriegt hat. Und wenn das klappt, sagt man: und jetzt mach die anderen, keine Ahnung, 300 Dateien auch so – oder alle Stellen, wo du findest, wo das Verfahren auch passt, mach es so. Dann ist die KI einfach sehr, sehr gut darin, dieses vorhandene Pattern wieder zu verwenden und anzuwenden. Und das spart uns auch einfach lästige Arbeit, die wir einfach nicht gerne machen. Und das ist wirklich ein Win-Win auf allen Seiten, inklusive den Kosten.
Jochen: Ich denke, da kommen dann auch die Speedups her, wo man sagt: es geht einfach faktisch schneller – also allen Unkenrufen zum Trotz. Den genauen Faktor – ich denke, das hängt von vielen Faktoren ab, und da sind wir auch noch am Rausfinden, gibt es eine gewisse Grundmuster, wo man sagen kann „so und so viel”. Ich würde da noch nicht in die Verallgemeinerung gehen wollen. Aber man ist wesentlich schneller, wenn es skaliert und wenn es solche repetitiven Parts gibt – da rollt die KI dann ihre Stärken aus.
Und für Kunden ist es dann ja auch extrem spannend, weil KI-Projekte werden ja oft gescheut, überhaupt in Angriff zu nehmen, weil einfach so viel Code, so viel Zeit und Manpower, die man dafür braucht. Und wenn ich das massiv reduzieren kann, dann kann ich es vielleicht auch mal wagen, für ein Modul zum Beispiel mal einen Testballon zu starten, schauen, was kommt am Ende raus, um das als einen Benchmark zu legen und gucken: okay, ist das Gesamtvorhaben dann doch in Angriff zu nehmen? Ich denke, da öffnen sich einfach ganz neue Möglichkeiten gegenüber der klassischen Herangehensweise, wo es dann oft einfach schon an der Planung und dem Budget scheitert, das man schlicht dafür bräuchte.
Sicherheit und Datenschutz
Daniel: Das hört sich ja schon mal sehr positiv an, wenn man jetzt mal aus Kundensicht oder der Projektleitung oder wen auch immer mal draufschauen möchte. Es sind ja neben den Kosten aber auch andere Themen, wo KI immer so ein bisschen negativ dargestellt wird – sind das ja unter anderem der Datenschutz oder generell die Sicherheit. Es gab auch News, wo halt diese KI-Modelle, weil sie halt teilweise Root-Zugriffe haben, einfach Sachen gelöscht haben, auch teilweise irgendwelche API-Keys halt irgendwo hingepusht haben öffentlich – was jetzt nicht böswillig war von der KI, aber es kann halt passieren. Habt ihr solche Sachen beobachtet, oder habt ihr da Maßnahmen ergriffen, um dagegen in diesem abgesteckten Experiment etwas zu tun oder es zu verhindern?
Florian: Ja, also es ist auf jeden Fall ein sehr spannendes und relevantes Thema. Konkret so schlimm war es bei mir nicht. Was bei mir tatsächlich passiert ist: wir haben zehn Codex-Lizenzen, die wir als Flatrate haben. Die haben wir natürlich versucht auszunutzen, die Flatrate. Und es gab einen Zeitraum, der war so grob drei, vier Tage lang, da ist die KI immer wieder abgedriftet in andere Sprachen – also weder Deutsch noch Englisch, sondern dann Japanisch oder Chinesisch – und hat dann in den Prompts halt einzelne Wörter in anderen Sprachen ausgegeben. Das hat dann dazu geführt, effektiv, dass ich mich mit dem, was du gerade angesprochen hast, Daniel, beschäftigt habe: was passiert eigentlich, wenn die KI sowas in meinem Code macht? Wie kriege ich das mit?
Klar, man reviewt den Code manuell, aber manchmal ist es ja auch schon zu spät. Zum Beispiel, wenn die KI in der package.json irgendeine Dependency hinzufügt und ein npm install ausführt, ist das Kind vielleicht schon in den Brunnen gefallen. Dadurch, dass ich da relativ defensiv rangegangen bin und der KI nur ganz bestimmte Befehle erlaubt habe, konnte ich das bei mir ausschließen, weil zum Beispiel npm install nicht in der Allow-List stand. Das kann ich auf jeden Fall empfehlen: sehr genau darauf zu achten, was man der KI erlaubt. Nur bestimmte Befehle, die Sinn machen, wie zum Beispiel die Ausführung von Tests zu erlauben – die die KI einfach oft braucht – und so einen sinnvollen Mittelweg zwischen „gefährliche Befehle nicht zulassen” und „für die KI nützliche und häufig ausgeführte unkritische Befehle zulassen” zu finden. Von sowas wie einem YOLO-Modus würde ich persönlich komplett abraten, weil der einfach zu viele Risiken mit sich bringt. Je nachdem, in welchem Umfeld man unterwegs ist, welche Daten man auf dem Rechner hat, kann es einfach unschöne Ergebnisse haben.
Maßnahmen gibt es verschiedene. Im Prinzip ist das Hauptschlagwort Isolation beziehungsweise Sandboxing. Dabei gibt es verschiedene Technologien, die man benutzen kann. Die allereinfachste und sicherste ist: man benutzt einfach einen extra Rechner für KI-Zeugs. Die ist aber leider auch teuer, weil man dann zwei Rechner braucht. Eine zweite Möglichkeit ist die Benutzung von Virtual Machines. Virtual Machines gibt es schon lange, die sind erprobt, und es gibt hin und wieder Jailbreaks von Virtual Machines. Aber im Allgemeinen ist das auf jeden Fall beides ein riesiger Security-Gewinn gegenüber „man macht gar nichts”. Und noch ein einfacherer Weg ist Dev-Containers, der gerade im Entstehen ist. Da gibt es sowohl von Docker als auch von Claude auf den offiziellen Seiten Dev-Container-Vorlagen. Leider sind die gerade noch unsicher und haben Lücken. Da hat ein Kollege von uns auch Pull-Requests gestellt, um Lücken zu schließen.
Vielleicht noch ganz kurz als Hintergrundinformation: was ist Isolation, worauf muss man achten? Es gibt zwei wichtige Bereiche. Der eine ist, den Zugriff auf kritische Daten einzuschränken. Bei Dev-Containers bedeutet, dass man mounted halt nur einen bestimmten Bereich – meistens ist es genau das Git-Repo, wo die KI arbeiten soll – in den Dev-Container, damit die Agents nur Zugriff auf dieses Projekt haben. Also Zugriff auf Daten beschränken, die die KI wirklich braucht. Und das Zweite ist, den Zugriff auf das Internet zu beschränken, auf Seiten, die die KI wirklich braucht. Zum Beispiel, wenn man der KI nicht erlaubt, auf beliebige Server wie zum Beispiel myevilhomepage.com zuzugreifen, dann kann sie da halt keine bösen Daten herunterladen oder geheime Daten hinschicken – zumindest nicht so leicht. Und das sind so die zwei Hauptaspekte, die man mit diesem Dev-Container-Ansatz angeht.
Jochen: Genau, das eine ist wirklich für die reine Entwicklung. Und ich meine, ich komme ja aus der .NET-Ecke und bin deswegen eh schon gewohnt, oft mit Visual Studio Code zu arbeiten. Und dort ist der Umgang mit Dev-Containern eigentlich sehr bequem. Insofern kann ich das schon empfehlen: dass, wenn man sich an diese Tools ranwagt, zumindest diesen kleinen Zwischenschritt versucht zu leben – und nicht im sogenannten YOLO-Modus arbeitet und einfach alles zulässt. Kann eine ganze Weile gutgehen, aber das latente Risiko ist halt da, dass die KI über die Stränge schlägt und was weiß ich macht.
Und das andere – da sind wir natürlich auch noch in vielen Diskussionen, ich nehme das auch bei vielen Kunden wahr: beschäftigen sich alle damit, welche Modelle kommen überhaupt zum Einsatz? Auch da gibt es halt das ganze Spektrum, angefangen mit den populärsten Modellen, die irgendwo in den USA gehostet sind, versus „ich hoste halt selber offene Modelle auf irgendeiner Cloud-Infrastruktur”, die dann wo auch immer gehostet liegt. Und natürlich für High-Critical-Sachen wäre es wahrscheinlich am besten, wirklich Modelle ganz allein auf Servern bei mir in der Firma zu hosten, damit die Daten gar nicht überhaupt das Unternehmensnetzwerk verlassen. Und das muss man einfach an der Kritikalität von den Daten, von dem System, den Prozessen abwägen und beurteilen: wo kann ich was einsetzen? Am besten da einfach auch Zeit und Energie reinstecken, eine Art Klassifikationssystem mit dem Unternehmen einzuführen, sagen: wo gibt es Guidelines, was mache ich? Weil wenn ich das nicht definiere, dann passiert halt alles und nichts.
Florian: Ja, ein guter Einstiegspunkt in das Thema ist, glaube ich, der Artikel von Simon Willison: „The Lethal Trifecta”. Da stellt er das nochmal schriftlich dar, was wir gerade mündlich erklärt haben – wie diese kritische Kombination bei KI, also Zugriff auf private Daten, die Fähigkeit nach extern zu telefonieren und das Aussetzen gegen nicht vertrauenswürdigen Content (also in dem Fall irgendwelche KI-generierten gefährlichen Befehle), diese Kombination aus den drei Sachen ist sozusagen das Gefährliche. Und das ist da sehr schön zusammengefasst und wurde durch den Artikel sozusagen auch als Thema deutlich populärer und in der Breite stärker vertreten.
Daniel: Ja, den Artikel packen wir auf alle Fälle in die Folgenbeschreibung rein. Was ich mir jetzt nur gerade gedacht habe: wir haben Sicherheit gewonnen durch die Isolation – hat das aber auch Nachteile, weil wir beschränken ja die Fähigkeiten der KI etwas? Oder sind die Nachteile gar nicht so groß, dass man darüber nachdenken sollte, der KI ein bisschen mehr Freiheiten zu geben?
Jochen: Naja, eins ist, denke ich, in der Methode schon gravierend, wenn ich sozusagen die Befehle immer wieder gegenzeichnen muss, sozusagen was er macht. Das limitiert sehr, wie ein Auto noch mehr vorangehen kann, wenn ich alle zehn Minuten mal schauen muss, ob er irgendwo hängt – weil es wieder Kommandos gibt, die ich ihm lieber nicht Blankoscheck ausstelle, dass er das machen darf: Sachen löschen oder beliebig irgendwelche Pauschal-Skripte auszuführen. Da bin ich, denke ich, ähnlich wie bei mir mit Florian, da wäre ich echt vorsichtig, das einfach so immer machen zu lassen, weil KI ist dann leider auch kreativ, da beliebig Sachen reinzupacken, wenn sie sonst nicht weiterkommen. Auf der anderen Seite, wenn ich das so eingeschränkt habe – nur mein Repo gemountet, dass er da die Dateien lesen und editieren darf – da gebe ich ihm schon eher ziemlich einen freien Fahrtschein, aber gewisse Operationen sollte man einfach limitieren. Und genau das kann halt sein, dass er das aber trotzdem braucht, dass es valide ist, und dann immer wieder den Fluss sozusagen stoppt oder unterbricht bei der Abarbeitung.
Florian: Gerade insbesondere mit dem Arbeiten mit mehreren Agenten wird das immer relevanter, weil dann warten auch mehrere Agenten auf den Input und das Okay des Users. Dann wird man selbst – das merkt man richtig – also ich schon bei zwei Agenten wird man richtig zum Flaschenhals, dass man merkt, die Agenten warten auf die Entscheidung. Und wenn irgendein Agent mal ein Problem hat, wo man ein Prompt nochmal neu designen muss, wo man sich überlegen muss, warum hat es die KI nicht geschafft, welche Information hat ihr gefehlt – am Ende warten halt alle Agenten darauf, dass es weitergehen kann. Es ist auf jeden Fall ein deutlich spürbarer Performanceverlust, wenn man die KI einschränkt. Es ist auf jeden Fall eine aktive Abwägung zwischen Performance und Security. Leider: dieses alte Lied von Security und Usability sind schwer vereinbar – schlägt auch hier voll zu.
Jochen: Man kann es versuchen ein bisschen zu leveragen. Zum einen ist das eben: wo die großen Modelle, mit was die antrainiert sind, kommt man schon sehr weit heutzutage. Das heißt: ich sage jetzt mal, wenn ich wirklich Internetzugriff komplett kappe, heißt das nicht, da geht nichts mehr. Also das ist schon viel einfach in den Modellen drin. Und wenn ich dann selektiv gewisse MCPs zum Beispiel erlaube – Context7 ist so, sei es nur eins genannt, das ziemlich viel hilfreich sein kann, um die neuesten APIs und irgendwelche Frameworks im Zugriff zu haben im Kontext. Oder zumindest webmäßig könnte ich es auch sublimieren durch DeepWiki oder so – einfach, wo ich gewisse Frameworks abfragen kann, also nur wenige Adressen zulasse, wo er relevante Informationen für seinen Kontext kriegt für die Arbeit, aber eben nicht mehr. Also es ist eigentlich nicht nötig, dass ich ihm volle Google-Search-Capability gebe. Zumindest im Coding-Bereich sehe ich das ziemlich wenig ein, dass das da nötig wäre. Für ganz andere Tasks, wenn ich irgendwelche Analysen fahren will über Web-Ressourcen – klar, dann geht es nicht ohne. Aber jetzt hier so für Code- oder Migrationssachen könnte man das schon relativ definiert einschränken: wo will ich denn ranlassen, an welche Wissenstöpfe, und das dann auch entsprechend limitieren?
Florian: Was man dann auch ergänzen kann ist, dass dieses Limitieren halt auch wieder Zeit kostet, natürlich diese ganzen Regeln sinnvoll aufzusetzen. Was auf jeden Fall sehr empfehlenswert ist: diese Ressourcen mindestens im eigenen Team, optimalerweise firmenweit zu teilen oder abteilungsweit, damit man eben nicht diese Arbeit, diese Setups von dieser sicheren Umgebung, multipliziert – sondern dass man halt dadurch, dass man dieses Setup teilt, diesen Aufwand nur einmal hat und auch eine möglichst sichere Umgebung für alle hat. Weil ultimativ bei Security geht es immer um den schwächsten Link. Wenn jeder Mitarbeiter sein eigenes Süppchen gekocht hat, ist halt der Mitarbeiter mit der schlechtesten Konfiguration von diesem Sandboxing dann der Mitarbeiter, wo es nicht klappt – und dann können alle anderen Sandboxes so sicher sein, wie sie wollen.
Mehrere Agenten und Context-Switching
Daniel: Florian, du hattest einen interessanten Punkt gebracht, dass du quasi das Bottleneck wirst, wenn es mehrere Agenten sind. Was ich da rein interpretiere ist: du hast ja Agenten, die machen unterschiedliche Sachen, und da hast du dann sehr viele Context-Switches. Wie bist du damit umgegangen? Wie hast du da die verschiedenen Aufgaben, die die einzelnen Agenten halbwegs autonom bisher gemacht haben, nachvollziehen können, dass du auch schnell eine fundierte Entscheidung treffen kannst – oder die Ausgabe, weil oftmals schnell die Modelle ja fragen, für dich ausreichend genug waren, um eine fundierte Entscheidung zu treffen? Gab es da irgendwelche Methoden oder Sachen, die du der KI mitgegeben hast, dass ihr das einfacher und schneller machen könnt, anstatt durch mehrere hundert Zeilen Ausgabe zu scrollen?
Florian: Ein Prinzip ist die Kurzfassung – da habe ich mich an Feuer gebrannt. Das ist tatsächlich ein aktives Problem, wo man einfach Köpfchen reinstecken kann, um das zu verbessern. Tatsächlich gibt es viele Ansätze. Also ein Ansatz ist mit Sicherheit, die Regeln, die die KI permanent in ihrem Gedächtnis hat, in der CLAUDE.md schrittweise zu verbessern, damit die KI nicht immer wieder die gleichen Probleme hat. Wenn es häufig wiederkommende Probleme gibt, der KI zu sagen: jetzt schreib mal in die CLAUDE.md dieses Problem rein und wie du es löst, damit du mich nicht die ganze Zeit damit nervst, sozusagen – dann hat man halt das Problem nicht mehr.
Dadurch wächst die CLAUDE.md dann auch zügig. Dann kommt man wieder zu dem Problem von Jochen, dass die KI, wenn man zu viele Informationen vorab in den Kontext steckt, vergesslich wird. Das heißt, da muss man ein gesundes Maß zwischen „relevant und hilfreich” versus „einfach zu spezifisch und zu viel” finden. Eine Möglichkeit ist zum Beispiel, extra Dateien anzulegen für bestimmte Tasks und die der KI bei bestimmten Prompts mitzugeben. Zum Beispiel bei Claude mit @Dateiname kann man dann zusätzliche Informationen für bestimmte Migrationsaufgaben mitgeben – oder halt mit Skills oder Hooks oder Ähnlichem das schrittweise zu verbessern, um diese Probleme zu reduzieren. Das kriegt man alles nicht geschenkt, leider.
Ein weiterer Schritt ist, die Pläne gründlicher zu reviewen und stärker Fokus darauf zu legen, gute Pläne zu erstellen, damit die Pläne reibungsloser abgearbeitet werden können. Und halt, wenn man wirklich zu diesen Context-Switches kommt: das ist tatsächlich zumindest für mich sehr, sehr schwierig, da schnell genug zu switchen und zu verstehen. Und tatsächlich für mich ist es genau, wie du gesagt hast, Daniel: ich muss dann gucken – was hat die KI gemacht, was hat sie gerade in einem 300-Zeilen-Print mir hingeworfen? Und das kostet dann auch Zeit und Nerven, weil gefühlt ist man dann nur am Context-Switchen, wenn man diesen initialen Hub an CLAUDE.md-Anpassen noch nicht gemacht hat. Zumindest ich, wenn ich versuche mehrere Agenten zu verwenden in einem Projekt, das ich nicht so gut kenne – habe da initial auf jeden Fall größere Schmerzen erlebt.
Jochen: Ja, also es kann einen schon irgendwie gefühlt unter Stress setzen. Man denkt die ganze Zeit, es sind irgendwelche Agenten und die warten nur auf Feedback, wie es weitergehen kann. Ein Rezept, wo ich mir dagegen beholfen habe, war tatsächlich – weil es in dieser Migrationsphase, wie ich vorhin schon mal genannt hatte, gerade in der Persistenzschicht doch einige Probleme gab –: gesagt, er sollte jetzt mal in einer issues.md-File aufsammeln und dann sozusagen drumherum schiffen, wenn er andere Sachen einfach weitermachen kann – erstmal nur die Problempunkte sozusagen aufsammeln und dann sozusagen später mit mir en bloc durcharbeiten.
Also ganz am Anfang war ich auch sehr iterativ oder inkrementell mit dem KI-Agent unterwegs: das war wirklich so in dem Chat die ganze Zeit, und in wenigen Sekundentakt dauernd kommt irgendwas und muss wieder irgendwas antworten hin und her. Und das ist dann auch die Kunst oder das Learning: wie komme ich dann in den Modus, wo ich ihn halt doch über längere Zeiträume möglichst autark laufen lassen kann, ohne dass er sonst wohin die Reise geht – sondern am Ende möglichst genau das Ergebnis rauskommt, das ich mir erhoffe. Eben durch genaue Spezifikationen, oder wie es der Florian gesagt hat, ganz wichtig: dass ich mehr über die Zeit auch mehr und mehr Regelwerk und Constraints in der CLAUDE.md oder AGENTS.md reinschreibe, die einfach dem LLM, dem Modell, auch helfen, sich an die Richtlinien und die Regeln zu halten, die ich in meiner Codebase, in meinem Team verankert haben möchte.
Ich sage nicht, dass es nicht möglich ist – also das erlebe ich gerade auch seitdem, seitdem wir da weitermachen. Ich denke, das Learning: da geht einiges voran, das wird immer besser und das bringt wirklich was. Aber wie es der Florian auch wieder gesagt hat: dass auch die Kunst „viel hilft viel” – also auch da wieder sozusagen nur das Nötigste, das Essentielle und den Kontext immer überschaubar halten. Man könnte natürlich sagen: die Zeit spielt für uns, weil die Modelle einfach mit immer mehr Kontext mit der Zeit auch arbeiten können – oder selber sich die Fähigkeit aneignen werden, den immer wieder zu kondensieren, zu konzentrieren auf das Elementare. Ich glaube, in die Richtung geht da die Entwicklung ganz klar hin. Sei es der neueste „Insights”-Befehl und einfach, dass sie versuchen Langzeit-Memory bei allen Modellen aufzusetzen, und dann immer wieder zusammenzufiltern: was ist jetzt elementar für die Arbeit, die ich gerade brauche.
Sehr spannend, aber ein Schritt, der ja noch im Entstehen ist, wo wir da angefangen hatten – mit den Skills in den verschiedenen Tools. Ich denke, das hilft auch sehr, dass man sozusagen wie so ein Nachschlagewerk – Experte für genau das und das Problem oder die Technologie – und immer nur bei Bedarf und dem Ansatz dazu schaltet.
Verwendete Modelle
Florian: Vielleicht als Referenz für die Hörer: wir haben Claude Sonnet und Claude Opus und OpenAI 5.1 (glaube ich) verwendet, hauptsächlich.
Daniel: Das war dann wahrscheinlich Sonnet und Opus 4.5 – also 4.5, weil 4.6 kam ja jetzt vor kurzem raus.
Florian: Genau, genau. Und zeitweilig am Anfang auch noch Gemini 2.5 Pro/Flash.
Erfahrung von Softwareentwicklern im KI-Zeitalter
Daniel: Ihr hattet ja vorhin ganz am Anfang erwähnt, dass ihr ja beide schon einige Jahre auf dem Buckel habt als Softwareentwickler und auch die ganze Zeit auch ohne KI – oder lange Zeit ohne KI-Unterstützung – gearbeitet habt. Inwieweit hilft euch eure Erfahrung aktuell mit dem Einsatz von KI-Tools, jetzt auch bei KI-Migration, um da halt mit effektiv umzugehen? Weil so KI ist ja ein Tool, was immer so versprochen wird: das kann jeder, alles mitmachen. Da würde mich halt eure Erfahrung und eure Einsichten auch mal interessieren.
Jochen: Okay, ich fange mal kurz an. Also zum einen: das, was man halt über viele langjährige Erfahrungen in Software-Engineering – auch mit einem gewissen Qualitätsanspruch – hat, ist, dass nicht jeder Code gleich gut ist, der jetzt irgendein Problem löst. Sondern ich denke, da haben wir einiges an Expertise vorzuweisen, zu begutachten. Das machen wir auch immer wieder bei Kunden, wo wir auf Zuruf das mal durchleuchten – messen mit Tools, statische Codeanalyse und so: wie sieht es in dem System aus, wie ist die Softwarequalität? Weil das auch, denke ich, eine langjährige Erkenntnis ist, die hoffentlich überall am Markt vertreten oder bekannt ist: wenn ich ein System einfach immer wieder weiterentwickle und nicht auch aktiv in qualitätsverbessernde oder -erhaltende Maßnahmen reininvestiere, erodiert das. Die Systemarchitektur, die Softwarequalität im Kleinen über die Zeit – und man kommt dann irgendwann in die Wartungshölle, dass man nur noch in Bugs ertrinkt und einfach jedes neue Feature schon beliebig teuer wird.
Altbekannte Weisheiten – und das sehe ich halt im Moment nicht, dass man sagen kann: jetzt habe ich die KI, und alle diese Erkenntnisse über Softwaresysteme und welche Gesetzmäßigkeiten es gibt, die gibt es nicht mehr, ich kann also auf die Qualität pfeifen. Da kommt man dann in der Ecke raus, wo oft gerne als Schimpfwort genutzt wird, also „KI-Slop” – rauskommt –, oder anders: von denen, die total fachfremd sind und kein Informatik- oder Software-Engineering-Know-how haben, der Vibe-Coding wird dann gefeiert. Ja, es ist toll – und mag für manche Anwendungsfälle auch durchaus hinreichend sein. Wenn ich sage, ich brauche irgendwie nur eine kleine App oder eine kleine Marketing-Webseite, die ist ein paar Monate live und dann kann ich sie wegwerfen: ja, so what, dann ist es vielleicht genau das Mittel der Wahl. So wie auch damals schon viele Fachbereiche immer wieder irgendwas sich in Excel zusammenschustern oder sonst wie – es ist ein Tool, ein Hilfsmittel.
Aber wenn ich wirklich Enterprise-Systeme habe, die dann vielleicht Jahre oder Jahrzehnte laufen sollen und extrem geschäftskritisch wichtige, sensible Daten haben, dann spielt der Qualitätsaspekt halt doch wieder eine Rolle. Oder sei es – ich will gar nicht so sprechen von Kraftwerken, medizinischem Bereich und sonst wie, da darf ich mir keine Fehler erlauben, „jo, Medizin war jetzt halt falsch zusammengemixt, schade drum”. Also es gibt Bereiche, da ist die Qualität essentiell wichtig. Und ich denke, da haben wir einfach durch die langjährige Expertise wie wir Software-Systeme – in Anführungszeichen jetzt noch klassisch, manuell – so bauen, dass sie genau diese Kriterien erfüllen: Korrektheit, Wartbarkeit, dass sie langlebig laufen können und auch auf der anderen Seite immer noch verständlich sind für die Menschen. Weil es kann ja auch wunderbar korrekt sein, aber wie halt Kraut und Rüben, Spaghetti-Code – also wie strukturiere ich große Probleme in kleinen Einheiten, dass sie verständlich bleiben?
Und genau diese ganzen Qualitätsansprüche sehe ich auch im Zeitalter von KI immer noch. Weil wenn wir das aus der Hand geben – das gibt ja manche Vertreter oder Verfechter, die sagen: okay, ich kann den Code irgendwie generieren, den muss ja gar kein Mensch mehr lesen können, das reicht, wenn irgendeine KI das versucht noch zu verstehen – ich würde ein klares Veto dagegen setzen. Also es gibt auch Haftungsfragen. Also irgendwann, am Ende des Tages, ist es schon wichtig, dass wir da auch noch die Kontrolle behalten über das, was da rauskommt. Wenn es noch in dieser Form Code ist, in den üblichen Sprachen, mit denen wir es zu tun haben, dann gilt bis dato – und das ist eine Banalität – so wurden die LLMs meistens auch trainiert, auf menschlichen Daten, auf menschlichem Code, menschlichen Schriftwerken. Das heißt, sie sind gut auf genau dem, was menschenlesbar und verarbeitbar ist, zu arbeiten. Und dann sollten wir dieses Qualitätsgut auch genau auf diesem Level halten, dass sowohl die KI das gut verarbeiten kann, aber auch der Mensch es noch gut verarbeiten und nachvollziehen kann.
Florian: Was ich da noch ergänzen würde ist: genau wie Jochen gesagt hat, halt klassische Qualitätskriterien in der Softwareentwicklung – wie zum Beispiel, dass Code veränderbar ist, ohne dass die ganze Codebase verändert werden muss – sind natürlich auch für Agents immer noch wichtig.
Zusätzlich zu dem Qualitätsanspruch würde ich noch gerne hinzufügen, dass bei – also ich sehe den auch als Hauptaspekt, diesen Qualitätsanspruch, das ist aus meiner Sicht entscheidend – ein zweiter, ein bisschen weniger wichtiger Punkt ist auch, dass die KI bei dem Erstellen von Migrationsplänen noch Probleme hat. Insbesondere wenn es darum geht: wie mache ich eine Migration schrittweise, wie nehme ich die Migration schrittweise live, wie gehe ich mit unsauberen Datenbankzuständen um – zum Beispiel, wenn man eine nicht-relationale Datenbank im Einsatz hat und Daten keinen konsistenten Stand haben. Das sind alle Sachen, die fallen der KI schwer, weil die nicht Standard sind. Und man muss halt in der Migration diese ganzen kleinen, nervigen Details berücksichtigen und auch der KI entsprechend prompten – oder selbst sich Lösungen überlegen, wie man mit diesen kleinen Details umgeht, und insgesamt einen Migrationsplan erstellen, der trägt, der schrittweise funktioniert. Genauso wie heute auch schon: Big-Bang-Migrationen haben einfach insgesamt ein großes Risiko, dass während der Projektlaufzeit – ich sag mal in Anführungszeichen nach den ersten zwei Jahren – wird das Projekt gezippt und kommt nicht live, und dann war die ganze Arbeit umsonst.
Wenn man es schafft, die Arbeit in kleinere Schritte zu unterteilen, die man schrittweise live nehmen kann und auch dort einen guten und soliden Plan hat, wie man die ganzen Umsysteme, Datenbanken und so weiter mitnimmt und alles immer stabil hält, dann wird eine Migration zu einem Erfolg. Und ja: die KI kann in dem Code-Bereich viel, aber das ist nicht alles bei einer Migration. Dieser ganze Rahmen, wie in der Organisation die Migration umgesetzt werden kann, gehört auch dazu – und diese Informationen zu kennen und zusammenzutragen, da sind gute Entwickler entscheidend, da sind Menschen entscheidend, die die Firma kennen und verstehen, welche Möglichkeiten und Optionen es gibt.
KI-Tooling beim Kunden
Daniel: Jochen, du hast jetzt auch ein paar Mal erwähnt, dass du ja beim Kunden auch schon quasi KI-Tooling einsetzt. In welchem Ausmaß ist das? Weil vieles, was wir jetzt darüber gesprochen haben über diese Experimente – das war ein, sagen wir mal, geschützter Rahmen. Aber in dem Projekt wirst du jetzt nicht einfach etwas machen, was dann nicht direkt produktiv geht – also wirklich an aktiven Projekten arbeiten: wie ist denn da der Umgang? Und auch gerne Florian, falls du da aktuelle Einsichten hast, weil das ist auch, glaube ich, super spannend.
Jochen: Na gut, also man merkt: da ist auf jeden Fall was in Bewegung, und eigentlich alle, die Kunden oder Unternehmen, sind einfach am Ball, würde ich jetzt mal behaupten. Im Vorjahr – Ende letztes Jahr – da war der Stand der Dinge noch, dass man Microsoft Copilot – ich will jetzt nicht werten, gut oder schlecht, sondern das ist einfach oft vertreten; ich denke, das ist einfach regulatorisch und auf der rechtlichen Seite überschaubar auf dem Risiko und so weiter, und die geben auch ziemlich große Versprechen ab, was sie alles nicht tun und woran sie sich halten.
Da ist man auf der anderen Seite ein bisschen weiter, zum aktuellen: kann ich im Projekt gerade auch Claude Code einsetzen, das die aber selber sozusagen dort hosten in einer Cloud-Umgebung. Und das ist natürlich schon ganz nett, weil es so von dem Tooling, wo man dran ist, gefühlt so ziemlich State of the Art ist. Da habe ich nur beobachtet – ich habe jetzt gedacht, jetzt war ich ja bei dem Migrationszeug KI-only, so fast alles der KI überlassen –, und jetzt ist es wieder so ein Gemischt-Modus, wo ich auch viel manuell wieder mache. Warum eigentlich?
Und da kam ich irgendwie auf den Schluss: wenn es gewisse kleine Sachen gibt in der Bestands-Codebase, wo ich jetzt eine Änderung machen soll – wenn es dann so ein Grenzteil wird, wo allein um zu beschreiben oder zu prompten, was gerade zu tun ist, wenn das so viel Zeit für mich dauert, wie wenn ich es einfach mache, dann switche ich sozusagen wieder zum manuellen klassischen Coding. Aber wenn es etwas ist – genau die Geschichten, wo ich die Stärken jetzt schon erlebt und gefühlt habe, wo es repetitiv wird und „jetzt muss noch die x anderen Stellen da anfassen”, nee, dann setze ich mich natürlich hin, spendiere die Zeit und sage: das prompte ich doch schnell mal, dass das die KI für mich übernimmt, das ist mir viel zu doof, diese wiederholende Tätigkeit da selber zu machen. Und so bereichert sozusagen, anreichert es meinen Arbeitsalltag jetzt aktuell.
Florian: Ja, ich habe leider noch nicht das Vergnügen.
Schlussworte
Daniel: Sehr schade. Aber dann würde ich mal sagen an dieser Stelle erstmal vielen Dank – das sind sehr große Einblicke. Habt ihr noch irgendetwas, was ihr den Leuten da draußen noch mitgeben wollt, das bis jetzt noch nicht zur Ansprache kam? Dann fühlt euch jetzt frei, das mitzuteilen.
Jochen: Ja, ich habe vielleicht noch ein, zwei Dinge, die mir gerade durch den Kopf gegangen sind, auch wo ich das gerade so resümiert hatte. Also zum einen finde ich, das ist eine total spannende Zeit. Also irgendwie die letzten Jahre hatten wir so das Gefühl: ja, kommt Framework XY, aber irgendwie „im Westen nichts Neues” – und jetzt mit den KIs, da verändert sich auf einmal alles extrem fundamental. Nochmal so unsere ganze Arbeitsweise: alles wird hinterfragt, auf den Prüfstand gestellt und wird sich ändern. Wir sind mitten in dem großen Change-Prozess, der ganz viel – das kann man überhaupt noch nicht überschauen –, es geht ja nicht nur in der Softwareentwicklung, es ist die gesamte Gesellschaft, die gesamte Industrie wird davon erfasst und ergriffen, dass sich da alles ändern wird.
Auf der anderen Seite finde ich es auch total spannend – ich bin so ein bisschen Sci-Fi-Fan – und ja, man lebt sozusagen in dem Zeitalter, wo jetzt vieles, was sich aus der Zeit erträumt wird, jetzt plötzlich Realität wird. Aber man sollte natürlich auch reflektiert damit umgehen: es ist nicht alles nur eine schöne neue Welt, sondern die Risiken und Nebenwirkungen irgendwie auch steuern – also das im guten Sinne und versuchen, die schlechten Auswüchse auch zu kontrollieren, gerne auch zu reglementieren. Obwohl Europa vielleicht manchmal ein bisschen zu sehr auf den Bremsklotz tritt, ja – aber damit den richtigen Umgang zu finden und das nicht einfach nur schalten und walten lassen.
Aber ich denke auch für uns in der Entwicklung sind das total spannende Zeiten, wo ich also wirklich da jedem nur raten kann: beschäftigt euch damit, jetzt ist auch die Zeit, wo diese Modelle, diese agentic Tools was taugen, die spucken nicht Quatsch aus, sondern da kommt sehr viel guter Code bei raus, die können einen toll bei der Arbeit unterstützen – und das geht ja noch da und weiter, wird immer besser. Und sich auf diesen Change-Prozess einlassen und zu finden: okay, wo ist mein neues Rollenbild? Das wird sich auch verschieben. Also die KI wird ja viel mehr das Coding übernehmen, auf der anderen Seite brauche ich trotzdem diese Engineering-Skills: richtig anzuleiten, zu kontrollieren, zu steuern, zu reviewen, was sie macht, und das große Ganze zu sehen. Also diese Kapazität hat sie zumindest dann heute noch nicht – auch bei zum Beispiel Migrationsprojekten oder sei es bei vielen dieser menschlichen Komponente, die Interaktion, das ist der Gesamtplan, die Gesamtsicht. Sondern sie ist gut in Dinge abarbeiten, wie eine fleißige Arbeitsbiene.
Florian: Genau, dem kann ich mich auch nur anschließen. Ich möchte nochmal appellieren, dass die Einstiegshürde, KI zu verwenden, sehr niedrig ist. Es ist wirklich in Claude Code den Plan-Mode zu verwenden, die KI einen Plan erstellen zu lassen und die KI den Plan ausführen zu lassen, und viele Befehle zu bestätigen. Man braucht nicht viel Know-how, um mit dem Thema anzufangen. Und dann kann man sich schrittweise mit den Details und den tieferen Themen, um die es in dem Podcast heute auch ging, beschäftigen und sich dort wirklich schrittweise reinwagen. Und diese erste Stufe ist wirklich sehr niederschwellig – ich würde sagen, viel niederschwelliger als alles, was ich in der Softwareentwicklung bisher gesehen habe, viel leichter als eine neue Programmiersprache oder ein neues Framework lernen. Der Einstieg wird einem hier wirklich sehr leicht gemacht. Und wie Jochen auch gesagt hat: es ist einfach unglaublich, was man erreichen kann. Und ich möchte einfach nur nochmal sagen: traut euch und nutzt die Chance, die neuen Möglichkeiten aktiv zu benutzen und die Zukunft, wie ihr Technologie verwendet und Technologie entwickelt, aktiv zu gestalten.
Daniel: Dann vielen Dank euch für die ermutigenden Worte – auch mit dem Thema, sich KI aktiv auseinanderzusetzen und auch das für größere Migrationsprojekte (in dem Fall dieses Themas jetzt dieser Folge) auch einzusetzen. Falls ihr Hörer da draußen noch irgendwie Fragen oder auch Feedback oder Anregungen für zukünftige Folgen habt, schreibt uns gerne eine E-Mail an podcast-feedback@andrena.de. Und damit war es für diese Folge: vielen Dank und tschüss.
Jochen: Vielen Dank. Tschüss.
Florian: Dankeschön. Tschüss.