Jahrelang war ich der Bankberater meiner eigenen Codebasis. Ein Antrag lag mehrmals auf dem Tisch: den Versand aus dem Monolithen herauslösen. Eigener Service, eigenes Deployment, vielleicht irgendwann ein eigenes Team. Und jedes Mal sass ich auf beiden Seiten des Schreibtischs: als Antragsteller, der den Schnitt wollte, und als Berater, der die Bonität prüfte. Der Berater gewann immer.
Zweimal verschoben, einmal aus der Roadmap gehalten. Nicht aus Faulheit – das hätte weniger Vorbereitung gebraucht. Wir standen dreimal am Whiteboard davor und jedes Mal wurde dasselbe sichtbar: Der Schnitt liegt nicht dort, wo das Diagramm ihn vermutet. Die Abhängigkeiten reichen so tief in den Monolithen, dass es beim Herauslösen nicht bliebe. Es bräuchte Umbauten drinnen, an Stellen, die niemand anfassen wollte, oder sollte.
Am Ende landeten wir jedes Mal bei derselben Tabelle. T_ORDER_STATUS, siebzehn Spalten, davon heissen drei VERSANDART, FREIGABE_KZ und BEMERKUNG. Welche nullable sind, ergibt kein Muster, sondern eine Chronologie. Die Auftragserfassung schreibt hinein, der Versand auch und irgendwo im Backoffice gibt es einen Knopf, der den Status direkt setzt. Und nachts um 02:15 liest ein Job mit, den vor Jahren jemand geschrieben hat, der nicht mehr da ist. Trennt man den Service heraus, trennt man auch das. Dann ist die Frage nicht mehr, ob die Daten konsistent sind, sondern wann sie es wieder sind.
Dazu kam, dass in der Fachdomäne niemand sagen konnte, wohin die Reise geht. Ein Schnitt entlang von Anforderungen, die in zwei Quartalen anders aussehen, ist kein Schnitt, sondern eine Wette. Und Wetten sollte ein seriöser Berater nicht finanzieren.
Antrag abgelehnt. Die Story dazu existierte seit Jahren in Jira und wurde bei jedem Backlog-Grooming ein Stockwerk tiefer gelegt, wie ein Aktenordner, den niemand vernichten will, aber auch niemand öffnen.
Dann kam AI.
Ich gab einem Agenten den Auftrag, genau diese Extraktion zu machen. Weniger aus Überzeugung als aus Neugier, vielleicht auch mit der stillen Hoffnung, er würde scheitern und meine Ablehnungsbescheide posthum bestätigen. Er bekam die fachliche Abgrenzung, was zum Versand gehört und was nicht. Die Zielarchitektur vom Whiteboard, die Schnittstelle, die wir uns vorgestellt hatten. Und vor allem: was er nicht tun sollte. Die zweite Liste war länger als die erste. Bei Agenten lohnt sich das mehr, als die erste zu präzisieren.
Zwei Stunden und drei Iterationen später hatte ich einen Pull Request. Die ersten beiden Fassungen hatten Dinge mitgenommen, die nur historisch mit dem Versand verwachsen waren, nicht fachlich. Jedes Mal wuchs die Liste dessen, was er nicht tun sollte. 94 geänderte Dateien, ein neues Modul, eine Schnittstelle, die strukturell sauberer war als das, was wir am Whiteboard skizziert hatten. Alle Tests grün. Was bei unserer Abdeckung vor allem eine Aussage über unsere Tests war.
Drei bis fünf Wochen hatte der Berater kalkuliert. Geliefert wurde in zwei Stunden. Das war der Moment, in dem der Bankberater in mir ein Problem bekam. Der grösste Posten seiner Kalkulation war ein einziger Zinssatz: der Preis menschlicher Arbeitszeit. Und jetzt sass da jemand vor ihm, der dieselbe Arbeit zum Bruchteil des Stundensatzes anbot. Es ist ein eigenartiges Gefühl, wenn die eigene Kosten-Nutzen-Rechnung von einer Maschine widerlegt wird, die nicht einmal weiss, dass es eine gab.
Softwareentwicklung war immer auch eine Kreditwirtschaft, wir haben es nur selten so genannt. Duplizieren wir Code oder leisten wir uns die Abstraktion? Fassen wir das alte Modul an oder bauen wir vorsichtig darum herum und zahlen dafür jeden Monat ein bisschen Zins? Aus diesen Abwägungen haben wir Prinzipien gemacht: Wiederverwendung, Kapselung, Modularisierung. Nicht weil sie schön sind, obwohl wir das gern behaupten. Jedenfalls nicht nur. Sondern weil Menschen teuer sind. Unsere ganze Architekturlehre ist im Kern eine Zinstabelle. Und bei einem Teil der Rechnung ist der Zinssatz gerade dramatisch gefallen.
Ein paar Tage später schaute ich mir den Pull Request noch einmal an.
Der Code war gut. Das war das Problem. Er war gut genug, dass ich nicht auf einen offensichtlichen Fehler zeigen und mich zurücklehnen konnte. Also musste ich tun, was Reviewer im Ernstfall tun: lesen.
Die Tabelle hatte er nicht übersehen. Er hatte das Problem gelöst. Der neue Service schreibt seinen eigenen Status und meldet Änderungen per Event zurück, der Monolith führt nach. Sauber gebaut, sogar mit Retry. Nur der Knopf im Backoffice schreibt weiter direkt hinein. Es dauerte eine Weile, bis ich verstand, welche Entscheidung hier eigentlich getroffen worden war. Das war die, vor der wir dreimal am Whiteboard gestanden hatten. Sie war einfach implementiert worden.
Nachgeführt heisst aber nicht sofort. Im Schönwetterfall sind es Millisekunden. An einem schlechten Tag, Queue voll, Netz weg, auch mal Stunden. Irgendwann stimmt es wieder. Die Frage, die jetzt zählte: Wie lange darf der Status falsch sein, bevor es jemandem auffällt? Dem Job um 02:15 oder dem Empfängersystem dahinter? Es gibt eine Antwort darauf. Sie steht nur nirgends.
Bei einer Bank würde man sagen: Die Kreditakte fehlt. Es gibt eine Schuld, es gibt Zinszahlungen, aber niemand findet den Vertrag, in dem steht, wofür wir das Geld damals aufgenommen haben. Diese Lücke füllen wir mit etwas, das wir Erfahrung nennen. Für den Agenten ist der Fall einfacher: Diese Akte existiert für ihn schlicht nicht.
Das brachte mich zu einer anderen Sicht auf AI und Architektur. Zuerst hatte ich gedacht, AI würde vor allem grosse, verwucherte Systeme retten. Ein Agent liest schneller als ich, verfolgt Abhängigkeiten quer durch 94 Dateien, führt Tests aus und vergisst dabei keine einzige. Das stimmt auch. Nur hilft ihm das wenig, wenn niemand mehr sagen kann, warum das System so ist.
Denn aus der Sicht eines Agenten liest sich Architektur wie ein Kreditdossier. Ein sauber geschnittenes Modul ist nicht nur guter Stil, es ist vor allem ein überschaubares Risiko. Eine klare Schnittstelle ist eine Haftungsgrenze: bis hierhin kann er etwas kaputt machen, weiter nicht. Ein Test ist ein Beleg: die einzige ausführbare Aussage darüber, was wir eigentlich wollten, und in vielen Projekten die einzige Stelle, an der das irgendwo steht. Und eine dokumentierte Architekturentscheidung ist nicht mehr nur für den Entwickler interessant, der in zwei Jahren übernimmt. Sie steht in den Instruktionen für den nächsten Agenten, der nicht in zwei Jahren, sondern in zwei Minuten zum Zug kommt.
Ich bewerte heute manche Schulden anders als noch vor ein paar Jahren. Duplizierter Code ist ein Kleinkredit: ärgerlich, aber jederzeit ablösbar. Eine geteilte Tabelle, in die mehrere Komponenten schreiben, ist eine variable Hypothek, auf der alle weiterbauen: Agenten eingeschlossen, die das mit grosser Begeisterung und ohne jedes schlechte Gewissen tun. Und ein Monolith wird nicht dadurch übersichtlicher, dass man ihm einen Agenten zur Seite stellt. Er wird zunächst nur schneller verändert. Zinseszins gab es immer. Neu ist die Taktung.
Vielleicht ist die interessante Frage deshalb nicht, ob AI gute oder schlechte Architektur produziert. Sondern: Welche Architektur ist überhaupt kreditwürdig genug, dass man ihr einen Agenten anvertrauen kann?
Den Pull Request habe ich am Ende nicht gemerged. Nicht weil er schlecht war. Sondern weil ich immer noch nicht weiss, was der Job um 02:15 verträgt, und weil das jemand herausfinden muss, der versteht, was dort nachts eigentlich passiert.
Der Agent hatte die Arbeit billiger gemacht. Die Entscheidung nicht. Sie blieb bei mir, zum alten Preis.
Wir konnten uns schlechte Architektur bisher leisten, weil wir zu langsam waren, um ihren vollen Preis zu bezahlen. Dieses Problem hat AI gelöst.
- Der Fall ist aus mehreren Projekten zusammengesetzt und anonymisiert. Die Beobachtung nicht.
- Wer es systematisch statt erzählt will: Sven-Torben Janus hat dieselbe Verschiebung fachlich durchgearbeitet: Softwarequalität neu denken: Architektur im Zeitalter von KI, Informatik Aktuell.