KI-gestützte Migrationen und großflächige Änderungen

Migrationen und großflächige Änderungen

0:00 Dieses Modul behandelt die Disziplin, in der agentische Werkzeuge am meisten leisten — und am meisten anrichten können. Eine Bibliothek ablösen, ein Muster über dreihundert Stellen ändern, ein Framework austauschen: Das ist genau die Arbeit, für die man früher Wochen veranschlagt hat und die heute technisch in Stunden machbar wäre.

0:18 Das Wort technisch ist hier entscheidend. Denn was in Stunden entsteht, muss immer noch von Menschen geprüft werden — und daran hat sich nichts geändert. Wie man diese Spannung auflöst, ist das Thema der nächsten Kapitel.

KI-gestützte Migrationen und großflächige Änderungen

0:31 Der Ablauf folgt der Reihenfolge einer echten Migration. Erst die Inventur — und dabei die wichtigste Erkenntnis, dass nicht die Zahl der Fundstellen zählt. Dann das Zielmuster, das Sie von Hand erarbeiten. Dann die Aufteilung zwischen Werkzeug und Agent. Dann die Stapel, in denen gearbeitet wird, und eine Zahl, die den Fortschritt beantwortet. Danach die Übergangsschichten und ihr Rückbau, der so oft unterbleibt.

0:56 Und zum Schluss zwei Eigenschaften, die eine Migration beherrschbar machen. In der Übung lösen Sie die Datumsbibliothek ab.

Inventur vor der ersten Änderung

1:04 Fangen wir mit der Bestandsaufnahme an. Und gleich mit der Erkenntnis, die die Aufwandsschätzung solcher Vorhaben grundlegend verändert. Großflächige Änderungen scheitern selten an der einzelnen Umstellung. Sie scheitern daran, dass der Umfang unbekannt war. Deshalb steht vor dem ersten Eingriff die Inventur: Wo überall wird das Abzulösende verwendet, und — das ist der wichtigere Teil — in welchen Ausprägungen?

1:29 Die meisten Teams beantworten nur die erste Hälfte. Sie zählen Fundstellen, tragen eine Zahl in den Plan ein und merken in Woche drei, dass diese Zahl nichts über den Aufwand gesagt hat. Hier ist die Rechnung, die man sich merken sollte: Vierhundert gleichartige Aufrufe sind eine mechanische Aufgabe von zwei Stunden. Vierzig Aufrufe in zwölf verschiedenen Verwendungsmustern sind ein Projekt. Die Zahl der Fundstellen sagt also wenig, die Zahl der Muster fast alles.

1:56 Und genau hier ist ein Agent wertvoll: Er zählt nicht nur, er gruppiert. Diese Gruppierung ist das, was Sie für die Planung brauchen, und sie ist von Hand ausgesprochen mühsam. Der vierte Punkt ist die Erinnerung an Modul drei: Die dynamischen Verwendungen gehören ausdrücklich mitgesucht — sie sind die, die später überraschen.

2:16 Der erste Punkt ist die Schätzfalle von eben. Der zweite ist handwerklich und kostet regelmäßig einen halben Tag: Nur den Quelltext durchsuchen und die Konfiguration auslassen. Der dritte ist der subtilste — Varianten zusammenzufassen, weil sie ähnlich aussehen. Genau in den Unterschieden steckt die Arbeit, und wer sie in der Inventur wegglättet, findet sie in der Umsetzung wieder.

2:38 Und der vierte beschreibt die häufigste Reihenfolge in der Praxis: Man fängt an umzustellen, während die Inventur noch läuft. Danach weiß niemand mehr, was schon erfasst ist.

Zielmuster und Referenzumsetzung

2:49 Jetzt der Schritt, den ich für den wichtigsten der ganzen Migration halte. Er kostet ein bis zwei Stunden und entscheidet über den Rest — und er wird regelmäßig durch eine Beschreibung ersetzt. Bevor viel geändert wird, muss feststehen, wie das Ergebnis aussehen soll. Nicht als Beschreibung — als Code. Sie wählen zwei oder drei repräsentative Fundstellen, stellen sie von Hand um, prüfen sie gründlich und erklären sie zum Vorbild.

3:14 Das klingt nach wenig und ist der Anker für alles Weitere. Der Unterschied zu einer Beschreibung ist erheblich: Eine Beschreibung muss interpretiert werden, und zwei Menschen interpretieren sie unterschiedlich. Ein Agent übrigens auch. Zwei Gründe, und beide sind praktisch. Der erste: Fast immer stellt sich beim zweiten oder dritten Fall heraus, dass das gedachte Zielmuster einen Fall nicht abdeckt.

