KI-gestützte Code Archaeology

KI-gestützte Code Archaeology

0:00 Archäologie ist ein treffendes Bild für das, was in diesem Modul passiert. Sie graben in einem System, dessen Erbauer nicht mehr da sind, finden Artefakte ohne Beschriftung und müssen aus Spuren rekonstruieren, welche Absicht dahintersteckte. Der Unterschied zur richtigen Archäologie: Ihr Fundstück läuft noch, jeden Tag, in der Produktion. Neu ist, dass Sie dabei nicht mehr allein sind.

0:22 Das Lesen fremden Codes war immer der teuerste Teil der Wartungsarbeit — und genau dieser Teil ist gerade sehr viel billiger geworden. Was das praktisch bedeutet und wo die Grenzen liegen, schauen wir uns in den nächsten Kapiteln an.

KI-gestützte Code Archaeology

0:35 Der Weg durch dieses Modul folgt der Reihenfolge, in der man auch praktisch vorgeht. Erst die nüchterne Bestandsaufnahme: Wie ist das Projekt geschnitten, baut es überhaupt, gibt es Tests? Dann die eigentliche Erkundung entlang eines konkreten Vorgangs. Dann die Suche nach den Geschäftsregeln und ein Blick in die Versionshistorie, die fast immer übersehen wird.

0:56 Und zum Schluss die Frage, die über allem steht: Wie unterscheide ich, was ein Agent belegt hat, von dem, was er vermutet? Am Ende erstellen Sie ein Systemprofil — auf zwei Seiten, mit gekennzeichneten Aussagen.

Erst verstehen, dann verändern

1:09 Beginnen wir mit einem Grundsatz, dem alle zustimmen und den unter Zeitdruck fast alle brechen. Interessant ist nicht, dass er gilt — interessant ist, dass sich das Kosten-Nutzen-Verhältnis dahinter gerade verschoben hat. Warum wird dieser Grundsatz so zuverlässig verletzt? Weil Verstehen sich nicht nach Fortschritt anfühlt. Nach drei Stunden Lesen können Sie im Standup nichts vorweisen.

1:32 Nach drei Stunden Programmieren schon. Der Preis für die Abkürzung ist immer derselbe: die Änderung, die an der falschen Stelle ansetzt, weil die eigentliche Regel woanders lag. Agentische Werkzeuge verschärfen die Versuchung — sie legen Ihnen innerhalb von Sekunden etwas vor, das einsatzfähig aussieht. Und sie liefern zugleich das Gegenmittel.

1:52 Beides gehört zusammen, und welches von beidem Sie nutzen, entscheiden Sie. Hier steckt die eigentliche Neuigkeit dieses Moduls. Früher war die Abwägung echt: Erkundung kostete Tage, und man konnte mit guten Gründen sagen, dafür ist keine Zeit. Diese Abwägung gibt es nicht mehr. Erkundung ist rein lesend, sie verändert nichts, sie braucht keine Schreibrechte, und sie kostet inzwischen Minuten statt Tage.

2:17 Damit fällt das letzte praktische Argument gegen das Verstehen weg. Wer heute ohne Erkundung ändert, spart deutlich weniger als früher — und riskiert genau dasselbe. Das ist keine moralische Aussage, sondern eine wirtschaftliche. Der erste Punkt ist der, den ich am häufigsten sehe: Der Vorschlag klingt kompetent, also übernimmt man ihn als Verständnis des Systems.

2:39 Dabei hat das Modell dieses System zum ersten Mal gesehen — was es liefert, stammt zu einem guten Teil aus der Erfahrung mit ähnlichen Systemen. Der zweite Punkt ist organisatorisch und deshalb hartnäckig: Erkundung taucht in keinem Fortschrittsbericht auf, also fällt sie weg. Und der vierte kostet Sie nichts und schützt viel: Warum sollte ein Werkzeug schreiben dürfen, das gerade nur liest?

Repository-Inventur

