KI als Archäologe für Legacy-Code: Geschäftsregeln aus VBA extrahieren

Wenn die Geschäftslogik in verstreuten VBA-Makros steckt

Das Problem des verborgenen Schatzes

Stellen Sie sich eine Personaleinsatzplanungs-Anwendung vor, die in VB6 entwickelt wurde und von mehreren hundert Kunden in Deutschland genutzt wird. Im Kern: 28.000 Zeilen VBA-Code, der die Logik für Schichtplanung, Zeiterfassung und — entscheidend — die Einhaltung deutscher Tarifverträge implementiert.

Tarifverträge regeln die Arbeitsbedingungen in deutschen Branchen. Sie legen alles fest, von maximalen Schichtlängen bis zu vorgeschriebenen Ruhezeiten, von Überstundenberechnungen bis zu Urlaubsansprüchen. Doch hier liegt die Komplexität: Diese Regeln unterscheiden sich nach Branche, nach Region, manchmal nach einzelnem Unternehmen. Ein Krankenhaus in Bayern arbeitet nach anderen Regeln als ein Produktionswerk in Nordrhein-Westfalen. Das Distributionszentrum einer Einzelhandelskette hat andere Anforderungen als ihre Filialen.

Über zwei Jahrzehnte entwickelte sich jede Kundeninstallation weiter, um ihre spezifischen Tarifvertragsanforderungen umzusetzen. Nachtschichtzuschläge hier so berechnet, dort anders. Pausenregelungen, die von der Schichtlänge abhängen, aber mit unterschiedlichen Schwellenwerten pro Kunde. Überstunden, die je nach Vertragsart, Beschäftigungsstatus und geltendem Tarifvertrag unterschiedlich auflaufen.

Die Geschäftsregeln stehen in keinem Anforderungsdokument. Sie sind über Tausende von Zeilen VBA verstreut, geschrieben von Entwicklern, die sowohl den Code als auch das Arbeitsrecht verstanden — einige sind weitergezogen, aber viele sind noch verfügbar als Fachexperten, die validieren können, was die KI extrahiert.

Wenn diese Systeme modernisiert werden müssen, stehen Organisationen vor einem grundlegenden Problem: Selbst wenn die ursprünglichen Entwickler noch verfügbar sind, können sie keine Monate damit verbringen, jedes Modul zu erklären. Die Dokumentation, falls sie jemals existierte, beschreibt Absichten statt Implementierung. Nutzer wissen, was das System für sie tut, aber nicht wie — und schon gar nicht, wie alle Teile zusammenwirken.

Warum traditionelle Ansätze scheitern

Die Dokumentationslücke

Die meisten VBA-Anpassungen wurden nie formal dokumentiert. Ein Entwickler schrieb Code, um ein unmittelbares Problem zu lösen, es funktionierte, und alle machten weiter. Selbst wenn Dokumentation existiert, beschreibt sie typischerweise, was jemand zu bauen beabsichtigte, nicht was tatsächlich gebaut wurde — und schon gar nicht die subtilen Änderungen, die über Jahre der Wartung gemacht wurden.

Die Grenzen von Interviews

Geschäftsnutzer können beschreiben, was sie mit dem System machen. Sie kennen ihre Arbeitsabläufe, ihre Grenzfälle, ihre Workarounds. Aber sie beschreiben Verhalten, nicht Logik. Wenn sie sagen „das System berechnet unsere Provision”, können sie nicht die sieben verschachtelten Bedingungen nennen, die bestimmen, welcher Provisionssatz gilt, oder die Sonderbehandlung für ausgelaufene Produkte, oder die Quartalsanpassung, die bei Großkunden greift.

Das Problem der manuellen Code-Analyse

Erfahrene Entwickler können VBA-Code lesen. Aber Tausende von Zeilen über Dutzende angepasster Installationen zu lesen, zu identifizieren, welche Muster Geschäftsregeln versus technische Implementierung darstellen, und alles zu einem kohärenten Verständnis zu synthetisieren — das dauert Monate. Selbst dann ist die Analyse gefärbt von dem, was der Prüfer erwartet zu finden. Unerwartete Muster werden übersehen.

KI-gestützte Code-Archäologie

Als ich begann, mit diesem Kunden als Developer Advocate zu arbeiten, war die Herausforderung klar: Genug Verständnis der bestehenden Geschäftsregeln extrahieren, um das System als moderne Progressive Web App neu zu bauen — auslieferbar sowohl vor Ort für Kunden, die das benötigen, als auch als SaaS-Angebot für diejenigen, die bereit für die Cloud sind.