3:38 Diese Erkenntnis ist bei drei umgestellten Stellen billig — Sie passen das Muster an und machen weiter. Bei dreihundert umgestellten Stellen ist sie teuer. Der zweite Grund betrifft die Beauftragung: Auf umgestellten Code zu zeigen ist präziser als jede Beschreibung. „Mach es wie in diesen zwei Dateien“ lässt deutlich weniger Spielraum als drei Absätze Prosa.

3:59 Der erste Punkt ist der Kernfehler dieses Kapitels: das Zielmuster nur zu beschreiben. Der zweite ist die Sparvariante — nur einen Fall umstellen. Damit verpassen Sie genau die Erkenntnis, um derer willen der Schritt gemacht wird. Der dritte ist die Konsequenz aus Punkt eins der vorigen Folie: Wenn die erste Überraschung kommt, ziehen Sie das Muster nach und weisen Sie ausdrücklich darauf hin.

4:21 Und der vierte ist eine Auswahlfrage: Wer die drei einfachsten Fälle als Referenz nimmt, erzeugt ein Muster, das für die schwierigen nicht taugt.

Mechanisch wo möglich, generativ wo nötig

4:30 Jetzt die Aufteilung der Arbeit. Wir hatten das Thema in Modul sechs schon einmal, im Kleinen. Hier, im Großen, hat es unmittelbare Auswirkungen auf Aufwand und Prüfbarkeit. Migrationsarbeit teilt sich in zwei sehr ungleiche Hälften. Der große, gleichförmige Teil — meist achtzig Prozent oder mehr — lässt sich mit strukturbewussten Werkzeugen erledigen.

4:52 Der kleine, sperrige Rest verlangt Urteilsvermögen und ist damit die Domäne des Agenten. Diese Aufteilung ist keine Prinzipienfrage, sondern eine Rechnung: Der mechanische Teil wird schneller und sicherer erledigt, und Ihre Prüfaufmerksamkeit bleibt für die Fälle übrig, in denen tatsächlich entschieden wurde. Die erste Zeile nennt das klassische Werkzeug: Codemods, die auf dem Syntaxbaum arbeiten.

5:15 Deterministisch, reproduzierbar, beliebig wiederholbar — dieselben Eigenschaften wie beim Werkzeug-Refactoring aus Modul sechs. Die zweite Zeile nennt einen Trick, der oft übersehen wird: Markieren Sie das Alte als veraltet und folgen Sie den Fehlern des Übersetzers. Der wird dann zu Ihrer Arbeitsliste, und er vergisst nichts.

5:35 Die dritte Zeile ist die Domäne des Agenten: ungewöhnliche Verwendung, Zusatzlogik, Kommentare, die mitgedacht werden müssen. Die Fußzeile nennt den doppelten Gewinn dieser Trennung. Der erste Punkt ist der häufigste, und er ist verständlich: Es fühlt sich flüssiger an, alles im Gespräch zu erledigen. Der zweite ist die Gegenrichtung — Codemods für zwölf Fundstellen zu schreiben lohnt nicht, da ist der Agent schneller. Die Grenze liegt irgendwo bei einigen Dutzend Stellen.

6:03 Der dritte ist der übersehene Trick von der vorigen Folie. Und der vierte ist praktisch wichtig: Trennen Sie mechanische und generative Anteile in verschiedene Commits. Sonst müssen Sie den mechanischen Teil mit derselben Sorgfalt prüfen wie den generativen — und der ganze Vorteil ist weg.

Stapelgröße und Reihenfolge

6:20 Jetzt die Frage, in welchen Portionen gearbeitet wird. Und die Antwort hat nichts mit technischer Machbarkeit zu tun, sondern allein mit Prüfbarkeit. Wer dreihundert Fundstellen in einem Zug ändern lässt, bekommt einen Patch, den niemand prüft. Nicht weil das Team faul wäre — es ist schlicht nicht leistbar. Und damit ist die Migration unkontrolliert, unabhängig davon, wie gut sie technisch gelungen ist. Die Arbeit gehört also in Stapel.

6:47 Die Schnittkriterien sind meist naheliegend: nach Modul, nach Schicht, nach Verwendungsmuster. Ein Stapel wird umgestellt, geprüft, festgeschrieben — und dann kommt der nächste. Der interessanteste Ratschlag steckt in Schritt vier und in der Fußzeile: Nehmen Sie die riskanteste Stelle weder zuerst noch zuletzt. Nicht zuerst, weil das Verfahren noch nicht erprobt ist und Sie dort keine Lernfehler machen wollen.

