Die Eingriffsrate: Warum zwei Agenten das neue Limit sind

„Museum of Meaningless Metrics”: Lines of Code, Story Points, Pull Requests, Tokens Spent — und die fünfte Vitrine, reserviert für die Intervention Rate. „Reserved for the next one.”

Es gibt einen Cartoon, der ein „Museum of Meaningless Metrics” zeigt. In den Vitrinen stehen Lines of Code, Story Points und Pull Requests. Das neueste Exponat, stolz auf schwarzem Marmor, ist ein Zähler mit der Aufschrift „Tokens Spent”. Ich schreibe diesen Artikel im vollen Bewusstsein, dass ich gerade eine fünfte Vitrine beantrage. Ob die Eingriffsrate dort landet oder zum echten Steuerungswerkzeug wird, ist die eigentliche Frage. Den Test dafür liefere ich am Ende.

Frag einen Entwickler, der seit ein paar Monaten ernsthaft mit Agenten arbeitet, wie viele er parallel laufen lässt. Die Antwort ist fast immer dieselbe: zwei. An guten Tagen drei. Dann reißt der Faden. Man kommt von einem Agenten zurück und weiß nicht mehr, was man dem anderen vor zwanzig Minuten aufgetragen hat, welche Annahme der dritte gerade trifft und ob das Review von Nummer eins überhaupt noch zur Aufgabe passt.

Das Modell ist dabei selten das Problem. Claude, GPT und Co. liefern. Was nicht skaliert, ist der Mensch davor.

Genau das bestätigt jemand, der es wissen muss. Fiona Fung verantwortet bei Anthropic die Teams hinter Claude Code und Cowork. Im Lenny’s Podcast beschreibt sie das gleiche Phänomen aus dem Maschinenraum des Unternehmens, das die Agenten baut:

„If you have 20 agents running, there’s just endless checking in and reviewing, and you have to remember what you were doing there. … I haven’t cracked it yet.”

Sie hat es nicht gelöst. Anthropic, mit Gratis-Tokens und dem besten Coding-Modell der Welt, hat es nicht gelöst. Das sollte jeden vorsichtig machen, der glaubt, der Sprung von zwei auf zwanzig Agenten sei nur eine Frage des nächsten Tool-Updates.

Der Engpass ist zweimal umgezogen

Die Produktivitätsdebatte um KI-Entwicklung hat in achtzehn Monaten zwei Engpässe hinter sich gelassen.

Zuerst das Schreiben von Code. Lange die knappe Ressource, heute weitgehend erledigt. Anthropic-Engineers liefern im Schnitt das Achtfache an Code pro Quartal verglichen mit 2021 bis 2025. In Vibe Coding haben wir gezeigt, was das für die Build-vs-Buy-Frage bedeutet.

Dann das Review. Sobald die Erzeugung explodierte, wurde der menschliche Reviewer zum Flaschenhals. Spec-basierte Validierung und automatisierte Reviews haben das teilweise entschärft.

Jetzt sitzt der dritte Engpass beim Menschen selbst, und zwar bei seiner Aufmerksamkeit. Je autonomer und asynchroner Agenten arbeiten, desto mehr parallele Vorgänge muss ein Kopf gleichzeitig halten. Fung nennt es „context-switching load”, und sie sieht ihn steigen, nicht fallen. Der Engpass ist von der Tastatur in den Arbeitsspeicher des Menschen gewandert.

Warum bei zwei bis drei Schluss ist

Die Grenze hat einen alten Namen. In der Managementlehre heißt sie Führungsspanne: Eine Führungskraft kann etwa fünf bis sieben Leute eng führen, danach wird Steuerung zu Verwaltung. Bei Agenten liegt die Spanne heute tiefer, weil jeder Agent bei jedem Wiedereinstieg volle Re-Kontextualisierung verlangt. „Wo war ich? Was wollte der? Stimmt das noch?”