Traditionelle Analyse würde ein Jahr oder länger dauern. Die Fachexperten kennen das Geschäft, aber sie lesen kein VBA. Die Leute, die den Code geschrieben haben, sind noch da, aber sie haben andere Aufgaben übernommen — Kundenbetreuung, Implementierungsberatung, Schulung — und können keine Monate damit verbringen, Entwickler durch jedes Modul zu führen. Und bei mehreren hundert Kundenvarianten war die manuelle Überprüfung jeder Installation unpraktisch.

Große Sprachmodelle, die auf Code trainiert wurden, bringen etwas Neues in diese Analyse. Anders als frühere Versuche, Software-Entwicklung zu vereinfachen, verspricht KI nicht, den Bedarf an Expertise zu eliminieren — sie verstärkt sie. Diese Modelle haben Millionen von Code-Mustern über verschiedene Sprachen gesehen. Sie können erkennen, was Code zu erreichen versucht, selbst wenn die Implementierung verschlungen ist. Sie werden nicht müde nach dem hundertsten Unterprogramm. Und sie können gezielt nach bestimmten Arten von Geschäftslogik suchen.

Was KI gut kann

Mustererkennung im großen Maßstab: KI-Modelle können große Mengen an Code verarbeiten und wiederkehrende Muster identifizieren. Sie können erkennen, wo ähnliche Geschäftslogik in verschiedenen Kundeninstallationen auftaucht, selbst wenn sie unterschiedlich implementiert ist.

Übersetzung in natürliche Sprache: Bei gegebenem VBA-Code kann eine KI Beschreibungen in Alltagssprache generieren, was der Code tut. Keine perfekten Beschreibungen — die KI kann den Kontext missverstehen — aber Ausgangspunkte, die Menschen verifizieren und verfeinern können.

Vergleich und Kontrast: Bei der Analyse mehrerer Installationen kann KI hervorheben, wo sie sich unterscheiden. „Installation A berechnet Steuern so, aber Installation B hat diese zusätzliche Bedingung.” Diese Unterschiede repräsentieren oft kritische Geschäftsregeln, die spezifisch für jeden Kunden sind.

Fragen beantworten: Statt nur Code zusammenzufassen, kann KI spezifische Fragen beantworten. „Wie handhabt dieses System Retouren?” „Was löst die Kreditlimit-Warnung aus?” „Wo passiert die Rabattberechnung?”

Was KI nicht kann

Geschäftskontext verstehen: KI weiß nicht, warum eine Regel existiert, nur was sie tut. Ein Mensch muss bestimmen, ob eine eigentümliche Berechnung echte Geschäftsanforderungen widerspiegelt oder einen längst vergessenen Workaround.

Vollständigkeit garantieren: KI kann subtile Interaktionen zwischen Code-Modulen übersehen. Sie kann bedingte Logik übersehen, die selten ausgeführt wird. Sie bietet Unterstützung, keine Gewissheit.

Fachexpertise ersetzen: Die KI kann identifizieren, dass eine Berechnung existiert und ihre Mechanik beschreiben. Nur jemand, der das Geschäft versteht, kann beurteilen, ob die Berechnung korrekt, notwendig oder überholt ist.

Ein praktischer Ansatz

Der Ansatz, den wir entwickelt haben, behandelt KI als Brücke zwischen Code und Fachexpertise. Die KI liest das VBA. Die Fachexperten validieren die Geschäftsregeln. Das Ergebnis ist nicht nur Verständnis — es sind ausführbare Spezifikationen, die die neue Implementierung antreiben werden.

Die Konten-Herausforderung

Ein großer Teil des VBA-Codes befasst sich mit Konten — den Bausteinen für die Berechnung von Mitarbeiterzahlungen. Es gibt Hunderte verschiedener Kontentypen: Grundgehaltskonten, Überstundenkonten, Nachtschichtzuschlagskonten, Urlaubskonten, Krankheitskonten, jedes mit eigenen Berechnungsregeln, die je nach Tarifvertrag und Kundenkonfiguration variieren.

Zu verstehen, wie jeder Kontentyp funktioniert — wann er aufläuft, wie er berechnet wird, was Anpassungen auslöst — ist essenziell, damit das neue System korrekte Gehaltsabrechnungen produziert.

Phase 1: KI-gesteuerte Extraktion zu GitHub Issues

Wir leiten die KI an, spezifische Funktionsbereiche des VBA-Codes zu analysieren. „Untersuche dieses Modul und identifiziere alle Kontentypen. Beschreibe für jedes Konto, wann es aufläuft, wie Beträge berechnet werden und welche Bedingungen die Berechnung beeinflussen.”