3:01 Fangen wir mit dem unspektakulärsten Teil an. Bevor irgendeine Frage nach Fachlichkeit gestellt wird, klären wir den technischen Rahmen — und beantworten dabei nebenbei die wichtigste Vorfrage der ganzen Modernisierung. Die Inventur ist so etwas wie der Rundgang durch ein Haus, das Sie übernehmen sollen, bevor Sie über Umbauten reden: Wo ist der Sicherungskasten, funktioniert die Heizung, gibt es einen Grundriss?

3:26 Beim Code heißt das: Schnitt, Bau, Tests, Abhängigkeiten, Konfiguration. Das ist wenig aufregend und liefert die Grundlage für alles Weitere. Vor allem beantwortet es die eine Frage, die über Ihr weiteres Vorgehen entscheidet: Existiert überhaupt ein Sicherheitsnetz? Solange die Antwort nein lautet, ist jede Diskussion über Umbauten verfrüht.

3:47 Der rote Faden dieser fünf Fragen ist eine Bewegung von außen nach innen — vom Aufbau über den Bau zu den Tests und schließlich zur Konfiguration. Achten Sie bei Frage zwei und drei auf die Formulierung: „Läuft der Bau überhaupt“ und „sind die Tests grün“ sind keine rhetorischen Fragen. Sie werden erstaunlich oft mit nein beantwortet, und dann haben Sie Ihre erste Aufgabe gefunden. Wichtig ist die Fußzeile: Fragen Sie nach Belegen, nicht nach Einschätzungen.

4:13 Nicht „gibt es Tests“, sondern „führe die Testsuite aus und zeig mir das Ergebnis“. Der Unterschied ist der zwischen einer Vermutung und einer Beobachtung. Punkt eins und zwei gehören zusammen und beschreiben denselben Fehler in zwei Schweregraden. „Es gibt eine Testsuite“ ist eine Aussage über das Repository. „Die Testsuite läuft in vier Minuten durch und ist grün“ ist eine Aussage über die Wirklichkeit. Nur die zweite hilft Ihnen.

4:39 Der dritte Punkt ist unterschätzt: Veraltete Abhängigkeiten zu zählen sagt wenig — entscheidend ist, welche davon gar nicht mehr gepflegt werden, denn nur die sind ein Sicherheitsproblem. Und der vierte: Die Inventur sagt tatsächlich nichts über die Fachlichkeit. Sie sagt Ihnen, ob Sie überhaupt arbeiten können.

Einstiegspunkte, Datenflüsse und Seiteneffekte

4:58 Jetzt beginnt die eigentliche Archäologie. Und hier entscheidet eine einzige methodische Wahl darüber, ob Sie am Ende etwas wissen oder nur etwas glauben: Verfolgen Sie einen Vorgang, oder lassen Sie sich eine Übersicht geben? Nehmen wir das Fahrtenbuch. Sie könnten fragen: „Wie ist die Architektur aufgebaut?“ Sie bekommen dann eine saubere Antwort mit Schichten und Kästchen, die vermutlich stimmt und die Sie nicht überprüfen können.

5:23 Oder Sie fragen: „Zeig mir den Weg von der angelegten Buchung bis zur Zeile in der Monatsabrechnung — Datei und Zeile für jeden Schritt.“ Das dauert kaum länger, und das Ergebnis können Sie nachlesen. Ein durchverfolgter Vorgang erklärt das System besser als jedes Diagramm, und er hat eine Eigenschaft, die einem Diagramm fehlt: Er ist überprüfbar.

5:43 Die Reihenfolge ist wichtig, und Schritt eins wird oft übersprungen: Wählen Sie einen Ablauf, der später tatsächlich geändert werden soll. Erkundung ohne Ziel ufert aus. Der Rest folgt dem Weg der Daten: Wo beginnt es, welche Schichten werden durchlaufen, wo wird Zustand verändert. Der eigentliche Ertrag steckt in Schritt vier und fünf — den Seiteneffekten. Geschriebene Dateien, versendete Nachrichten, Aufrufe fremder Systeme, alles Zeitabhängige.

