Es gibt einen vernünftigen Einwand gegen das ganze Reden über neu gedachte Prozesse und Rollen, und man sollte ihn ernst nehmen, denn in den meisten Fällen hat er recht. Wer vorschlägt, den Prozess zu überarbeiten, schlägt fast immer vor, langsamer zu werden. Er fügt einen Genehmigungsschritt hinzu, ein Dokument zum Ausfüllen, ein Gremium, das sich donnerstags trifft, und er tut es im schlechtesten Moment, nämlich wenn ein Team endlich einen Rhythmus gefunden hat. Jede Methodik der letzten dreißig Jahre trat als Qualität auf und wurde als Bürokratie ausgeliefert. Die Governance-Seiten zur künstlichen Intelligenz, die in den letzten zwei Jahren entstanden sind, sind großenteils Theater, und sie dienen dazu, in einer Vorstandssitzung sagen zu können, das Thema sei abgedeckt. Wenn jemand mit einem Vorschlag zur Neuordnung in der Hand auftaucht, ist das Misstrauen gesund.
Ein Fehler, der keine Exception auslöst
Was der Einwand nicht abdeckt, ist eine Klasse von Fehlern, die keine Fehlermeldung erzeugt. Sie erzeugt kein Ticket, lässt keine Pipeline scheitern, erscheint auf keinem Dashboard. Das Symptom hat nicht die Form eines Vorfalls, sondern die eines Satzes in der Retrospektive, meist im dritten oder vierten Monat der Arbeit mit einem agentischen Werkzeug, wenn jemand feststellt, das Modell sei schlechter geworden.
Die naheliegende Lesart ist, der Anbieter habe etwas verschlechtert, oder die anfängliche Begeisterung sei aufgeblasen gewesen. Fast nie ist es so gelaufen. Gelaufen ist es so: die Anweisungsdatei des Projekts ist über die Schwelle hinaus gewachsen, an der der Agent noch alles zusammenhalten kann, und hat begonnen, die Hälfte auszusortieren, auf die es ankam. Oder die Beschreibung eines automatischen Ablaufs ist von Umformulierung zu Umformulierung gedriftet, bis sie bei allem auslöst, was gleichbedeutend damit ist, bei nichts mehr auszulösen. Keiner der beiden Fehler löst eine Exception aus. Für ein Gerüst, das sich auflöst, gibt es keinen Stack Trace, und ohne Fehlermeldung schreibt das Team den Einbruch dem Werkzeug zu statt der eigenen Konstruktion.
Der Status der persönlichen Konfiguration
Das ist die erste Erscheinungsform eines Prinzips, das man, sobald man es gesehen hat, an drei oder vier verschiedenen Stellen desselben Unternehmens wiedererkennt. Was leise verfällt, ist genau das, was niemand prüfen muss.
Anwendungscode hat eine Verteidigung gegen stillen Verfall, und die Verteidigung ist, dass jemand einen Test geschrieben hat, der wütend wird. Die Anweisungen, mit denen wir einen Agenten steuern, die gespeicherten Prompts, die Projektkonventionen, die Automatisierungen, die von selbst auslösen sollten, all dieses Material, das in den letzten zwei Jahren zur Produktionsinfrastruktur geworden ist, hat den Status der persönlichen Konfiguration geerbt. Es lebt im Ordner eines Projekts ohne erklärten Eigentümer, ohne Changelog, ohne jemanden, der für seine Wartung haftet. In der Praxis heißt das: das jüngste und fragilste Gerüst der ganzen Lieferkette ist auch das einzige, das wir nicht unter Prüfung gestellt haben.
Das Wort „fertig“
Die zweite Erscheinungsform betrifft ein Wort, das im Unternehmen als definiert gilt und es nicht ist. Das Wort ist „fertig“. Anderthalb Jahre generative Werkzeuge haben viel beschleunigt, und am meisten beschleunigt haben sie die Fertigmeldung. Ein Agent kommt am Ende einer Aufgabe mit einer Zuversicht an, die in der Prüfung keine Entsprechung hat, und der Satz, mit dem er abschließt, ist von dem einer wirklich abgeschlossenen Arbeit nicht zu unterscheiden.
Steht die Definition von fertig in Prosa, auf einer Seite interner Konventionen, die alle einmal gelesen haben, wird sie eingehalten, wenn Zeit da ist, und übersprungen, wenn keine da ist, also wenn es darauf ankommt. Sie wird nicht aus Nachlässigkeit übersprungen. Sie wird übersprungen, weil eine Regel in Prosa immer mit einer Lieferung konkurriert, die ein Datum hat, und immer verliert. Der Unterschied zwischen einer geschriebenen Regel und einer deterministischen Prüfung, die die Fertigmeldung blockiert, wenn eine Quelldatei nach dem letzten erfolgreichen Test geändert wurde, ist kein Unterschied in der Strenge. Es ist der Unterschied zwischen einer Absicht und einer Schranke, und unter Druck überlebt nur die zweite.
Die Kosten sind dabei nicht verschwunden, sie haben sich verschoben. Verschoben in die Review, in das Rework, in das Wiederöffnen bereits als geschlossen markierter Aufgaben, und in keiner dieser drei Positionen misst sie jemand, weil die Metrik, auf die wir schauen, weiterhin die Geschwindigkeit ist, mit der Dinge für fertig erklärt werden.
Das Inventar, das niemand mitten im Sprint neu erzeugt
Die dritte Erscheinungsform kenne ich am besten, weil ich seit Jahren mit Kunden im Gesundheitswesen und in der öffentlichen Verwaltung arbeite, wo Konformität kein Reputationsthema ist, sondern eine Zulassungsbedingung. Regulatorische Konformität scheitert nicht an Unwissenheit. Niemand, in keinem Unternehmen, das in den letzten drei Jahren eine Ausschreibung gelesen hat, zweifelt daran, dass eine Software-Stückliste gebraucht wird. Der Punkt ist, dass sie niemand mitten im Sprint neu erzeugt, weil nichts diesen Moment erzwingt: es gibt ein Release abzuschließen, und das Neuerzeugen des Abhängigkeitsinventars konkurriert mit diesem Release um die Aufmerksamkeit von jemandem und verliert, jedes Mal, bis zu dem Tag, an dem ein Auditor danach fragt und es nicht existiert. Ich habe das ausführlicher begründet, indem ich gezeigt habe, dass Compliance nicht an fehlenden Normen scheitert, und seither kein einziges Gegenbeispiel gefunden.
Der Fehler ist mit den beiden vorigen identisch. Es ist keine Kompetenzlücke, es ist das Fehlen eines erzwungenen Moments. Der Unterschied ist, dass die Uhr hier öffentlich und nicht verhandelbar läuft: die Meldepflichten für Schwachstellen des Cyber Resilience Act gelten ab dem 11. September 2026, die Verordnung gilt vollständig ab dem 11. Dezember 2027, und der European Accessibility Act ist bereits seit dem 28. Juni 2025 in Kraft. Die Reibung, die bis gestern eine rhetorische Figur in einer Besprechung kostete, kostet ab jetzt eine Nichtkonformität.
Kapazität kaufen statt diagnostizieren
Eine vierte Erscheinung lohnt die Erwähnung, kleiner, aber diagnostisch, weil sie zeigt, wie leicht man das Mittel verfehlt. Wenn ein Team gegen die Nutzungsgrenzen agentischer Werkzeuge stößt, lautet der unmittelbare Schluss, es brauche einen größeren Plan oder ein anderes Modell. In der großen Mehrheit der Fälle ist der Kostentreiber nicht das gewählte Modell, sondern der Kontext, der sich in einer langen Sitzung angesammelt hat, und die Lösung liegt nicht im Einkauf, sondern darin, wie die Arbeit aufgeteilt wird.
Es ist derselbe Fehler in kleinerem Maßstab: vor einem unsichtbaren Fehler kaufen wir Kapazität, statt den Mechanismus zu diagnostizieren, weil der Kauf von Kapazität eine Handlung ist, die man in zehn Minuten beschließen kann, und die Diagnose eines Mechanismus nicht.
Wer Nein sagen kann
Von hier an hört die Frage auf, technisch zu sein, und wird eine Frage der Rollen, und darum finde ich sie interessant. Wenn sich der Engpass von der Produktion zur Prüfung verschiebt, ist die knappe Ressource nicht mehr, wer schnell schreibt. Es ist, wer mit einer Begründung Nein sagen kann, und wer es zu einem Artefakt sagen kann, das ganz danach aussieht, korrekt zu sein. Es ist dieselbe Wertwanderung, die ich anderswo Spezifikationsschulden genannt habe, nur von der Ausgangs- statt von der Eingangsseite betrachtet.
In kleinen Teams erzeugt das einen Effekt, den ich von nahem gesehen habe: eine Junior-Person, begleitet von einem Agenten, liefert Output mit der Oberfläche einer Senior-Arbeit, ohne das Urteilsvermögen, das mit dieser Oberfläche üblicherweise kommt, und die Prüflast konzentriert sich auf zwei oder drei Personen, die zur Schranke für alles andere werden. Die instinktive Reaktion ist, diese zwei oder drei Personen zu bitten, schneller zu prüfen. Die richtige Reaktion ist, sich zu fragen, welcher Teil ihres Urteils in Wahrheit eine Regel war, die nie jemand aufgeschrieben hat, und sie in einer Form aufzuschreiben, die von selbst auslöst.
Schulung und Boden sind zwei Investitionen
Hier trennen sich Schulung und Baseline, und sie müssen als zwei getrennte Investitionen finanziert werden, weil sie unterschiedliche Fragen beantworten. Schulung hebt die Menschen, erweitert, was sie sehen können, verschiebt jemanden von der Ebene der Ausführung auf die der Spezifikation und der Prüfung. Aber Schulung erzeugt Ergebnisse oberhalb eines Bodens, und in einem Team von zehn Personen existiert dieser Boden nicht von selbst. Er existiert nur, wenn ihn jemand baut, unter Versionskontrolle stellt und als gepflegtes Artefakt behandelt statt als Ordner mit Notizen.
Ohne diesen Boden darunter bleibt das Heben der Menschen eine Aussage für institutionelle Präsentationen: jeder arbeitet auf seinem eigenen Niveau an Strenge, die Varianz zwischen einer Lieferung und der nächsten hängt davon ab, wer sie übernommen hat, und niemand kann eine Verbesserung durch Methode von einer Verbesserung durch eine einzelne, besonders gewissenhafte Person unterscheiden. Der Boden ist nicht dazu da, gute Leute zu begrenzen. Er ist dazu da, ihren Beitrag sichtbar zu machen, der sonst im Rauschen aufgeht.
Was keine Maschine für gültig erklären kann
Es bleibt ein letzter Schritt, und er nimmt den Punkt wieder auf, von dem ich vor einigen Tagen ausgegangen bin, als ich über die Ebene, die sich nicht delegieren lässt, geschrieben habe. Diese ganze Architektur automatischer Prüfungen hat eine strukturelle Grenze, und die Grenze ist, dass keine von ihnen ihr eigenes Ergebnis für gültig erklären kann. Eine Maschine kann inventarisieren, kann erzeugen, kann eine Lücke melden, kann eine Fertigmeldung blockieren. Was sie nicht kann, ist ihre eigene Arbeit als angenommen, konform oder validiert zu markieren, und nicht, weil das technisch unmöglich wäre, sondern weil in dieser Geste das Einzige liegt, was eine Rechtsordnung anerkennt, nämlich eine Person, die dafür haftet. Darin hat die europäische Regulierung längst aufgehört, eine Meinung zu sein, und begonnen, das Organigramm an unserer Stelle zu schreiben.
Der Wert liegt nicht darin, mehr Artefakte zu erzeugen, sondern Nachweise statt Vertrauen. Ein Bericht, der zu jedem Punkt vorhanden, Lücke oder nicht anwendbar sagt, mit einem Verweis oder einer Begründung, ist in einem Verfahren verwendbar. Ein Bericht, der sagt, es sehe alles in Ordnung aus, ist es nicht, und der Unterschied zwischen beiden ist keiner des Tons, sondern der Verwertbarkeit.
Deshalb habe ich die Baseline, die ich verwende, unter MIT-Lizenz als Open Source veröffentlicht: dreizehn Verfahren plus eine Prüfung, die am Ende der Sitzung die Fertigmeldung blockiert, wenn eine Quelldatei nach dem letzten erfolgreichen Test geändert wurde. Es gibt die Tests, die die Verfahren prüfen, 1.111 Prüfungen in neunzehn Suiten, und ein Testrepository, das absichtlich so gebaut ist, dass es an jeder Oberfläche scheitert, die das Audit des Gerüsts kontrolliert, denn ein Gerüst, dessen Festigkeit behauptet und nicht gezeigt wird, fällt genau in die Fehlerklasse, die es verhindern soll. Es liegt auf oltrematica.github.io/oltrematica-skills, und wer will, kann es Zeile für Zeile bestreiten, was die einzige seriöse Art ist, so etwas anzubieten.
Zwei Fragen für die Geschäftsführung
Der Teil, der einer Geschäftsführung nützt, ist aber nicht das Repository. Es sind zwei Fragen für die Tagesordnung der nächsten Leitungssitzung, und ihr Nutzen liegt darin, dass die Antwort keine Voruntersuchung braucht.
Die erste: wer im Unternehmen ist verpflichtet zu prüfen, dass unser Gerüst noch funktioniert, und mit welchem Nachweis. Die zweite: wie viel von dem, was wir heute fertig nennen, wird von einer Schranke gehalten und wie viel von einer Absicht. Wenn der ersten kein Name entspricht und der zweiten keine Prüfung, ist das kein Werkzeugproblem, und kein Einkauf wird es lösen.
Was du mitnimmst
Es gibt eine Klasse von Fehlern, die keine Fehlermeldung erzeugt: eine Anweisungsdatei, die über die Aufmerksamkeitsschwelle des Agenten gewachsen ist, die Beschreibung einer Automatisierung, die bis zum Auslösen bei allem gedriftet ist. Für ein Gerüst, das sich auflöst, gibt es keinen Stack Trace, und ohne Fehlermeldung beschuldigt das Team das Modell.
Was ohne Lärm verfällt, ist genau das, was niemand prüfen muss. Anwendungscode hat eine Verteidigung gegen stillen Verfall, und diese Verteidigung ist ein Test, der wütend wird. Die Anweisungen, mit denen wir Agenten steuern, haben den Status der persönlichen Konfiguration geerbt: kein Eigentümer, kein Changelog, keine Wartung.
Eine in Prosa geschriebene Definition von „fertig“ konkurriert immer mit einer Lieferung, die ein Datum hat, und verliert immer. Eine deterministische Prüfung, die die Fertigmeldung blockiert, wenn eine Quelldatei nach dem letzten erfolgreichen Test geändert wurde, ist nicht strenger: sie ist eine Schranke statt einer Absicht, und unter Druck überlebt nur die Schranke.
Schulung und Baseline sind zwei getrennte Investitionen. Schulung erzeugt Ergebnisse oberhalb eines Bodens, und in einem Team von zehn Personen existiert dieser Boden nicht von selbst: er existiert, wenn ihn jemand baut, versioniert und pflegt. Ohne diesen Boden darunter hängt die Varianz zwischen zwei Lieferungen davon ab, wer sie übernommen hat.
Keine automatische Prüfung kann ihr eigenes Ergebnis für gültig erklären, und das nicht aus technischen Gründen: in dieser Geste liegt das Einzige, was eine Rechtsordnung anerkennt, nämlich eine Person, die dafür haftet. Der Wert liegt nicht darin, mehr Artefakte zu erzeugen, sondern Nachweise statt Vertrauen.
Fragen & Antworten
Warum ist Misstrauen gegenüber Vorschlägen zur Prozessüberarbeitung gesund?
Weil meistens vorgeschlagen wird, langsamer zu werden, und zwar im schlechtesten Moment, wenn ein Team endlich einen Rhythmus gefunden hat. Jede Methodik der letzten dreißig Jahre trat als Qualität auf und wurde als Bürokratie ausgeliefert, und ein guter Teil der KI-Governance-Seiten der letzten zwei Jahre existiert, damit jemand in einer Vorstandssitzung sagen kann, das Thema sei abgedeckt. Das Misstrauen ist gesund. Es deckt nur die Fehler nicht ab, die keine Fehlermeldung erzeugen.
Warum scheint ein Agent nach einigen Monaten schlechter zu werden?
Fast nie, weil der Anbieter das Modell verschlechtert hat. Häufiger ist die Anweisungsdatei des Projekts über die Schwelle gewachsen, an der der Agent noch alles zusammenhalten kann, und hat begonnen, die Hälfte auszusortieren, auf die es ankam; oder die Beschreibung eines automatischen Ablaufs ist von Umformulierung zu Umformulierung gedriftet, bis sie bei allem auslöst, was gleichbedeutend damit ist, bei nichts mehr auszulösen. Keiner der beiden Fehler löst eine Exception aus, und ohne Fehlermeldung wird der Einbruch dem Werkzeug zugeschrieben statt dem Gerüst.
Welchen Unterschied macht eine deterministische Prüfung gegenüber einer geschriebenen Regel?
Eine Regel in Prosa, etwa eine Definition von „fertig“ auf einer Seite interner Konventionen, wird eingehalten, wenn Zeit da ist, und übersprungen, wenn keine da ist, also wenn es darauf ankommt. Nicht aus Nachlässigkeit: weil sie immer mit einer Lieferung konkurriert, die ein Datum hat, und immer verliert. Eine Prüfung, die die Fertigmeldung blockiert, wenn eine Quelldatei nach dem letzten erfolgreichen Test geändert wurde, ist kein Unterschied in der Strenge, sondern der Unterschied zwischen einer Absicht und einer Schranke. Unter Druck überlebt nur die zweite, und die scheinbar gesparten Kosten wandern in Review, Rework und das Wiederöffnen bereits geschlossener Aufgaben.
Warum erzeugt niemand das Abhängigkeitsinventar mitten im Sprint neu?
Nicht aus Unwissenheit. Kein Unternehmen, das in den letzten drei Jahren eine Ausschreibung gelesen hat, zweifelt daran, dass eine Software-Stückliste gebraucht wird. Der Punkt ist, dass nichts diesen Moment erzwingt: es gibt ein Release abzuschließen, und das Neuerzeugen des Inventars konkurriert mit diesem Release um die Aufmerksamkeit von jemandem und verliert, jedes Mal, bis zu dem Tag, an dem ein Auditor danach fragt und es nicht existiert. Der Unterschied zu den anderen Fehlern: hier ist die Uhr öffentlich. Die Meldepflichten für Schwachstellen des Cyber Resilience Act gelten ab dem 11. September 2026, die Verordnung gilt vollständig ab dem 11. Dezember 2027, und der European Accessibility Act ist seit dem 28. Juni 2025 in Kraft.
Warum sollten Schulung und Baseline getrennt finanziert werden?
Weil sie unterschiedliche Fragen beantworten. Schulung hebt die Menschen, erweitert, was sie sehen können, verschiebt jemanden von der Ausführung zur Spezifikation und zur Prüfung. Aber sie erzeugt Ergebnisse oberhalb eines Bodens, und in einem Team von zehn Personen existiert dieser Boden nicht von selbst: er existiert nur, wenn ihn jemand baut, unter Versionskontrolle stellt und als gepflegtes Artefakt behandelt statt als Ordner mit Notizen. Ohne diesen Boden darunter arbeitet jeder auf seinem eigenen Niveau an Strenge, und niemand kann eine Verbesserung durch Methode von einer Verbesserung durch eine einzelne, besonders gewissenhafte Person unterscheiden.
Der Autor