Die KI produziert nicht nur einen Bericht — sie erstellt ein GitHub Issue für jede entdeckte Geschäftsregel oder jeden Kontentyp. Das Issue enthält die Analyse der KI: was der Code zu tun scheint, welche Bedingungen gelten, welche Variationen sie bemerkt hat und Fragen, wo die Logik unklar war.

Phase 2: Menschliche Prüfung und Planung

Die Fachexperten, die jedes Issue prüfen, sind dieselben Leute, die den ursprünglichen VBA-Code geschrieben haben. Sie sind inzwischen in kundennahe Rollen gewechselt — Implementierung, Support, Schulung — aber sie erinnern sich an die Logik. Sie müssen ihr eigenes VBA nicht erneut lesen; sie lesen die Geschäftssprache-Beschreibung der KI und beurteilen, ob sie dem entspricht, was sie vor Jahren gebaut haben.

Manchmal hat die KI es genau richtig getroffen. Manchmal hat sie eine Nuance übersehen, die der ursprüngliche Autor sofort erkennt. Manchmal hat die KI Verhalten aufgedeckt, das selbst der Autor vergessen hatte — Grenzfallbehandlung, die er vor einem Jahrzehnt für einen bestimmten Kunden hinzugefügt hatte.

Validierte Issues werden zur Implementierung eingeplant. Unklare Issues werden für tiefere Untersuchung markiert, oft verbunden mit einem kurzen Gespräch, um Erinnerungen an die Anforderungen dieses bestimmten Kunden aufzufrischen.

Phase 3: KI-unterstützte Implementierung

Die Implementierung folgt einem ähnlichen Muster. Bei einem validierten Issue, das eine Geschäftsregel beschreibt, prompten wir die KI, den C#-Code und zugehörige Tests für die neue PWA zu schreiben.

Die KI produziert sowohl die Implementierung als auch die Testfälle. Die Tests kodieren die Geschäftsregeln in ausführbarer Form: „Gegeben ein Mitarbeiter mit Vertragstyp X, der Schichtmuster Y arbeitet, wenn das Nachtschichtzuschlagskonto berechnet wird, dann sollte der Betrag Z sein.”

Phase 4: Gezielte menschliche Validierung

Die Fachexperten prüfen die generierten Tests — aber nicht Zeile für Zeile. Sie wissen, welche Konten unkompliziert sind und welche Komplexität verbergen. Sie wissen, welche Tarifvertragsregeln subtile Grenzfälle haben und welche einfache Berechnungen sind.

Sie konzentrieren ihre Aufmerksamkeit auf die kritischen und schwierigen Teile. Wenn sie einen Test für Nachtschichtzuschläge sehen, prüfen sie, ob er die Mitternachtsgrenze korrekt behandelt. Wenn sie Urlaubsaufbau-Tests sehen, verifizieren sie die Logik für Teiljahres-Mitarbeiter. Ihre Expertise leitet, wo sie hinschauen, nicht ob sie alles ansehen.

Diese gezielte Prüfung ist weit effizienter als erschöpfende Verifikation. Die Fachexperten wenden Urteilsvermögen an, wo Fehler wahrscheinlich versteckt sind, statt allen Code als gleich riskant zu behandeln.

Verstärkung statt Ersatz

Die Fachexperten in diesem Unternehmen haben den ursprünglichen VBA-Code geschrieben. Sie kennen deutsches Arbeitsrecht im Detail, und sie kennen den Code, weil sie ihn gebaut haben. Aber ihre Zeit ist knapp — sie sind beschäftigt mit Kundenimplementierungen, Support-Anrufen und Schulungen. Sie Tausende von Zeilen ihres eigenen Codes erneut lesen zu lassen, um ihn neuen Entwicklern zu erklären, ist keine gute Nutzung ihrer Expertise.

Die KI schafft eine Übersetzungsschicht. Sie liest den Code und produziert Beschreibungen in Geschäftssprache. Die ursprünglichen Autoren validieren diese Beschreibungen — schnell, weil sie korrekte Erklärungen ihrer eigenen Arbeit erkennen. Zusammen bringen sie Verständnis in Stunden ans Licht, das sonst Wochen unterbrochener Gespräche dauern würde.

Dieses kollaborative Modell definiert den Developer Advocate-Ansatz: praktische technische Arbeit, die bestehende Expertise verstärkt statt sie zu ersetzen. Die KI ist ein Werkzeug. Die Fachexperten liefern das Urteilsvermögen. Der Developer Advocate orchestriert den Prozess und stellt sicher, dass das extrahierte Wissen zu ausführbaren Spezifikationen wird — nicht nur zu Dokumentation, die aus dem Takt gerät.

Dies ist besonders wichtig für