6:09 Diese Stellen sind später Ihre Testpunkte, und sie sind auch die Stellen, die Sie daran hindern werden, überhaupt zu testen. Beides sollten Sie früh wissen. Der erste Punkt ist der zentrale Fehler dieses Kapitels: eine Architekturübersicht anfordern und sie für geprüft halten. Sie ist nicht falsch, sie ist ungeprüft — und der Unterschied wird erst sichtbar, wenn Sie darauf aufbauen.

6:33 Der zweite passiert aus Erschöpfung: An der Stelle, wo es unübersichtlich wird, hört man auf. Das ist meist genau die Stelle, um die es geht. Und der dritte ist tückisch: Zeitabhängigkeiten sehen wie Implementierungsdetails aus. Wir kommen im nächsten Modul darauf zurück, weil sie zu den unangenehmsten Überraschungen überhaupt gehören.

Geschäftsregeln rekonstruieren

6:53 Kommen wir zur eigentlichen Beute dieser Ausgrabung. Nicht die Architektur ist das Wertvolle an einem Bestandssystem, sondern die fachlichen Regeln, die niemand aufgeschrieben hat. Die Frage ist, wo man sie findet — und welchem Fundort man trauen kann. Im Fahrtenbuch stoßen Sie beim Lesen auf eine 3,5 in einer Bedingung zur Führerscheinklasse und auf eine 60 in der Privatnutzungsberechnung. Zwei nackte Zahlen ohne Kommentar.

7:18 Das sind Regeln — sie haben nur keinen Namen. Irgendjemand wusste einmal, warum ab sechzig Kilometern anders gerechnet wird, und dieses Wissen ist verschwunden, während die Zahl geblieben ist. Solche Stellen zu finden und zu benennen ist der erste echte Fortschritt in einem Modernisierungsvorhaben. Und zwar bevor irgendetwas geändert wird — allein das Benennen erzeugt schon Wert.

7:40 Die Reihenfolge in dieser Tabelle ist keine Zufallssortierung, sondern eine Rangfolge nach Verlässlichkeit — und sie überrascht viele. Ganz unten steht die Dokumentation. Nicht weil sie schlecht geschrieben wäre, sondern weil sie unbemerkt veralten kann: Niemand merkt es, wenn ein Wiki-Artikel nicht mehr stimmt. Ein Test dagegen kann nicht still veralten, denn er wird ausgeführt und wird rot. Deshalb ist ein Test die ehrlichste Dokumentation, die es gibt.

8:05 Und die Datenbank verrät Ihnen oft mehr über die Wirklichkeit als jedes Konzept: Was das Schema erlaubt und was tatsächlich drinsteht, sind zwei verschiedene Geschichten. Warum lohnt sich das Benennen, bevor irgendetwas umgebaut wird? Weil sich eine benannte Regel besprechen lässt. Sie können mit „gilt für Arbeitswege über sechzig Kilometer eine Sonderregelung?“ zur Fachabteilung gehen. Mit einer 60 in einer Bedingung können Sie das nicht.

8:32 Zweitens wird sie prüfbar: Was einen Namen hat, lässt sich in einen Test überführen. Drittens taucht sie im Diff auf, wenn sie sich ändert — eine namenlose Konstante rutscht unbemerkt durch. Und viertens, der praktische Punkt: Beim Umbau wandert eine namenlose Regel entweder unbemerkt mit oder verschwindet ganz.

Hotspots aus der Versionshistorie

8:52 Jetzt zu einer Informationsquelle, die in jedem Repository liegt, nichts kostet und fast nie ausgewertet wird. Sie beantwortet Fragen, an die der Code selbst gar nicht herankommt — Fragen nach der Zeit. Der Quellcode zeigt Ihnen einen Zustand. Die Historie zeigt Ihnen eine Bewegung — und Bewegung ist genau das, was Sie für Ihre Priorisierung brauchen.

