|
Getting your Trinity Audio player ready...
|
Wer jahrzehntelang gewachsene Software durch KI-Agenten ablösen lässt, steht vor einem Problem, das mit Code nur zur Hälfte zu tun hat. Der Sollzustand, an dem sich der Neubau messen lässt, wird in der Praxis nicht gefunden, sondern zwischen IT und Fachabteilungen verhandelt. Und jede Entscheidung, welche Funktion nicht mehr übernommen wird, legt fest, was die Organisation künftig nicht mehr kann. Agenten machen das Verlernen schnell und billig. Das Wiedererlernen bleibt langsam und teuer. Der Essay fragt, wer diese Entscheidung trifft und woran er sie prüfen kann.
Die Beschreibung steckt im Code
Ob KI-Agenten das Argument entkräften, dass sich gewachsene Software kaum ersetzen lässt, ist offen. Sie können Verhalten schneller vergleichen und Tests in großer Zahl erzeugen. Das hilft aber nur, wenn es etwas gibt, an dem sich das neue Verhalten messen lässt. Bei jahrzehntelang gewachsener Netzwerksoftware ist der Code oft die einzige vollständige Beschreibung dessen, was das System tut. Wer ihn ersetzt, muss entweder diese Beschreibung rekonstruieren oder darauf vertrauen, dass das Neue dasselbe tut. Beides ist eine Aussage über Tests und Verantwortung, nicht über Tokens.
Reverse Engineering ist der Versuch, die fehlende Beschreibung nachträglich herzustellen. Wo ein Sollzustand existiert, können Agenten dagegen testen, schnell und in großer Zahl. In der Praxis wird dieser Sollzustand aber nicht gefunden, sondern verhandelt: zwischen IT, Fachabteilungen und anderen Beteiligten, mit unterschiedlichem Gewicht und unterschiedlichem Interesse. Was als Testfall aufgenommen wird, ist ein Kompromiss, der Entscheidungen anschlussfähig macht, aber nicht zeigt, ob er das Problem trifft. Die Lücken liegen dabei nicht zufällig, sondern dort, wo niemand zuständig ist oder wo die Abteilung mit dem Wissen wenig durchsetzen konnte. Agenten können diese Verhandlung verändern: Sie können Widersprüche und Auslassungen sichtbar machen, aber auch zum Instrument einer Seite werden oder die Beteiligten mit Testfällen überfordern. Ein bestandener Test belegt damit zunächst nur, dass der Neubau dem entspricht, worauf man sich geeinigt hat.
Der Bestand ist keine sichere Referenz
Dagegen lässt sich einwenden, dass der Bestand selbst keine verlässliche Referenz sei. Gewachsene Systeme sind durch Versuch und Irrtum entstanden. Workarounds ersetzten die Modernisierung der Gesamtarchitektur, und irgendwann überblickt niemand mehr das Ganze. Das System läuft, aber niemand kann sagen, warum. Der Verzicht auf einen Neubau ist dann kein sicherer Zustand, sondern ein Risiko, das nur nicht sichtbar wird.
Frederick Brooks hat in seinem Aufsatz „No Silver Bullet“ zwischen wesentlicher und zufälliger Komplexität unterschieden. Die wesentliche liegt im Problem selbst, die zufällige in der Art, wie man es gelöst hat. Ein Neubau könnte die zufällige abstreifen. Die Unterscheidung lässt sich aber aus dem Code allein nicht gewinnen: Ein Workaround kann Altlast sein oder das einzige Zeugnis eines Falls, der einmal Schaden angerichtet hat. Neben den ausgehandelten Sollfällen braucht es deshalb einen zweiten Prüfstein, und das kann der Betrieb sein, also der Vergleich von Alt und Neu am echten Verkehr, in dem jede Abweichung erklärt und bewertet wird. Auch er ist keine neutrale Instanz, denn er zeigt nur, was im Beobachtungszeitraum vorkam, und was als Abweichung gilt, hängt von den Beteiligten ab. Er deckt aber auf, was in der Verhandlung niemand eingebracht hat. Agenten können diese Abweichungen in großer Zahl sortieren. Welche Abweichung hinnehmbar ist, entscheiden sie nicht.
Software als verfestigte Entscheidung
Auch der Vergleich der Ausgaben behandelt das System noch als Black Box, die Eingaben in Ausgaben verwandelt. Er prüft, ob die Software dasselbe tut, nicht, was sie in der Organisation bewirkt.
Der Soziologe Niklas Luhmann beschreibt Organisationen als Systeme, die aus Entscheidungen bestehen, die an Entscheidungen anschließen. Was in einer Organisation entschieden werden kann, ist durch Prämissen vorstrukturiert, etwa durch Programme, Kommunikationswege und Personal. Gewachsene Software gehört in diesem Sinn zu den verfestigten Entscheidungen. Sie legt fest, was sichtbar wird, in welcher Reihenfolge etwas geschieht und wer bei Abweichungen angesprochen wird. Das ist eine Zuspitzung der Luhmannschen Begriffe und nicht seine Aussage über Software.
Vieles davon steht in keiner Anforderung. Der nächtliche Batch-Lauf ist auch eine Frist, in der morgens noch jemand korrigieren kann. Die umständliche Maske erzwingt die Rücksprache zwischen zwei Abteilungen. Plausibilitätsprüfungen und Standardwerte nehmen Entscheidungen Unsicherheit ab, sodass niemand mehr sieht, dass hier einmal jemand entschieden hat. Und der Workaround ist oft die Stelle, an der die formale Ordnung und die tatsächliche A…