Der Kostentreiber ist nicht die Zahl der Agenten. Es sind die Kosten pro Kontextwechsel. Solange jeder Wiedereinstieg teuer ist, hebt auch der schnellste Agent die effektive Spanne nicht. Fung beschreibt die bittere Ironie an sich selbst: Früher blockte sie Fokuszeit, um Kontextwechsel zu vermeiden und programmieren zu können. Heute blockt sie wieder Fokuszeit, diesmal um die async angestoßene Agenten-Arbeit überhaupt noch einzusammeln.

Das KPI: Eingriffsrate

Was sich beschreiben lässt, lässt sich messen. Und was ein Team steuern will, muss es messen. Die zentrale Größe ist die Eingriffsrate (Human Intervention Rate):

Eingriffsrate = Anzahl menschlicher Eingriffe / Anzahl Agenten-Aufgaben

Ein Eingriff ist jedes Mal, wenn ein Mensch einem Agenten noch aktiv etwas sagen muss. Heute liegt das bei nahe 100 Prozent: Kaum eine Aufgabe läuft ohne Nachfragen, Korrekturen oder Freigaben durch. Das Ziel ist eine Kurve nach unten, hin zu einem kleinen, bewusst gewählten Restwert.

Die Gegengröße ist der Autonomiegrad: der Anteil der Aufgaben, die ein Agent von Anfang bis Ende ohne menschlichen Eingriff abschließt. Heute bei den meisten Teams im einstelligen Prozentbereich.

Wer es ernst meint, erfasst zwei Begleitgrößen mit. Die Agenten-Führungsspanne misst, wie viele Agenten ein Mensch parallel effektiv betreut, heute zwei bis drei. Die mittlere Laufzeit zwischen Eingriffen misst, wie lange ein Agent arbeitet, bevor er einen Menschen braucht. Beide sollen steigen.

Den Grund mitschreiben, nicht nur die Zahl

Eine nackte Eingriffsrate sagt, dass es klemmt, aber nicht wo. Deshalb gehört zu jedem Eingriff ein Grund:

• Spec-Klärung — die Aufgabe war zu vage gestellt
• Kurskorrektur — der Agent lief in die falsche Richtung
• Freigabe — eine Berechtigung, ein Zugang oder eine Entscheidung fehlte
• Nacharbeit — der Output war falsch und musste korrigiert werden

Erst diese Aufschlüsselung macht das KPI handlungsfähig. Wenn 60 Prozent der Eingriffe aus „Spec-Klärung” stammen, liegt der Hebel bei besseren Aufgaben-Templates und gepflegten Repo-Specs, nicht beim nächsten Modell. Stammt der Großteil aus „Freigabe”, ist es ein Permission-Design-Problem.

So misst man das in der Praxis

Die gute Nachricht für alle, die das jetzt erheben wollen: Die Rohsignale liefert Claude Code selbst. Die eingebaute OpenTelemetry taugt als zentrale Zählgrundlage besser als selbstgebaute Hooks, weil sie standardisiert ist, wenig Pflege braucht und sich org-weit ausrollen lässt. Hooks behalten dabei genau eine Aufgabe, die Telemetrie nicht leisten kann: den Grund eines Eingriffs zu erkennen.

Mit CLAUDE_CODE_ENABLE_TELEMETRY=1 emittiert Claude Code Events und Metriken, die sich direkt auf die Kennzahlen abbilden lassen:

Kennzahl	Signal aus Claude Code	Berechnung
Eingriffe (Turns)	claude_code.user_prompt (Event)	Events pro Session minus Kickoff
Autonomiegrad (Tool-Ebene)	claude_code.tool_decision, Feld source	config/hook = automatisch, user_* = menschlich
Aufgaben	claude_code.session.count	Session als Task-Proxy für die erste Version
Zeit zwischen Eingriffen	Zeitstempel der user_prompt-Events, claude_code.active_time.total	Abstand bzw. aktive Zeit je Eingriff
Führungsspanne	überlappende aktive Sessions je account_uuid	maximale Parallelität im Zeitfenster