9:13 Wir haben im ersten Modul festgehalten: Interessant ist der Code, der geändert werden muss. Wer das geändert werden muss abschätzen will, schaut am besten nach, was in der Vergangenheit geändert wurde. Die Auswertung ist rein mechanisch — zählen, gruppieren, sortieren. Damit ist sie eine ideale Agentenaufgabe: null Urteilsvermögen nötig, vollständig überprüfbares Ergebnis.

9:37 Diese drei Auswertungen beantworten drei verschiedene Fragen. Die erste sagt Ihnen, wo sich Investition lohnt — nämlich dort, wo der Aufwand ohne Verbesserung immer wieder anfällt. Die zweite ist die interessanteste und wird am seltensten gemacht: Welche Dateien werden auffällig oft zusammen geändert, obwohl sie fachlich nichts miteinander zu tun haben?

9:57 Das ist verborgene Kopplung, und sie ist ein starker Hinweis auf einen falschen Schnitt. Die dritte zeigt, wo das System die Entwickler regelmäßig überrascht. Beim Fahrtenbuch zeigen alle drei erwartbar auf dieselbe Stelle: die Abrechnung, jeden Jahreswechsel. Zwei dieser Punkte sind handwerklich, zwei methodisch. Handwerklich: Wenn jemand vor drei Jahren das Projekt einmal komplett durchformatiert hat, taucht danach jede Datei als Hotspot auf.

10:24 Solche Massenläufe müssen Sie herausrechnen, sonst ist die Auswertung wertlos. Methodisch wichtiger ist der erste Punkt: Die Vergangenheit ist ein Indikator für die Zukunft, aber kein Beweis. Wenn ein Bereich künftig stillgelegt wird, war er ein Hotspot und ist keiner mehr. Legen Sie die Auswertung also neben die Roadmap, nicht an ihre Stelle.

Nachweisbare Aussage gegen plausible Vermutung

10:44 Wir kommen zum wichtigsten Kapitel dieses Moduls. Alles, was Sie bisher gehört haben, hängt an einer einzigen Fähigkeit: unterscheiden zu können, was belegt ist und was vermutet. Und das ist schwerer, als es klingt. Wenn ein Mensch unsicher ist, hören Sie das. Die Stimme wird zögerlich, es kommt ein „ich glaube“ oder ein „müsste eigentlich“. Diese Signale fehlen bei einem Agenten vollständig.

11:08 Er formuliert eine Fundstelle mit Zeilennummer und eine Vermutung aus der Erfahrung mit ähnlichen Systemen im exakt gleichen ruhigen Tonfall. Und die Vermutungen sind die gefährlicheren — nicht weil sie oft falsch wären, sondern weil sie plausibel sind. Sie stammen aus der Welt der ähnlichen Systeme. Ihr System ist aber genau deshalb Legacy, weil es sich nicht so verhält, wie man erwarten würde.

11:32 Es gibt eine Kategorie von Aussagen, bei der Sie besonders wachsam sein sollten: alles, was etwas ausschließt. „Diese Funktion wird nirgends sonst verwendet“ ist der Klassiker. Zwei Dinge machen sie gefährlich. Erstens bauen darauf Löschungen auf — es ist eine Aussage mit Folgen. Zweitens, und das ist der eigentliche Punkt: Sie ist durch Lesen prinzipiell nicht belegbar.

11:55 Aufrufe über Konfiguration, über zur Laufzeit gebildete Namen, über Reflexion — die stehen nirgends im Text. Kein Leser findet sie, auch kein sehr guter. Belegen lässt sich so etwas nur durch Beobachtung. Diese fünf Schritte kosten insgesamt vielleicht zehn Minuten und verändern die Qualität Ihrer Erkundung grundlegend. Wichtig ist Schritt zwei: Öffnen Sie die Fundstelle tatsächlich. Nicht alle — Stichproben genügen.

12:21 Aber wer nie nachschaut, bekommt irgendwann Fundstellen genannt, die nicht existieren, und merkt es nicht. Schritt vier ist der Kern: Eine halbe Stunde Lesen lässt offen, was eine Protokollzeile in dreißig Sekunden beantwortet. Und Schritt fünf ist schlichte Hygiene: Was Sie nicht geprüft haben, markieren Sie als vermutet. Sonst wird es beim nächsten Lesen zur Tatsache.

