Der Autor einer 20 Jahre alten Versicherungsplattform hat 108 Support-Tickets durch eine maßgeschneiderte KI-Agenten-Pipeline laufen lassen. Das Ergebnis ist ein Workflow, der eine stundenlange Aufgabe für Senior-Entwickler in wenige Minuten verwandelt – eine Entwicklung, die die Art und Weise, wie Unternehmen Legacy-Code am Leben erhalten, grundlegend verändern könnte.
Warum Legacy-Systeme wichtiger sind als neuer Code
Die betreffende Versicherungsanwendung ist ein Monolith aus 2,3 Millionen Zeilen Code und etwa 1.000 PL/SQL-Paketen. Allein ihre Größe macht es unmöglich, dass eine einzelne Person die gesamte Codebasis beherrscht. Hinzu kommen ein Labyrinth aus kundenspezifischen Konfigurationsparametern, verstreute Dokumentationen und ein Ticket-Archiv, das bis ins Jahr 2017 zurückreicht. Das eigentliche Nadelöhr ist somit nicht das Schreiben von Code, sondern das „Finden des Kontexts“.
Der typische moderne KI-Hype konzentriert sich auf die Generierung von neuem Code für Greenfield-Projekte. In diesem Fall liegt die Schwierigkeit nicht in der Syntax von PL/SQL, sondern darin, das exakte Logikstück, die relevante Konfiguration und das historische Ticket zu finden, das das Problem zum ersten Mal beschrieb. Ein erfahrener Entwickler kann Stunden damit verbringen, Hinweise aus GitLab, SVN, Wikis und alten Support-Tickets zusammenzufügen. Der KI-Agent erledigt dieselbe Arbeit in Minuten.
Der Workflow in der Praxis
Wenn ein neues Ticket eingeht, führt der Autor einen einzigen Befehl aus. Der Agent:
- Ruft den Tickettext und alle angehängten Dateien über die Ticket-System-API ab.
- Führt eine Keyword- und Vektorsuche im gesamten Ticket-Archiv durch, um ähnliche vergangene Fälle aufzuspüren.
- Fragt eine persönliche Bibliothek mit wiederverwendbaren SQL-Skripten ab.
- Untersucht die Code-Historie in den Versionsverwaltungssystemen (GitLab oder SVN).
Alle Ergebnisse werden in einer Datei zusammengefasst, die auch den nächsten Schritt vorschlägt – in der Regel eine Code-Korrektur, einen Entwurf für eine Antwort an den Kunden oder eine Anfrage für weitere Diagnosen.
Integrierte Fähigkeiten
Der Autor hat 24 „Skills“ für den Agenten definiert, die in vier Kategorien unterteilt sind:
- Kontextzugriff – Lesen von APIs, Handbüchern und Datenbanken, um relevante Fakten zu extrahieren.
- Domänenwissen – Interpretation von Versicherungsbuchungsregeln und der Systemarchitektur.
- Schreiben – Generierung von PL/SQL-Snippets und deren Paketierung für das Deployment.
- Meta – Erkennen von Mustern und automatisches Erstellen neuer Skills bei Bedarf.
Diese Fähigkeiten ermöglichen es dem Agenten, wie ein Junior-Entwickler zu agieren, der niemals schläft, und die exakte Codezeile oder Konfiguration zu finden, auf die sich ein Ticket bezieht.
In den Prozess integrierte Sicherheitsnetze
Automatisierung in einer Produktionsumgebung erfordert Schutzmaßnahmen. Der Autor folgt zwei einfachen Regeln:
- Statische Validierung – Jedes generierte Skript wird mittels eines
EXPLAIN PLANgegen das Live-Schema geprüft. Dies prüft auf Syntax- oder Logikfehler, ohne den Code tatsächlich auszuführen. - Bestätigung durch zwei Modelle – Ein zweiter, unabhängiger KI-Agent überprüft jede Änderung, die als riskant eingestuft wird. Wenn beide Modelle zum gleichen Ergebnis kommen, fährt der Autor fort; andernfalls wird das Ticket zur manuellen Überprüfung eskaliert.
Diese Prüfungen verhindern, dass der Prozess zu einer Blackbox wird, die versehentlich eine kritische Versicherungstransaktion unterbrechen könnte.
Kumulative Vorteile
Die Ausgabe jedes Tickets wird wieder mit dem Ticketdatensatz verknüpft, wodurch eine lebendige Wissensdatenbank entsteht. Wenn ein ähnliches Problem Monate oder Jahre später erneut auftritt, kann der Agent nicht nur die vorherige Lösung lesen, sondern auch die Argumentation, die dazu geführt hat. Im Grunde wird jedes gelöste Ticket zu Trainingsdaten für zukünftige Tickets, was den Zyklus weiter beschleunigt.
Ehrliche Einschränkungen
- Manuelles Testen bleibt bestehen – Der Autor validiert Änderungen weiterhin in einer Testumgebung, bevor sie übernommen werden.
- Keine harten Metriken – Obwohl die Zeitersparnis erheblich erscheint, hat der Autor die genaue Reduzierung der Stunden noch nicht quantifiziert.
- Persönliches Setup – Die aktuelle Implementierung läuft auf einer einzelnen Workstation; eine Skalierung auf ein ganzes Team würde zusätzliche Engineering-Aufwände erfordern.
Diese Einschränkungen verhindern, dass der Ansatz ein fertiges Produkt ist, aber sie schmälern nicht die zentrale Erkenntnis: KI kann die Zeit für die Kontextbeschaffung von Stunden auf Minuten reduzieren.
Was als Nächstes zu beobachten ist
Das Experiment des Autors ist eher ein Proof-of-Concept als ein kommerzielles Angebot. Die nächsten logischen Schritte umfassen:
- Formalisierung von Metriken – Erfassung der Ticket-Lösungszeiten vor und nach der KI-Pipeline, um einen Business Case zu erstellen.
- Team-Bereitstellung – Bereitstellung des Agenten als Shared Service, damit mehrere Ingenieure von derselben Wissensdatenbank profitieren können.
- Integration in CI/CD – Das direkte Einspeisen validierter Skripte in eine Continuous-Integration-Pipeline könnte den Kreislauf vom Ticket bis zur Produktion schließen, ohne dass ein manueller Übergabeprozess erforderlich ist.
Sollten diese Erweiterungen erfolgreich sein, könnte das Modell als Vorlage für andere Unternehmen dienen, die mit massiven, tief verwurzelten Codebasen zu kämpfen haben.
Fazit
Der wahre Wert von KI in Legacy-Umgebungen liegt nicht im automatischen Schreiben von neuem Code, sondern darin, sofort den richtigen Kontext zu liefern. Indem ein KI-Agenten-Workflow die stundenlange Detektivarbeit eines Senior-Entwicklers auf wenige Minuten reduziert, können alternde Systeme funktionsfähig gehalten, Supportkosten gesenkt und schrittweise ein sich selbst verstärkendes Wissensrepository aufgebaut werden. Das Experiment zeigt, dass der größte Produktivitätsgewinn bei Legacy-Software nicht durch das Generieren von neuem Code entsteht, sondern durch die drastische Verkürzung der Suche nach Antworten.
