Output lässt sich parallelisieren, Verständnis nicht. Warum Organisationen Verantwortung gerade leise in Risiko umwandeln — und warum das erst im Ernstfall auffällt.
Die Rechnung, die keiner aufmacht
In Team-Chats wird gerade viel gefeiert. Zwanzig Pull Requests diese Woche, dreißig nächste. Die Agents laufen über Nacht, morgens liegt der Diff bereit, die Pipeline ist grün. Durchsatz ist die Metrik der Stunde, und sie zeigt steil nach oben.
Eine Frage taucht in diesen Chats selten auf: Wie viele dieser Änderungen hat jemand wirklich verstanden? Nicht überflogen, nicht abgenickt, weil die Tests durchliefen — verstanden im Sinne von: Ich kann erklären, warum diese Änderung richtig ist, was sie im System bewegt und was passiert, wenn sie es nicht tut.
Dass die Frage fehlt, ist kein Versäumnis einzelner Teams. Durchsatz lässt sich zählen, Verständnis nicht, und was sich nicht zählen lässt, taucht in keinem Dashboard auf. Es fällt erst auf, wenn es fehlt.
Dabei ist die zugrunde liegende Grenze nicht neu. Ein Entwickler kann eine Änderung gründlich reviewen. Vielleicht fünf. Vielleicht zwanzig, wenn sie klein sind und die Tests gut. Irgendwo dahinter wird aus Review Sichtung, aus Sichtung Stichprobe. Diese Grenze existierte schon immer — sie wurde nur nie erreicht, weil Menschen Code nicht in dem Tempo schreiben konnten, in dem Agents ihn heute erzeugen. Jetzt wird sie wöchentlich überschritten, und der Abstand zwischen dem, was produziert wird, und dem, was jemand versteht, wächst.
Die Branche hat gelernt, Output zu skalieren. Die Zahl der Menschen, die für diesen Output sprechen können, ist gleich geblieben.
Was mit Verantwortung passiert, wenn niemand sie will
Die naheliegende Erwartung wäre: Organisationen bemerken diese Lücke und benennen jemanden, der sie schließt. Einen Verantwortlichen für das, was die Agents bauen.
Das wird in den meisten Unternehmen nicht passieren, und es lohnt sich, ehrlich zu sein, warum. Verantwortung ist eine unangenehme Kostenposition. Organisationen gehen mit unangenehmen Kostenpositionen selten so um, dass sie sie einer Person zuordnen — sie verteilen sie, bis niemand sie mehr sieht. Das Team ist verantwortlich. Der Prozess ist eingehalten. Der Vendor haftet laut Vertrag. Die Versicherung deckt den Rest. Jede dieser Antworten ist für sich genommen vernünftig, viele davon sind sogar gute Praxis. Zusammengenommen ergeben sie etwas anderes: organisierte Diffusion.
Diffusion funktioniert erstaunlich gut. Sie hält den Betrieb ruhig, sie schützt Einzelne vor Schuldzuweisung, sie erfüllt Prüfanforderungen auf dem Papier. Sie hat nur eine Eigenschaft, über die selten gesprochen wird: Verantwortung, die man diffundiert, verschwindet nicht. Sie wandelt sich um — in Risiko.
Der Unterschied zeigt sich nicht im Normalbetrieb. Er zeigt sich im Incident. Die Versicherung kann zahlen, aber sie kann nicht erklären, warum das System entschieden hat, wie es entschieden hat. Der Vendor kann auf seine Vertragsklauseln verweisen, aber er behebt den Vorfall nicht. Der Prozess kann belegen, dass alle Freigaben vorlagen, aber er sagt niemandem, was jetzt zu tun ist. All diese Mechanismen verteilen die Folgen eines Problems. Keiner von ihnen stellt Handlungsfähigkeit her.
Und so passiert im Ernstfall etwas Interessantes, quer durch alle Unternehmenskulturen, auch durch die, die sich ausdrücklich zu blameless bekennen: Die Organisation sucht die Person, die das System erklären kann. Nicht um sie zu belangen — um wieder arbeitsfähig zu werden.
Verständnis ist eine Ressource mit Abfluss
Denn während der Systembestand wächst, passiert mit dem Verständnis dafür zweierlei. Es wächst deutlich langsamer — Verstehen lässt sich nicht parallelisieren, es entsteht in dem Tempo, in dem Menschen Systeme durchdringen. Und es fließt ab: mit jedem Projektwechsel, jeder Umstrukturierung, jedem Consultant, dessen Vertrag endet. In einer Branche, in der Teams sich alle zwölf bis achtzehn Monate neu zusammensetzen, ist das kein Randphänomen, sondern der Normalfall.
Solange Menschen den Code selbst schrieben, korrigierte sich das teilweise von allein. Wer etwas baut, versteht es zwangsläufig; das Schreiben war das Lernen. Diese Kopplung ist gerade dabei, sich aufzulösen. Ein System kann heute über Monate wachsen, erweitert und umgebaut werden, ohne dass der Zuwachs an Code einen entsprechenden Zuwachs an Verständnis erzeugt hat — bei niemandem.
Man könnte das technische Schulden zweiter Ordnung nennen. Schulden erster Ordnung kennt jeder: der schnelle Hack, die fehlende Abstraktion, das Modul, das keiner anfassen will. Unangenehm, aber behandelbar — Schulden auf Code kann man refactoren. Schulden auf Verständnis muss man neu erarbeiten, von Menschen, die das System nie gekannt haben. Das ist möglich, aber es ist langsame, teure Arbeit, und sie beginnt fast immer unter dem denkbar schlechtesten Vorzeichen: mitten im Vorfall, unter Zeitdruck, mit einem System, das gerade beweist, dass es nicht verstanden wurde.
Das Tückische an diesen Schulden ist ihre Unsichtbarkeit. Kein Linter findet sie, keine Metrik schlägt aus, das System läuft ja. Es läuft nur zunehmend ohne Zeugen.
In regulierten Umgebungen ist der Mechanismus schon sichtbar
Wer sehen will, wie das endet, muss nicht spekulieren. Es reicht, dorthin zu schauen, wo Nachvollziehbarkeit schon lange keine Tugend ist, sondern eine Anforderung: Banken, Versicherer, kritische Infrastruktur.
Dort existiert das Gerüst aus Autorenschaft, Freigaben und Historie nicht, weil diese Häuser Bürokratie schätzen, sondern weil dort die Frage „wer kann das erklären“ regelmäßig tatsächlich gestellt wird — von Prüfern, von Aufsehern, im Schadensfall von Gerichten. Diffusion stößt in diesen Umgebungen schneller an ihre Grenze, weil der Ernstfall institutionalisiert ist. Er kommt nicht vielleicht irgendwann; er kommt im Prüfungszyklus.
Maschinell erzeugter Code hebelt dieses Gerüst nicht aus, er läuft mitten hinein. Und die Regulierung, die dieses Jahr in Europa in ihre nächste Stufe geht, formalisiert im Kern nur, was ohnehin gilt: Systeme, deren Entscheidungen niemand erklären kann, sind ein Risiko — technisch, geschäftlich, rechtlich. Neu ist nicht die Anforderung. Neu ist, dass sie nun auch für die Teile des Systems gilt, die keine Person geschrieben hat.
Der Rest der Wirtschaft ist von dieser Prüfdichte weit entfernt, und vieles davon wird sie nie erreichen. Aber der Mechanismus ist derselbe, nur der Auslöser ein anderer: Wo der Prüfer fehlt, übernimmt der Incident seine Rolle. Er kommt unangekündigt, aber er stellt dieselbe Frage.
Dazu an anderer Stelle mehr. Hier genügt die Beobachtung, dass die regulierten Branchen gerade vorführen, was passiert, wenn Diffusion auf einen Ernstfall trifft, der planmäßig eintritt.
Was die wenigen tun werden
Ich schreibe bewusst nicht, was Unternehmen tun sollten. Die meisten werden den Weg der Diffusion gehen, er ist kurzfristig rational, und Appelle ändern daran erfahrungsgemäß wenig. Interessanter ist, was die wenigen tun werden, die den Mechanismus verstanden haben — sei es aus regulatorischem Zwang, sei es nach dem ersten teuren Vorfall.
Sie werden nicht weniger AI einsetzen. Das Produktivitätsniveau ist real, und niemand geht dahinter zurück. Sie werden stattdessen an drei Stellen anders arbeiten.
Sie werden Verantwortung zuschneiden statt zentralisieren. Ein Mensch „über allem“ ist keine Struktur, sondern ein Engpass. Tragfähig sind kleinere, klar geschnittene Bereiche, in denen jemand ein Stück System tatsächlich kennt — mit der ehrlichen Konsequenz, dass der Durchsatz pro Bereich begrenzt ist. Die Grenze war immer da; sie wird damit nur sichtbar gemacht statt ignoriert.
Sie werden Evidenz verlangen statt Vertrauen. Wenn niemand mehr jede Zeile prüfen kann, verschiebt sich, was geprüft wird. Ein Agent, der nur Ergebnisse liefert, verlangt blindes Vertrauen. Ein Agent, der Nachweise mitliefert — Tests, die die fachliche Anforderung tatsächlich abdecken, Validierung gegen definierte Kriterien, eine nachvollziehbare Begründung für nicht-triviale Entscheidungen — verlangt Urteilsvermögen. Der Mensch prüft den Nachweis, nicht den Diff. Bei diesem Volumen ist das kein schwächeres Review, sondern das einzige, das den Namen noch verdient.
Und sie werden Entscheidungen festhalten, nicht nur Änderungen. Der Diff zeigt, was sich geändert hat; das Warum ist das Einzige, was in zwei Jahren noch jemanden interessiert — und das Einzige, was den Abfluss von Verständnis überlebt, wenn Menschen gehen. Wir arbeiten intern deshalb entscheidungsgetrieben statt ticketgetrieben; wer es genauer wissen will, findet das unter D³ dokumentiert. Der Kern ist unabhängig vom Framework: Eine festgehaltene Entscheidung ist übertragbar. Verständnis, das nur in Köpfen lebt, ist es nicht.
Nichts davon ist ein Tool, und nichts davon lässt sich nachträglich kaufen. Es ist Architektur — nicht die des Systems, sondern die der Verantwortung dafür. Wer sie nicht bewusst gestaltet, bekommt trotzdem eine. Die Diffusion ist schließlich auch eine.
Die neue Knappheit
Ich habe im Januar geschrieben, dass Software bald nichts mehr kostet — und dass genau das teuer wird. Das Argument lässt sich weiterführen.
Wenn Schreiben nichts mehr kostet, ist Schreiben keine Kompetenz mehr, für die jemand bezahlt. Wenn selbst Entscheidungen zunehmend vorbereitet, simuliert und vorgeschlagen werden, verengt sich der Raum weiter. Was bleibt, ist das, was sich prinzipiell nicht erzeugen lässt: ein System so zu kennen, dass man seine Entscheidungen erklären, seine Fehler einordnen und seine Grenzen benennen kann — im Normalbetrieb, und vor allem dann, wenn er endet.
Diese Fähigkeit ist nicht mitskaliert, während der Output es tat. Sie fließt mit jeder Umbesetzung ab und wächst nur langsam nach. Das ist die Definition einer knappen Ressource, und Knappheit setzt Preise — unabhängig davon, ob Organisationen das heute schon einpreisen oder erst, wenn der erste Incident die Rechnung aufmacht.
Für Entwickler bedeutet das eine Verschiebung, keine Bedrohung. Die Frage ist nicht mehr, wie viel jemand produziert; Produktion ist gelöst. Die Frage ist, für wie viel System jemand sprechen kann. Das lässt sich nicht behaupten, sondern nur belegen — spätestens im ersten Ernstfall trennt sich beides zuverlässig.
Und für Organisationen bedeutet es: Die Agents sind nicht das Risiko. Das Risiko ist ein Systembestand, der schneller wächst als das Verständnis dafür — bei laufender Umwandlung von Verantwortung in Diffusion und von Diffusion in Risiko. Diese Schere schließt sich nicht von allein. Manche werden sie bewusst schließen. Die meisten werden sie vermessen, wenn es so weit ist.
Es lohnt sich, die Antwort zu kennen, bevor die Frage gestellt wird.