Das source-Feld auf claude_code.tool_decision ist der Schlüssel. Es unterscheidet eindeutig, ob eine Tool-Entscheidung automatisch fiel (config, hook) oder ein Mensch sie traf (user_temporary, user_permanent, user_reject, user_abort). Der Autonomiegrad fällt damit ohne Schätzung an.

Was die Telemetrie nicht weiß, ist das Warum. Dafür kommen Hooks ins Spiel, gezielt für die Gründe-Schicht. Ein Stop- oder UserPromptSubmit-Hook bekommt den transcript_path auf stdin und reicht ihn an einen kleinen Klassifizierer weiter, der den Folge-Prompt in Spec-Klärung, Kurskorrektur, Freigabe oder Nacharbeit einsortiert. Die „Freigabe”-Fälle deckt das source-Feld schon teilweise ab, den Rest liefert der Blick ins Transcript.

Das Minimal-Setup pro Maschine sind ein paar Umgebungsvariablen:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp           # user_prompt und tool_decision laufen als Events/Logs
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317
export OTEL_RESOURCE_ATTRIBUTES=team=eng,dev=$(whoami)

Für ein ganzes Team gehören diese Variablen in die managed-settings.json. Dort sind sie zentral verteilt und vom Nutzer nicht überschreibbar. Als Sammelstelle reicht ein OTLP-Collector mit Prometheus und Grafana dahinter. Kleinere Teams können den Strom auch an einen eigenen Endpunkt schicken: Ein Stop-Hook, der die Kennzahlen an einen schlanken FastAPI-Dienst POSTet und in SQLite ablegt, kommt mit wenig Code aus und macht die Zahl sofort abfragbar.

Ein Vorbehalt bleibt, und er ist wichtig. Telemetrie zählt Turns, nicht Fehler. Ein produktives Gespräch mit dem Agenten erzeugt dieselben user_prompt-Events wie eine genervte Kurskorrektur. Aussagekräftig wird die Eingriffsrate erst zusammen mit einer Qualitätsgröße, und genau dafür sorgt die Gründe-Schicht.

Die Branche, die dieses KPI seit Jahren fährt

Das Muster ist nicht neu. Das autonome Fahren misst seit einem Jahrzehnt genau das: Disengagements, also wie oft ein Sicherheitsfahrer eingreifen musste. In Kalifornien ist die Meldung an das DMV gesetzlich vorgeschrieben, jedes Jahr, pro Anbieter, pro gefahrene Meile. Aus „das Auto fährt schon ganz gut” wurde so eine berichtspflichtige Zahl, an der sich Waymo, Cruise und der Rest öffentlich messen lassen müssen.

Die Übertragung ist direkt: Disengagements pro Aufgabe, oder pro tausend Zeilen Code, ist der Reifegrad-Indikator agentischer Entwicklung. Und die Lehre aus dem Auto gilt auch hier: Die Kurve fällt in Sprüngen mit jeder Modellgeneration, und der letzte Rest an Eingriffen ist der teuerste. Fungs Rat, früher gescheiterte Automatisierungen mit jedem Modell-Update erneut zu testen, ist genau diese Beobachtung aus der Praxis.

Das Reifegradmodell

Stufe	Arbeitsweise	Eingriffsrate	Führungsspanne
0 — Manuell	Mensch steuert jeden Schritt	~100 %	1
1 — Assistiert	Mensch promptet, reviewt synchron	hoch	1
2 — Überwacht-parallel	Mehrere Agenten async, Mensch sammelt ein	sinkend, aber Switching-Last steigt	2–3 (heute)
3 — Routine-getrieben	Routinen erzeugen Prompts und Agenten, Mensch greift nur bei Ausnahmen ein	klein	10+
4 — Selbst-verifizierend	Geschlossene Loops aus Tests, Evals, Monitoring	nahe 0 bei unkritischen Aufgaben	viele