Legacy-Modernisierungsprojekte, bei denen das Verstehen des bestehenden Systems

handwerkliche Arbeit ist — Untersuchung, Hypothese, Verifikation. KI beschleunigt die Untersuchungs- und Verifikationsphasen, während Menschen die Kontrolle über die Urteilsentscheidungen behalten.

Praktische Überlegungen

Modellauswahl

Verschiedene KI-Modelle haben verschiedene Stärken. Für Code-Analyse funktionieren Modelle mit starken Programmierfähigkeiten und großen Kontextfenstern am besten. Claude Sonnet 4.5 und ähnliche Modelle können umfangreiche Code-Dateien verarbeiten und Kohärenz über lange Analysesitzungen aufrechterhalten.

Kontext-Management

VBA-Module können groß sein. Der KI genug Kontext zu geben, um zu verstehen, was sie betrachtet — ohne sie mit irrelevantem Code zu überwältigen — erfordert Urteilsvermögen. Manchmal müssen zusammenhängende Module gemeinsam eingespeist werden; manchmal muss man sich auf spezifische Funktionen konzentrieren.

Prompt-Engineering

Wie man fragt, ist enorm wichtig. „Was macht dieser Code?” produziert generische Antworten. „Dieser VBA-Code scheint Preisnachlässe zu berechnen. Identifiziere alle Bedingungen, die beeinflussen, welcher Rabattsatz angewendet wird, und erkläre jede Bedingung in geschäftlichen Begriffen” produziert nützliche Analyse.

Versionskontrolle

Wenn man Code aus mehreren Kundeninstallationen analysiert, ist es essenziell zu verfolgen, welcher Code woher kam. Der KI ist es egal, aber den Menschen, die ihre Ausgabe interpretieren, definitiv nicht.

Über die Extraktion hinaus: Für die Zukunft bauen

Bestehende Geschäftsregeln zu verstehen ist nur der erste Schritt. Das größere Ziel ist typischerweise, diese Logik in einem modernen System neu zu bauen — dokumentiert, getestet, wartbar.

Die Muster, die man aus Legacy-VBA extrahiert, können zur Grundlage werden für:

• Ausführbare Spezifikationen, die genau dokumentieren, was das System tun soll
• Test-Suiten, die verifizieren, dass die neue Implementierung dem alten Verhalten entspricht
• Domänenmodelle, die Geschäftsregeln explizit machen statt sie im Code zu vergraben

KI-Unterstützung endet nicht bei der Extraktion. Dieselben Modelle können helfen, identifizierte Geschäftsregeln in modernen Code zu übersetzen, Testfälle zu generieren und das beabsichtigte Verhalten zu dokumentieren. Der gesamte Bogen vom Verstehen zum Neubauen wird schneller.

Der wahre Wert

Das Personaleinsatzplanungssystem repräsentiert Jahrzehnte an angesammeltem Wissen über deutsches Arbeitsrecht — nicht abstrakte Rechtstheorie, sondern praktische Implementierung, wie Hunderte von Organisationen diese Regeln tatsächlich anwenden. Dieses Wissen hat enormen Wert, aber es war eingesperrt in VBA-Code, den nur eine Handvoll Menschen lesen konnte.

Jetzt wird dieses Wissen explizit. Die Tests, die wir erstellen, validieren nicht nur die neue PWA-Implementierung — sie dokumentieren genau, wie jede Tarifvertragsregel in der Praxis funktioniert. Wenn ein Kunde fragt „wie handhaben Sie Ruhezeiten für Teilzeitmitarbeiter im Einzelhandel?”, existiert die Antwort in lesbarer, ausführbarer Form.

Das verändert die Modernisierungsökonomie fundamental. Ein Jahr manueller Analyse komprimiert sich auf Wochen. Die Fachexperten — die dieses Jahr damit verbracht hätten, Fragen von Entwicklern zu beantworten, die versuchen, den Code zu verstehen — validieren stattdessen extrahierte Regeln auf Geschäftsebene. Ihre Expertise wird gehebelt, nicht verbraucht.

Für Organisationen, die Legacy-Systemen mit umfangreicher Anpassung gegenüberstehen, repräsentiert dies eine neue Fähigkeit. Arbeit, die zuvor Monate teurer Spezialistenzeit erforderte, passiert jetzt in Wochen. Analyse, die zu teuer war, um sie zu rechtfertigen, wird erschwinglich. Geschäftswissen, das in jahrzehntealtem Code eingesperrt war, wird zugänglich für Menschen, die es tatsächlich nutzen können.

Der Code geht nirgendwohin. Aber jetzt haben wir bessere Werkzeuge, um zu verstehen, was er weiß.