7:11 Und nicht zuletzt, weil am Ende der Zeitdruck am größten ist und die Aufmerksamkeit am geringsten. Das ist ein Muster, das für viele Vorhaben gilt und selten ausgesprochen wird. Die Schritte eins und zwei sind der Lerneffekt: Fangen Sie klein und gut abgesichert an, damit die ersten Fehler billig sind. Der erste Punkt ist ein häufiger Schnittfehler: Stapel nach Dateigröße statt nach Verwendungsmuster. Dann prüfen Sie in jedem Stapel wieder dieselben Sonderfälle.

7:38 Der zweite beschreibt eine Situation, die mit agentischer Arbeit leichter entsteht als früher — mehrere Stapel gleichzeitig offen, weil es ja so schnell geht. Der dritte ist der Ehrgeiz: den größten Stapel zuerst, um schnell voranzukommen. Und der vierte ist Hygiene: Nach jedem Stapel committen, sonst verlieren Sie den Rückweg, den die ganze Aufteilung erst herstellt.

Fortschritt messbar machen

8:00 Eine Migration über Wochen braucht eine Zahl, die den Stand beantwortet. Und dieselbe Zahl liefert nebenbei den wirksamsten Schutz gegen die Migration, die nie endet. Ohne eine solche Zahl wird jede längere Migration zum Fass ohne Boden — und zwar nicht nur gefühlt. Man kann tatsächlich nicht sagen, ob man bei dreißig oder bei achtzig Prozent steht.

8:21 Die brauchbarste Größe ist automatisch ermittelbar: Wie viele Fundstellen des alten Musters gibt es noch? Das ist ein Suchlauf, den Sie in die Pipeline hängen können. Und dann wird die Sache interessant, denn eine Zahl in der Pipeline kann mehr als messen. Der entscheidende Punkt ist der zweite: Die Zahl kann verhindern, dass neue Fundstellen hinzukommen.

8:42 Ohne diese Sperre haben Sie ein Rennen — vorne wächst nach, was hinten abgearbeitet wird, und je größer das Team, desto aussichtsloser. Ich habe Migrationen gesehen, die über ein Jahr liefen und am Ende bei derselben Zahl standen wie am Anfang. Eine Regel, die das alte Muster in neuem Code verbietet, kostet fast nichts und beendet dieses Rennen. Sie ist damit die wirksamste Einzelmaßnahme in diesem ganzen Modul.

9:06 Die erste Liste ist die Zahl von eben — automatisch ermittelt, jederzeit abrufbar. Die zweite wird fast immer vergessen und ist genauso wichtig: die bewusst nicht migrierten Fälle, mit Begründung. Es gibt sie in jeder Migration — generierter Code, ein Bereich, der ohnehin stillgelegt wird, eine Stelle, an der das Zielmuster nicht passt.

9:26 Ohne diese Liste bleibt am Ende ein Rest von siebzehn Fundstellen übrig, und niemand weiß, ob die vergessen wurden oder Absicht waren. Dann prüft das jemand ein zweites Mal.

Übergangsschichten und ihr Rückbau

9:36 Während der Umstellung existieren beide Welten nebeneinander, und meist braucht es etwas, das dazwischen vermittelt. Diese Schicht ist nützlich und gefährlich zugleich — und der gefährliche Teil zeigt sich erst Jahre später. Ohne diese Schicht könnten Sie gar nicht schrittweise umstellen — sie ist die Voraussetzung dafür, dass alte und neue Welt gleichzeitig funktionieren. Insofern ist sie richtig.

10:00 Das Problem ist nicht ihre Existenz, sondern ihre Lebensdauer. Sie entsteht mit einem klaren Zweck und bleibt, weil der Rückbau nichts Sichtbares bringt und immer etwas Dringenderes ansteht. Nach drei Jahren weiß niemand mehr, wofür sie da war — nur dass man sie nicht anfassen sollte. Der erste Punkt beschreibt ein Bild, das Sie in älteren Systemen tatsächlich finden: drei Generationen von Übergangsschichten übereinander.

10:24 Jede stammt aus einer Modernisierung, die begonnen und nicht abgeschlossen wurde. Das ist das eigentliche Erbe abgebrochener Vorhaben — nicht der alte Code, sondern die Zwischenschichten. Und der dritte Punkt ist der Grund, warum es sich verschärft: Jede Schicht macht die nächste Modernisierung schwerer, weil man sich erst durch sie hindurcharbeiten muss, bevor man an die Fachlichkeit kommt.