Der wichtigste Befund steckt in Stufe 2: Sie fühlt sich oft schlechter an als Stufe 1. Die Eingriffsrate sinkt, aber die kognitive Last pro Mensch steigt erst einmal. Genau dort stecken die meisten Teams gerade fest, und genau dort sitzt Fungs ungelöstes Problem. Der Weg nach Stufe 3 führt über die Senkung der Kosten pro Kontextwechsel, also über Werkzeuge, die den Zustand wiederherstellen und sagen „hier stehst du gerade”. Anthropic baut das mit Routinen, die selbst Agenten anstoßen. Bei den meisten anderen fehlt es noch.

Wo das KPI gefährlich wird

Drei Fallstricke, sonst optimiert man das Falsche.

Eine Eingriffsrate von null klingt wie das Ziel und ist in Wahrheit ein Warnsignal. Bei irreversiblen oder riskanten Aufgaben gehören menschliche Gates bewusst dorthin, wo ein Fehler weh tut. Fung trennt das im Alltag über ihr „bad versus sad”-Raster: „bad” ist der nicht behebbare Fehler, ein Crash mit Datenverlust, „sad” der ärgerliche, aber heilbare Schmerzpunkt. Volle Autonomie bei „bad” ist fahrlässig.

Das KPI ist manipulierbar. Man drückt die Eingriffsrate trivial, indem man Qualität opfert und niemanden mehr hinschauen lässt. Deshalb muss sie immer an eine Qualitätsgröße gekoppelt werden, an Rework-Rate, Incident-Rate oder die „bad/sad”-Quote. Sonst misst man Autonomie und bezahlt mit Schaden. Wer Output statt Outcome zählt, landet beim gleichen Denkfehler wie beim Token-Maxing, das wir in AI-FinOps und der Token-Wahnsinn auseinandergenommen haben. Genau solche Output-Metriken füllen die Museumsvitrinen.

Nicht jeder Eingriff ist Reibung. Manche sind die wertvolle Richtungsentscheidung, für die man den Menschen überhaupt im Loop haben will. Die Gründe-Taxonomie trennt den vermeidbaren Eingriff vom gewollten. Warum Aufsicht zum Design gehört und nicht zum Defizit, haben wir in Setzen und Vergessen gibt es nicht ausführlich begründet.

Was das für die Tool-Auswahl heißt

Für jeden im DACH-Mittelstand, der gerade KI-Entwicklungswerkzeuge evaluiert, verschiebt sich der Maßstab. Die erste Frage war „Wie viel Code erzeugt das Ding?”. Das ist die falsche Frage, weil mehr Output bei gleicher Eingriffsrate nur mehr Arbeit für den Menschen bedeutet. Die richtigen Beschaffungsfragen lauten:

1. Senkt das Werkzeug die Eingriffsrate messbar, oder produziert es nur mehr Material zum Kuratieren?
2. Trägt es asynchrone Agenten-Fleets und stellt es Kontext nach einem Wechsel schnell wieder her?
3. Liefert es Telemetrie, mit der sich Eingriffe, Gründe und Führungsspanne überhaupt erfassen lassen?
4. Lässt sich Autonomie pro Risikoklasse einstellen, sodass kritische Pfade ihre menschlichen Gates behalten?

Die ehrliche Lage ist: Niemand hat die Decke von zwei bis drei Agenten bisher durchbrochen, der Hersteller der besten Agenten eingeschlossen. Wer also einem Anbieter glaubt, der zehn parallele Agenten pro Entwickler verspricht, sollte nach genau einer Zahl fragen. Nach der Eingriffsrate. Kommt darauf keine Antwort, ist das die Antwort.

Und damit zurück ins Museum

Lines of Code und Tokens Spent stehen in der Vitrine, weil sie Output gezählt und so getan haben, als wäre das Wirkung. Die Eingriffsrate entgeht diesem Schicksal nur unter einer Bedingung: gekoppelt an Outcome und Qualität, mit dem Grund neben jeder Zahl. Hält sie das durch, steuert sie das Einzige, was gerade wirklich knapp ist, die menschliche Aufmerksamkeit. Hält sie es nicht durch, bekommt das Museum sein fünftes Exponat.