In Teil 6 dieser Serie – Die Risiko-Staffel gegen den Kontrollverlust beim Agenten – sind dir drei Zonen begegnet, in denen die Kosten-Rechnung versagt: die Irreversibilität, das genuin Unbekannte, und die Frage, ob die Spec überhaupt das Richtige will. Ich habe sie Vorboten genannt. Jetzt löse ich das ein.
Denn zwei dieser Zonen sind mehr als Stellen, an denen man anders rechnet. Sie sind Stellen, an die keine Verifikation je hinreicht, egal wie viel Käfig du baust. Zusammen mit einem dritten Grund, den Teil 6 noch gar nicht brauchte, markieren sie einen Rest, der nicht schrumpft, weil dein Werkzeug zu billig wäre, sondern weil er sich prinzipiell keiner Maschine beugt. (Die dritte Zone, die Irreversibilität, hebe ich mir für den Schluss auf.)
Über diesen Rest reden wir jetzt. Und über die gute Nachricht, die in ihm steckt.
Drei Gründe, und keiner ist ein Werkzeug-Problem
Der Rest ist kein Tooling-Gap, den die nächste Werkzeug-Generation schließt. Er hat drei Wurzeln, und alle drei liegen tiefer als jedes Gate.
- Die Spec könnte das Falsche wollen. Das ist die Grenze, die sich durch die ganze Serie zieht. Jede Verifikation prüft den Code gegen eine Spezifikation. Aber was prüft, ob die Spezifikation den richtigen Zweck trifft? Du kannst eine Spec sauber, widerspruchsfrei und vollständig machen, das alles lässt sich gaten. Ob sie das beschreibt, was eigentlich gemeint war, kann dir keine Maschine sagen. Das endet bei menschlichem Urteil, und es endet dort nicht aus Bequemlichkeit, sondern weil „das Richtige“ außerhalb des Systems liegt, gegen das geprüft wird.
Faustregel 5: Das falsche Problem perfekt lösen ist trotzdem Ausschuss. Kein automatisches Gate fängt das. Verifikation fragt „ist es richtig gebaut?“ und lässt sich erzwingen; Validierung fragt „ist es das Richtige?“ und endet bei dir. Das ist die eine Faustregel, die in dieser Serie keinen eigenen Mechanismus bekommt, weil es keinen geben kann.
- Die meisten interessanten Eigenschaften sind nicht mechanisch entscheidbar. Dahinter stehen zwei verschiedene Grenzen, die im selben Spalt enden.
- Die erste ist prinzipiell: ein altes Ergebnis der Informatik, der Satz von Rice, und du brauchst die Mathematik dahinter nicht, um die Pointe zu verstehen. Für nicht-triviale Aussagen über das Verhalten eines Programms gibt es kein Verfahren, das sie für jeden Fall zuverlässig beantwortet. Es gibt also gar keinen Algorithmus, der die Frage im Allgemeinen entscheidet.
- Die zweite ist praktisch: Tests umgehen die erste Grenze nicht etwa durch Beweis, sondern indem sie Stichproben nehmen. Ein grüner Test sagt „an den geprüften Stellen stimmt es“, nie „es stimmt überall“. Rice sagt, ein vollständiges Verfahren kann es nicht geben; die Stichprobe sagt, das, was wir stattdessen tun, bleibt endlich und damit lückenhaft. Für die meisten Eigenschaften lässt sich dieser Spalt durch genug Stichproben beliebig klein machen, aber nie auf null, und du weißt nie sicher, welche Eigenschaft die Ausnahme ist. Verifikation sampelt, sie beweist nicht. Genau in diesem Spalt bleibt der Rest.
- Den genuin neuen Fehler kennst du noch nicht. Ein Gate prüft eine antizipierte Fehlerklasse. Du baust es, weil du weißt, dass dieser Fehler vorkommen kann. Den Fehler, an den niemand gedacht hat, kann kein Gate fangen, bevor er das erste Mal auftaucht, meist in Produktion. Das ist keine Schwäche deiner Gates, das ist die Natur des Unbekannten: Was du noch nicht kennst, kannst du nicht vorab umzäunen.
Drei verschiedene Wurzeln, ein gemeinsames Ergebnis. Der Rest ist klein, aber er ist hart. Du kommst nicht unter ihn, indem du besser baust.
Der Rest ist kein Makel, er ist eine Adresse
Denn der Rest ist nicht das, was übrig bleibt, weil etwas misslungen ist. Er ist der Ort, an den der Mensch gehört.
Faustregel 10: Es bleibt ein uneliminierbarer Rest. Und der ist der richtige Platz für den Menschen.
Drei Dinge sitzen in diesem Rest, und alle drei sind menschlich, nicht aus Verlegenheit, sondern weil es niemand sonst kann. Erstens: den Intent verantworten, also entscheiden, was überhaupt das Richtige ist. Zweitens: das genuin Neue beurteilen, den Fall, für den es noch kein Muster und kein Gate gibt. Und drittens, das wird am leichtesten übersehen: die Pflege des Käfigs selbst.
Erwarte hier keine saubere Eins-zu-eins-Deckung mit den drei Wurzeln von oben. Zwei der Aufgaben entsprechen direkt einer Wurzel: den Intent verantworten der Spec-Validität, das Neue beurteilen dem genuin Neuen. Die Sampling-Wurzel hat keine eigene Aufgabe, weil man gegen sie nichts tun kann, nur mit ihr leben. Und die Pflege des Käfigs entspringt keiner der drei Wurzeln direkt; sie ist die Meta-Aufgabe, die über allen anderen steht, weil sie den Apparat in Ordnung hält, der die anderen beiden überhaupt erst trägt.
Denn der Käfig wird vom Agenten gebaut, aber er gehört dem Menschen. Und er wird nie fertig. Das habe ich in dieser Serie nicht behauptet, sondern erlebt. In Obol fing der Typecheck die Testdateien zuerst gar nicht. Das Dead-Code-Gate war konfiguriert und biss trotzdem nicht. Ein Merge-Gate behandelte später jede Änderung als hochriskant und erstickte damit den Durchsatz, den die Risiko-Staffel kaufen sollte. Jedes Mal war der Wächter selbst der Defekt, und jedes Mal hat ihn kein Agent gefunden, sondern ein Mensch, der die Änderung am Käfig misstrauisch las. Die Wachsamkeit, die nicht delegierbar ist, gilt genau diesen Käfig-Diffs: klein in der Menge, aber die gefährlichsten Änderungen im ganzen Repo, weil sie das Gesetz ändern, nach dem alles andere geprüft wird.
Das ist die Arbeit, die bleibt. Nicht weniger anspruchsvoll als vorher, sondern konzentrierter.
Eskalation ist kein Fehlerfall
Wenn der Rest der richtige Sitz des Menschen ist, braucht das System eine Stelle, an der es den Rest auch abgibt. Sonst verschwindet er still: Der Agent dreht endlos weiter, oder er nimmt die billige Abkürzung und würgt das rote Signal ab, statt es zu lösen. Diese Stelle ist die Eskalation, und sie ist kein Notausgang, sondern ein geplanter Übergabepunkt.
Vier Auslöser, an denen die Autonomie endet und der Mensch übernimmt:
- Der Loop konvergiert nicht. Maximale Iterationen erreicht, kein Fortschritt. Meist steckt dahinter ein Intent-Problem oder ein harter Defekt, kein Grund für den hundertsten Versuch.
- Die Änderung ist irreversibel. Eine Migration, ein Auth-Pfad, ein publiziertes Event. Grünes Gate reicht hier strukturell nicht, ein Mensch nimmt ab.
- Etwas genuin Neues taucht auf. Kein Gate vorhanden, weil die Fehlerklasse neu ist.
- Es gibt echte Uneinigkeit über den Intent. Das System macht den Konflikt sichtbar, es entscheidet ihn nicht.
Diese vier sind kein Zufall, auch wenn sie sich nicht sauber auf die drei Wurzeln von oben abbilden lassen. Grob wieder erkennst du sie: „genuin Neues“ ist die Neu-Wurzel, „Uneinigkeit über den Intent“ die Spec-Wurzel, „irreversibel“ die dritte Zone aus Teil 6, die ich mir aufgehoben habe. Der erste Auslöser, „der Loop konvergiert nicht“, ist keine eigene Wurzel, sondern ein Symptom: das betriebliche Warnlicht, hinter dem meist ein Intent-Problem oder ein harter Defekt steckt. Es sind also betriebliche Trigger, keine Eins-zu-eins-Übersetzung der prinzipiellen Gründe. Eskalation ist der Mechanismus, der den Rest dorthin trägt, wo er hingehört, sauber, mit Kontext, an einen benannten Menschen, statt als hektischer Abbruch. Wann genau der Loop von „nochmal“ auf „übergib“ kippt, ist übrigens nichts, was man sich ausdenkt. Das misst man am laufenden System, und in Obol wird diese Schwelle noch justiert.
Dass das keine Theorie ist, hat Obol inzwischen einmal komplett gezeitgt.
Das erste echte Feature lief den ganzen Weg: aus der Spezifikation wurden Tests, daraus Code, durch alle Gates, am Ende der Merge. Und der Mensch tauchte dabei an genau zwei Stellen auf, nicht zufällig, sondern an den beiden, die dieser und der vorige Teil vorhersagen: einmal vorne, beim Review der Spec, wo über den Intent entschieden wird, und einmal hinten, beim unabhängigen Review vor dem Merge. Dazwischen lief die Maschine allein. Das ist der Rest in Aktion: nicht überall ein Mensch, sondern an den zwei Punkten, an denen es keiner sonst kann.
Und inzwischen hat der Käfig auch das Gegenstück gezeigt, das Abgeben. Bei einem späteren Feature saß ein Defekt nicht im Code, sondern in einer Testvorrichtung, die der Loop nicht selbst reparieren durfte. Nach ein paar fruchtlosen Runden ging die Sache an einen Menschen und wurde über einen frischen Spezifikationslauf korrigiert. Eskalation ist eben kein Abbruch, sondern der vorgesehene Übergabepunkt.
Art gegen Menge
Ein naheliegender Einwand: Vibe-Coding, das ziellose Drauflosprompten ohne Käfig, hat doch auch nur diesen Rest. Stimmt. Der Art nach ist es derselbe Rest. Der Menge nach ein Abgrund.
Genau das ist der ganze Unterschied. Ohne Käfig ist fast alles ungeprüft, der Rest ist riesig und niemand weiß, wo er liegt. Mit Käfig schrumpft er auf einen winzigen, klar umrissenen Kern, und du weißt genau, was in ihm steckt: die drei Wurzeln, sonst nichts. Der Käfig eliminiert den Rest nicht, das kann er nicht. Er konzentriert ihn auf den kleinsten und wertvollsten Punkt. Das ist nicht ein Nebeneffekt des Vorgehens. Das ist das ganze Spiel.
Der Doppelstandard, den wir uns leisten
Es lohnt, einmal innezuhalten und zu fragen, was wir da eigentlich vom Agenten verlangen.
Das ist der Satz, der schon in Teil 1 stand und auf den die ganze Serie zugelaufen ist. Verifizierbar statt fehlerlos. Nicht ein abgeschwächter Anspruch, sondern der einzige, der überhaupt einlösbar ist, bei Maschinen wie bei Menschen.
Der Anspruch an die Maschine ist nicht höher als an den Menschen, er ist anders.
In vielem verlangen wir vom Agenten sogar weniger: ein eng umrissenes Ticket, keine Systemverantwortung, keine Stakeholder-Gespräche. Aber an einer Stelle erwarten viele insgeheim etwas Seltsames, das sie von keinem menschlichen Entwickler erwarten würden: fehlerlose Programme. Bei Menschen vertrauen wir nie auf Fehlerlosigkeit, sondern auf Rechenschaft (jemand ist verantwortlich), Urteil (jemand kann eine neue Lage einschätzen) und Korrigierbarkeit (Fehler werden gefunden und behoben). Dem Agenten fehlt dieser soziale Unterbau. Also ersetzen wir soziales Vertrauen durch systemisches, durch den Käfig. Die richtige Forderung an ihn lautet deshalb nie „sei fehlerlos“, sondern „sei verifizierbar“.
Den Rest managen, nicht schließen
Wenn der Rest bleibt, ist die Frage nicht, wie du ihn schließt, sondern wie du mit ihm lebst.
Die Antwort ist eine Verschiebung der Prüfung in die Zeit nach dem Merge. Was kein Gate vorab fangen konnte, fängt die Beobachtung des laufenden Systems hinterher. Ein Verhalten, das in Produktion auffällt, ist ein neuer, eben erst sichtbar gewordener Fehlertyp. Und der wandert zurück nach vorn: Aus dem Vorfall wird ein neues Gate, das genau diese Klasse ab jetzt abfängt. Der Käfig wächst mit dem, was die Wirklichkeit ihm beibringt. Du sagst nie „das ist korrekt“. Du sagst „das hat alles bestanden, was wir zu prüfen wussten, und für den Rest steht ein Mensch gerade“.
Und eine Versuchung musst du dir dabei verkneifen, die schon in Teil 6 lauerte: Du schließt den Rest nicht, indem du noch einen Prüfer obendrauf stapelst. Eine zusätzliche Schicht, die mit den vorigen korreliert, liefert fast kein neues Signal. Der letzte Halt ist kein weiteres Gate, er ist menschlich. Das ist kein geschlossener Beweis, der Mensch am Ende ist fehlbar wie alles andere, er ist ja der Grund, warum die ganze Maschinerie überhaupt existiert. Es ist nur die Stelle, an der Fehlbarkeit mit Rechenschaft zusammenfällt, und das ist das Beste, was zu haben ist. Rechenschaft heißt hier nichts Abstraktes: Es ist der Mensch, der den Merge freigibt und mit seinem Namen an der Käfig-Diff steht, der Code-Owner, der Reviewer vor dem Merge, die Rolle, die haftet, wenn es schiefgeht. Kein Agent kann diesen Namen tragen.
(Dass derselbe Käfig nebenbei auch von Hand geschriebenen Code besser macht und ein Team aus KI-Skeptikern und KI-Fans am selben Standard zusammenbringt, ist eine eigene Geschichte. Sie steht im Begleitartikel dieser Serie.)
Was ich nicht behaupte
Bevor das alles zu rund klingt, drei Einwände, die ich nicht auflöse.
Der erste, der naheliegende: Ist „der Mensch rückt an die wertvollste Stelle“ nicht bloß Beförderung durch Umdeutung? Zum Teil doch. Das Revier wird kleiner, daran ändert keine schöne Formulierung etwas. Was bleibt, ist nicht mehr Arbeit, sondern verdichtetere Verantwortung. Ob ein kleiner, harter Rest ein ganzes Berufsbild trägt, ist eine offene Frage, keine entschiedene.
Der zweite: „prinzipiell uneliminierbar“ ist nicht dasselbe wie „praktisch wichtig“. Vielleicht werden die Modelle so gut, dass der Rest unter die Schwelle fällt, ab der sich ein menschlicher Wächter überhaupt lohnt. Möglich. Nur verschwinden die drei Wurzeln dadurch nicht, sie werden seltener sichtbar. Und das macht den verbliebenen Fall teurer, nicht billiger, weil ihn dann niemand mehr erwartet.
Der dritte, der ehrlichste: Dieser ganze Käfig, sieben Teile Gates, Staffeln, Eskalation, ist für ein kleines Team mit Deadline nicht über Nacht baubar. Die Frage ist dort nicht „ob überhaupt“, sondern „wie wenig genügt“. Auch darauf gibt diese Serie keine fertige Antwort, nur eine Richtung.
Alle Teile aus dieser Serie
Teil 1 · 11 Min.Warum bessere Prompts deinen KI-Code nicht retten
Teil 2 · 12 Min.Spec-Driven Development, oder: EARS vs. Vibe Coding
Teil 3 · 16 Min.Mutation Testing bei KI-Agenten: Wer hält das Schloss?
Teil 4 · 12 Min.Merge Queue für KI-Agenten
Teil 5 · 17 Min.Blast Radius – was dein Agent anrichtet, wenn er nicht mehr dir gehört
Teil 6 · 16 Min.Die Risiko-Staffel gegen den Kontrollverlust beim Agenten
Teil 7 · 14 Min. · Du liest geradeWo die Dark Factory das Licht anlässt
Die Lichter gehen aus, aber nicht alle
So schließt sich die Klammer, die Teil 1 geöffnet hat. Über agentisches Coden wurde aus zwei Richtungen geredet, Performancegewinn von den einen, Qualitätsverfall von den anderen, und beide hatten recht. Du bekommst beides, aber nicht, indem du auf einen besseren Generator hoffst, sondern indem du das System darum herum baust: Intent nach oben, Korrektheit nach unten, Fakten nach vorn, und den Menschen an den einen Punkt, an dem er unersetzlich ist.
Am Anfang, in Teil 1, stand das Bild der „Dark Factory“: die Fabrik, in der das Licht ausbleibt, weil gar kein Mensch mehr im Betrieb steht und Maschinen keines brauchen. Für Software ist das, je nach Blickwinkel, ein Versprechen oder eine Drohung. Diese ganze Serie war, von Anfang an, die Bauanleitung für die verantwortbare Form dieser Fabrik. Und hier ist ihr Schlusssatz, der zugleich die dritte Zone aus Teil 6 einlöst: Die Lichter gehen aus, proportional zur Reversibilität.
Autonomie ist tragbar, solange sich ein Fehler zurücknehmen lässt. Wo eine Änderung reversibel ist, darf der Loop laufen, ohne dass jemand zusieht, dort dürfen die Lichter aus sein. Aber der irreversible Rand, die Migration, die nichts zurücknimmt, das Event, das schon andere Systeme ausgelöst hat, die Zahlung, die raus ist, dieser Rand bleibt beleuchtet. Und genau dort, im Licht, sitzt der Mensch, wobei Reversibilität selten ein sauberer Schalter ist und diese Einschätzung selbst schon zum menschlichen Rest gehört. Nicht „alle Lichter aus“, sondern „aus, wo es reversibel ist, an, wo es das nicht ist“. Der Mensch verschwindet in dieser Fabrik nicht, er rückt an die Stelle, die übrig bleibt, wenn die Maschine alles Prüfbare übernommen hat: zu entscheiden, was gebaut werden soll, das wirklich Neue zu beurteilen, über dem Käfig zu wachen. Kleiner als früher, ja. Aber es ist die Arbeit, die am wenigsten verzeiht, wenn man sie schlecht macht.
Das ist kein Trostpreis. Es ist der Teil der Arbeit, der sich nie wegautomatisieren ließ, und der auch nie der schlechteste war. Du nennst dein System nie fehlerlos. Du machst es verifizierbar, und den Rest verantwortest du selbst.
Bleibt eine letzte Ehrlichkeit, die diese Serie sich selbst schuldet. Sieben Teile lang sagt sie: Nenn nichts korrekt, nur verifizierbar. Dieselbe Regel gilt für sie selbst. Dass der Rest bleibt und dem Menschen gehört, ist kein Beweis. Es ist die beste Wette, die ich Stand heute abgeben kann, geprüft an dem, was wir bisher gesehen haben, und offen für die Daten von morgen. Und falls sie kippt, dann vermutlich nicht so, wie die Angst es sich ausmalt. Nicht, weil eine Maschine eines Tages die wirklich wichtige Entscheidung besser trifft als jeder Mensch. Sondern weil wir aufhören, sie selbst treffen zu wollen, und den Platz freiwillig räumen. Ob der wichtigste Teil dem Menschen gehört, entscheidet am Ende keine Technologie. Das entscheiden wir.
War’s das jetzt?
In Teil 4 der Serie habe ich eine Aussage offen stehen lassen: Der Loop prüft die Treue zur Spec, nicht, ob die Spec das Richtige will. Tja – so ganz unkommentiert möchte ich das nicht lassen. Doch dazu mehr, wenn wir uns nächste Woche mit dem Digital Twin beschäftigen.
Doch auch danach habe ich noch ein paar Kleinigkeiten. Zum einen habe ich noch einen Begleitartikel geschrieben, der sich mit mit der allgemeinen Situation der KI-gestützten Code-Generierung beschäftigt, zum anderen habe ich noch ein ausführliches Tutorial in Petto, das zeigt, wie sich das bisher gezeigte in der Praxis umsetzen lässt.


Schreibe einen Kommentar