10:46 Die Gegenmaßnahme muss an den Anfang, denn später fehlt der Anlass. Schritt eins und zwei sind schnell erledigt: Zweck festhalten und benennen, woran erkennbar ist, dass die Schicht nicht mehr gebraucht wird. Schritt drei macht daraus etwas Belastbares — null verbleibende Fundstellen ist ein Messwert, kein Vorsatz. Und Schritt vier ist der organisatorische Punkt: Der Rückbau gehört als eigener Arbeitsschritt in die Planung, nicht in die guten Absichten.

11:12 Die Fußzeile bringt es auf den Punkt: Ein Nachweis hält der Zeit stand. Ein Vorsatz hält bis zum nächsten dringenden Thema.

Umkehrbarkeit und Wiederholbarkeit

11:20 Zum Abschluss zwei Eigenschaften, die eine Migration beherrschbar machen. Die erste kennen Sie schon. Die zweite ist bei generativer Arbeit nicht selbstverständlich — und das hat Konsequenzen. Umkehrbarkeit heißt: Für jeden Stapel gibt es einen Weg zurück. Wiederholbarkeit heißt: Ein Migrationsschritt, zweimal ausgeführt, liefert dasselbe Ergebnis.

11:41 Die zweite Eigenschaft klingt akademisch und nimmt der Sache im Alltag den Schrecken — denn ein abgebrochener oder unvollständiger Lauf ist dann kein Problem, Sie wiederholen ihn einfach. Ohne sie ist jeder Abbruch mitten in einem Stapel eine kleine Krise, weil Sie erst feststellen müssen, was schon passiert ist. Die ersten beiden Zeilen betreffen die Umkehrbarkeit, und die Botschaft kennen Sie aus Modul drei: Bei Datenänderungen ist der Rückweg aufwendiger als ein Rücksprung im Code und will vorher erprobt sein.

12:10 Die letzten beiden betreffen die Wiederholbarkeit — und die vierte ist die unangenehme: Bei generativer Umstellung ist sie nicht selbstverständlich. Zwei Läufe desselben Auftrags liefern nicht zwangsläufig dasselbe. Das ist kein Mangel, sondern eine Eigenschaft dieser Werkzeuge, und die Fußzeile zieht daraus den Schluss: ein weiteres Argument, den mechanischen Teil mechanisch zu erledigen.

12:32 Daraus folgt eine praktische Regel für die generativen Anteile: Was einmal entstanden und geprüft ist, wird festgeschrieben — als Commit, nicht als Auftrag, den man bei Bedarf noch einmal ausführt. Der dritte Punkt nennt den Grund: Wenn Sie es neu erzeugen lassen, ist es nicht mehr dasselbe Ergebnis, und Ihre Prüfung gilt nicht mehr.

12:51 Der vierte Punkt zieht die Konsequenz für die Dokumentation: Die Referenz ist der Commit, nicht der Prompt. Der Prompt kann in der Notiz stehen, aber verbindlich ist, was im Repository liegt.

Übung: Eine Bibliothek in mehreren Varianten ablösen

13:02 In der Übung lösen Sie die veraltete Datumsbibliothek des Fahrtenbuchs ab. Und Sie werden bei der Inventur eine Erfahrung machen, die für dieses Modul typisch ist. Die Fundstellen verteilen sich über Buchung, Abrechnung, Export und Berichte — und sie sehen unterschiedlich aus. Mal wird nur formatiert, mal gerechnet, mal mit Zeitzonen hantiert, mal ein Datum aus Text erzeugt.

13:24 Genau das ist der Punkt: Erwarten Sie mehr Varianten, als die Zahl der Stellen vermuten lässt. Und behandeln Sie die Liste der bewusst nicht migrierten Fälle als Teil des Ergebnisses, nicht als Eingeständnis. Wer am Ende sagen kann, warum drei Stellen so bleiben, hat eine bessere Migration abgeliefert als jemand, der bei null Fundstellen steht und es nicht erklären kann.

13:46 Nehmen Sie sich für Schritt eins und zwei mehr als die Hälfte der Zeit — dort entsteht der Wert. Schritt drei ist die Aufteilung: Bestimmen Sie ausdrücklich, welcher Anteil mechanisch geht und welcher den Agenten braucht, und begründen Sie die Grenze. In Schritt vier arbeiten Sie in Stapeln mit Commit nach jedem. Und Schritt fünf ist der, der über das Seminar hinauswirkt: eine Fortschrittszahl, die zugleich verhindert, dass neue Fundstellen entstehen.

14:11 Halten Sie zum Schluss fest, welche Fälle bewusst bleiben — und woran man das in einem Jahr erkennen soll.