Das Unknowns Register

12:44 Zum Abschluss ein Werkzeug, das aus zwei Spalten Text besteht und trotzdem den häufigsten Fehler der Modernisierung verhindert. Es hält fest, was Sie nicht wissen — und das ist wertvoller, als es klingt. Am Ende einer Erkundung haben Sie zwei Ergebnisse: was Sie herausgefunden haben und was offen geblieben ist. Das erste schreibt jeder auf.

13:04 Das zweite verschwindet — und trägt die Risiken. Das Register ist deshalb bewusst schlicht: die offene Frage, warum sie wichtig ist, und wie man sie beantworten könnte. Mehr braucht es nicht. Entscheidend ist die dritte Spalte, denn sie macht aus einem Zweifel eine Aufgabe. „Ich weiß nicht, ob sich jemand auf das Exportformat verlässt“ ist ein ungutes Gefühl. „Buchhaltung fragen“ ist ein Termin.

13:29 Schauen Sie sich an, was diese drei Beispiele gemeinsam haben: Keine davon lässt sich im Repository beantworten. Warum ab sechzig Kilometern anders gerechnet wird, steht in keiner Datei — das weiß entweder die Fachabteilung oder niemand. Ob sich außerhalb jemand auf das Exportformat verlässt, wissen die Nutzer, nicht der Code. Genau das ist die Auswahl, um die es geht.

13:51 Die Fragen, die ein Agent klären kann, klärt er sofort. Was übrig bleibt, sind die Fragen an Menschen — und die brauchen Vorlauf, weil Menschen Termine haben. Deshalb gehören sie früh auf die Liste. Hier steht der eigentliche Zweck, und er beschreibt einen Ablauf, den Sie vermutlich wiedererkennen. Eine Frage bleibt offen.

14:11 Ein paar Tage später erinnert sich niemand mehr daran, dass es eine Frage war — sie ist zu einer Annahme geworden. Wieder ein paar Tage später baut eine Änderung darauf auf. Und der Irrtum fällt erst in der Produktion auf, an einer Stelle, die scheinbar nichts damit zu tun hat. Diese Kette bricht das Register an der ersten Stelle: Was aufgeschrieben ist, bleibt eine Frage, bis jemand sie beantwortet.

Übung: Systemprofil eines unbekannten Subsystems

14:35 Jetzt bringen Sie alles zusammen. Zwei Seiten über ein Subsystem, das Sie heute Morgen noch nicht kannten — und eine Kennzeichnung, die den Unterschied macht. Zwei Seiten sind bewusst wenig. Es geht nicht um Vollständigkeit, sondern um Auswahl — Sie sollen entscheiden, was für ein anstehendes Vorhaben wirklich zählt. Die Kennzeichnung jeder Aussage als belegt oder vermutet ist der Kern der Übung und wird Sie mehr Zeit kosten, als Sie denken.

15:01 Der Schlussteil ist der Prüfstein: Nehmen Sie drei Aussagen, die Sie als belegt markiert haben, und sehen Sie im Quellcode nach. Die Zahl derer, die standhalten, sagt Ihnen mehr über Ihre Arbeitsweise als das ganze übrige Profil. Achten Sie auf Schritt eins: Starten Sie den Bau wirklich. Nicht nachsehen, ob eine Bauanleitung existiert, sondern ausführen.

15:22 Der Unterschied zwischen beidem ist der Unterschied zwischen diesem Modul und dem üblichen Vorgehen. Schritt zwei und drei sind die eigentliche Ausgrabung, Schritt vier lassen Sie den Agenten mechanisch erledigen. Und Schritt fünf ist die Selbstkontrolle. Wenn von drei geprüften Belegen zwei standhalten, ist das ein normales Ergebnis — und ein guter Grund, künftig immer Stichproben zu nehmen.

15:45 Im nächsten Modul bestimmen wir auf dieser Grundlage die Änderungsfläche.