In den meisten Gesprächen über agentisches Engineering hat sich die Handlung vom Prompting zum Operieren verlagert. Hier ein Blick in die Nebelwand: Software-Fabriken, Ziele, Schleifen, Hintergrundsitzungen, Sub-Agenten, Hooks, Sandboxen, agentenbestätigende Agenten. Für viele Schöpfer der Zukunft wird dieses Verhalten ab Tag 1 in die Produkte eingebaut sein: Claude Code und Codex zeigen diesen Wandel direkt.
Aus der Ingenieursperspektive wirst du geringe Autonomie nutzen, um Risiken zu begrenzen und die Umkehrbarkeit zu erhöhen, aber höhere Autonomie für explizite Aktivitäten und Flotten paralleler Agenten, die riesige Codebasen sicher umgestalten. Die Kernfrage zu einer Aktion ist immer: Welches Level verdient diese Aufgabe, und welche Überprüfung macht dieses Level vertretbar?
Die Spitze der Grenze ist der Manager-Agent, der auf seinen Auslöser hin erwacht, an seine Helfer delegiert, während er kontinuierlich deren Output überprüft und nur mit den Entscheidungen zurückkommt, die von einem Menschen getroffen werden müssen. Leute, die eine solche Einrichtung nutzen, betreiben möglicherweise bereits hunderte oder tausende von Agenten, hauptsächlich auf immergrünen Codebasen. Wie bei den meisten Gedanken über Autonomie gilt: Wie du den Maßstab wahrnimmst, ist dennoch für jeden anders.
Der am häufigsten genannte Maßstab stammt von Steve Yegges eindimensionaler Leiter, erwähnt in „Welcome to Gas Town" und im Pragmatic Engineer. Es ist eine gute Referenz, wenn du eine Zahl willst, die dir sagt, wie KI-nativ du bist: Die Leiter gibt dir eine einzelne Zahl, um zu messen, ob du dein Vertrauen in einen einzelnen Agenten kennst. Hier ist eine Version davon:
Anfang 2026, selbst als die Arbeit begann, sich von Delegation zu Orchestrierung zu verschieben, war dies ein recht guter Proxy zur Risikomessung. Heute jedoch können viele Fähigkeiten an Bedeutung und Hebelwirkung gewinnen, wenn du viele Agenten gleichzeitig betreiben kannst. Eine einzelne Sprosse kann dir nicht helfen, Multi-Agenten-Fähigkeiten zu verorten.
Stattdessen vermischt fast jede Autonomiedebatte, die ich gesehen habe, zwei Fragen, die getrennt werden sollten: Wie weit weg von dir selbst lassen wir diesen einzelnen Agenten gehen, und wie gut sind wir darin, viele Agenten zu koordinieren?
Um diese beiden Dimensionen getrennt zu erfassen, verwenden wir zwei Achsen: Handlungsfähigkeit (Agency) und Orchestrierung.
Auf der Agency-Achse umfasst „niedrig" das Vorschlagen von Kandidatenaktionen und das Warten auf eine Entscheidung.
„Mittel" bedeutet, dass der Agent an einer bestimmten Aufgabe arbeitet, aber seinen Umfang eingrenzt und ständig Bericht erstattet, was er tut, zusammen mit Beweisen, damit du ihn weiter steuern kannst.
Am hohen Ende der Agency arbeitet der Agent auf ein Ziel hin, experimentiert, lernt, testet, findet Wege, ein Problem zu lösen, stößt auf Hindernisse, stellt Fragen, probiert verschiedene Ansätze aus und liefert all diese Arbeit in Form von Beweisen zurück.
Auf der Orchestrierungsachse bedeutet „niedrig" einen Agenten, einen Thread. Bei „mittel" hast du mehrere Agenten, jeder arbeitet in seinem eigenen Arbeitsverzeichnis, möglicherweise auf verschiedene Ziele hin, aber isoliert. Am hohen Ende hast du einen Orchestrator, der ein Backlog, einen Issue-Tracker, einen Zeitplan oder eine andere Warteschlange aufnehmen und in kontinuierliche Arbeit umwandeln kann, und du musst nur eingreifen, wenn etwas schiefgeht: „Management by Exception." Produkte und Funktionen, die diese Ideen beinhalten, sind:
- Claude Codes /plan, /goal, /loop, /background, /batch, /code-review, /security-review Modi, Sub-Agenten, Hooks, Checkpointing, Agenten-Delegation und Management-Praktiken, Hintergrundsitzungen, Agenten-Team-Muster, /schedule Argumente
- Codex‘ lokale/Cloud-Threads, Goal-Modus, Arbeitsverzeichnisse, Automatisierungen, Sub-Agenten, Review-Bereiche, GitHub-Code-Review, Hooks, Sandboxing, Auto-Review und Wiederholung
Diese Fähigkeiten passen nicht auf eine einzelne Leiter.
Der Aufstieg: Drei Epochen und ein einziger Stapel
Wenn du die Leiter von unten nach oben liest, stellst du dir vor, gleichzeitig sowohl Agency als auch Orchestrierung zu erklimmen. Tatsächlich repräsentieren die sechs Stufen drei separate Epochen, die wir alle durchlaufen:
Zuerst sitzt du am Steuer, und ein Agent hilft hauptsächlich, indem er darauf wartet, dass du ihn lenkst.
Zweitens übernimmt der Agent die Führung bei einer abgegrenzten Aufgabe oder einem Ziel, aber du bist noch da, um ihn zu lenken und zu überprüfen, was er tut.
Und drittens, in der Ära der Orchestrierung, ist das System in der Lage, die Show zu leiten, Arbeit auf viele Agenten zu verteilen, und du musst meistens nur eingreifen, wenn etwas schiefgeht: „Management by Exception."
Das macht die Sache einfacher, weil die vertikale Position auf der Leiter die beiden Achsen sauber erfasst (Orchestrierung setzt erst nahe der Spitze ein) und sie so zu einem einzigen stetigen Aufstieg durch die Sprossen wird. Und doch ist der Aufstieg immer noch Teil einer Veränderung, die wir alle durchmachen.
Ein guter Tag im Engineering beinhaltet das Berühren mehrerer Sprossen, manchmal sogar mehrerer: Es ist normal, im Laufe einer Aufgabe ein paar Mal zwischen den Epochen zu wechseln.
Die sechs Stufen im Detail
Stufe 0: Assistieren
Der Agent macht Vorschläge, die meist gut und oft perfekt sind, aber du wirst immer entscheiden, ob sie gut genug sind, um darauf zu reagieren. Denk an Autovervollständigung, Inline-Editier-Vorschläge oder das Verweilen in einer Chat-Sitzung, in der eine Änderung diskutiert wird, die noch niemand übernommen hat. Verwenden für kostspielige Fehler, winzige Änderungen oder wenn du dir selbst ein Urteil bildest. Die Überprüfung findet hauptsächlich lokal statt.
Stufe 1: Überwachte Aktion
Der Agent bearbeitet oder führt Befehle in deinem Namen aus und fragt dich vor der Ausführung von etwas Konsequentem. Dies ist die Standardhaltung der meisten Leute. Es kann in einer lokalen Sandbox mit Genehmigungen vor dem Anwenden von Änderungen erfolgen – wobei jede Genehmigung eine unabhängige Bestätigung ist, dass die Änderung in Ordnung ist – oder in einer interaktiven Sitzung. Die Fehlerart ist Genehmigungsmüdigkeit; alle Genehmigungen fühlen sich gleich an, unabhängig davon, was sie genehmigen. Du könntest dies lösen, indem du einen Blick auf den Diff wirfst, einigen Heuristiken folgst, vor der Genehmigung eine andere Person konsultierst oder einfach zustimmst, den Agenten verantwortlich sein zu lassen. Codex Auto-Review löst dieses Problem, indem es die endgültige Genehmigung von Randbedingungen an einen separaten Prüfagenten delegiert.
Stufe 2: Delegation abgegrenzter Aufgaben
Übergib eine abgegrenzte Aufgabe an den Agenten. Diese Aufgabe wird ein klares Ziel, Einschränkungen und eine Arbeitsdefinition davon haben, wie „erledigt" aussieht. Du bleibst in der Nähe, kannst unterbrechen, bist aber meistens nicht involviert. Dies ist der Schwerpunkt in der Softwareentwicklungswelt. Die Überprüfung verlagert sich von dir (du musst dich vielleicht ausruhen und schlafen) hin zu Beweisen, die der Agent produzieren kann: bestandene automatisierte Tests, korrekte Typen, Lint-Vorschläge, Screenshots, Reproduktionsschritte, Herkunftsnachweise durch Beispiele usw.
Stufe 3: Zielgetriebene Autonomie
Der Agent tut alles, was nötig ist, um ein Ziel zu erreichen, und stoppt nur, wenn eine bestimmte Bedingung erfüllt ist. Im Prompt-Modus bedeutet dies, dass der Prompt selbst zum Ziel wird (z. B. „Kannst du die Time-to-Interactive dieser Seite auf unter 1 Sekunde reduzieren?"). In Codex ist dies der Goal-Modus: Der Agent durchläuft die Schritte Planen->Handeln->Testen->Überprüfen, bis er die Erfolgskriterien nicht mehr erfüllt. In Claude Code sind es die Befehle /goal, /loop und /schedule. Damit diese Stufe nützlich ist, muss die Stoppbedingung auf eine Weise messbar sein, die automatisiert werden kann.
Bitte deinen Agenten nicht um Hilfe bei vagen, wolligen Zielen wie „die Benutzererfahrung allgemein verbessern" oder „die Codebasis testbarer machen". Wähle etwas Spezifisches, Messbares und Automatisiertes: Finde Bugs in der Produktion, die der statischen Analyse entgehen, reduziere die Ladezeit, stelle sicher, dass wir einen strengen TypeScript-Build ohne explizite Anys haben, triagiere alle Abhängigkeiten, um nur die zu behalten, die wir verstehen und die unsere Tests bestehen, usw. Und schließlich: Um Bugs in der Produktion zu finden, muss sich der Agent in einer produktionsähnlichen Umgebung befinden.
Stufe 4: Parallele Delegation
Arbeite mit vielen Agenten parallel. Jeder Agent arbeitet an einem isolierten Teil der Aufgabe. Der größte Engpass auf dieser Stufe ist die Zerlegung: das Definieren der richtigen Teile zur Delegation. Unterstützungen umfassen: Sub-Agenten, Hintergrundsitzungen, /batch, Arbeitsverzeichnisse, Agententeams usw. Die Fehlerart ist falsche Parallelität: Viele Agenten gleichzeitig auf überlappenden Teilen laufen zu lassen, sodass du statt mehr Arbeit Merge-Konflikte und doppelte Entscheidungen bekommst. Um dies gut zu machen, müssen Agenten voneinander isoliert sein, jeder besitzt seine eigenen Dateien und seinen eigenen Status. Jeder muss auch seine eigene Review-Warteschlange haben. Und schließlich verursacht jeder Agent Kosten – in Bezug auf verbrauchte Tokens – proportional zur Anzahl der gleichzeitig laufenden Agenten. Auf der menschlichen Seite steigen durch die Orchestrierungssteuer die Grenzkosten für das Hinzufügen eines Agenten nach einigen.
Stufe 5: Management-by-Exception-Orchestrierung
Definiere, wie Erfolg aussieht und welche Richtlinien gelten sollen. Ein Manager-Agent wird basierend auf Auslösern aufwachen (z. B. neues Issue, neue Aufgabe, Uhrzeit), Arbeiter-Agenten entsenden, deren Fortschritt überwachen, Output überprüfen, bei Fehlschlag wiederholen, an kompetentere Agenten oder Menschen eskalieren, wenn Bedingungen erfüllt sind, Ergebnisse aggregieren und schließlich Arbeitsprodukte (z. B. PRs) und Beweise an externe Systeme zurückgeben. Denk an eine Fabrik: Der Issue-Tracker oder das Backlog ist der Input, und das Produkt der Fabrik ist der Output (d. h. viele behobene Issues, Bugs). Agenten arbeiten in einer angemessen isolierten Umgebung mit vielen Wänden (und falls nötig, Notausstiegen), und nur ein Betriebssystem – definiert durch den Manager-Agenten – definiert, was die Fabrik tun soll.
Das Design dieses Betriebssystems bleibt dem Menschen überlassen; OpenAI hat eine Spezifikation für Symphony vorgeschlagen, die ein Linear-Board im Zentrum hat: Jedes Issue bekommt seinen eigenen Agenten-Arbeitsbereich, und der Agent stellt kontinuierlich sicher, dass er Fortschritte in Richtung seines Ziels macht, wie es in einer Spezifikationsdatei in seinem eigenen Arbeitsbereich definiert ist. Die menschliche Überprüfung kann auf der Ebene erfolgen, auf der Beweise generiert werden, aber die Grenze (d. h. das Mächtigste in der Orchestrierungswelt) ist der Bau kontinuierlicher Agentenfabriken mit Hunderten oder sogar Tausenden von Agenten. An diesem Punkt des Aufstiegs wird es zunehmend wichtiger, eine unabhängige Überprüfung zu haben: separate Implementierer und Prüfer, separate Testläufer und QA, separate Sicherheitschecks, separate Prozess-Gates für die Abnahme.
Risiko und Umkehrbarkeit setzen die Obergrenze.
Ich erinnere mich an eine frühere Anthropic-Studie zu einigen der schwierigsten Aufgaben mit Claude Code, bei der es mehr als doppelt so oft um Klarstellung bat, wie Benutzer unterbrachen. Erfahrene Benutzer (~750 Sitzungen gegenüber unter 50) genehmigten eher automatisch und unterbrachen, während sie den Fortschritt im Auge behielten.
Sie machten auch eine breitere Analyse darüber, wie Menschen Claude Code nutzen. Sie untersuchten ~400.000 Sitzungen von ~235.000 Personen zwischen Oktober 2025 und April 2026. Aus jeder Sitzung konnten sie die Entscheidungen ableiten, die jemand trifft, wie z. B. wie viele Aktionen sie in jedem Prompt anfordern, welche davon sie zur automatischen Genehmigung auswählen, wie oft sie unterbrechen usw. Menschen treffen ~70 % der Planungsentscheidungen, aber Claude erledigt ~80 % der Ausführung. Hohe Autonomie bedeutet nicht, Menschen aus dem Kreislauf zu lassen, sondern sie davon zu entlasten, jeden Schritt zu machen, und ihnen stattdessen die Entscheidung zu überlassen, in welche Richtung es als nächstes geht.
Wenn wir feststellen wollen, ob ein großes KI-System mit hoher Autonomie arbeitet, sollten wir die drei folgenden Fragen stellen:
- Wie schnell werden wir merken, dass wir uns mit dem, was es tut, irren?
- Wie sauber können wir rückgängig machen, was es tut?
- Was würde beweisen, dass wir mit dem, was es tut, richtig liegen?
Wenn die Antwort auf alle drei lautet: nicht schnell, mit großen Schwierigkeiten und indem wir der Zusammenfassung vertrauen, dann ist es keine hohe Autonomie.
Jedem Lauf eines Agenten sollte ein Vertrag vorausgehen, der definiert, was er zu erreichen versucht.
Das Ziel: Was wir zu erreichen versuchen (keine Aktivität, nicht die Technik, sondern ein Ergebnis).
Der Umfang: In welchem Bereich wir operieren und welche Techniken erlaubt sind.
Nicht-Ziele: Was nicht Teil des Ziels ist.
Werkzeuge und Berechtigungen: Wie der Agent mit der Welt interagieren kann. Stoppbedingung: Wann gestoppt werden soll; idealerweise eine messbare Variable.
Beweise: Spezifische Tests, Screenshots, Logs, Datenbankeinträge oder andere Indikatoren, die verwendet werden können, um zu bestätigen, dass etwas getan wurde (unabhängig vom Agenten).
Eskalation: Wer unter welchen Umständen einbezogen wird (einschließlich der Frage, wer den Agenten ausführt).
Und Budget: Ein Limit dafür, wie viel Zeit, Aufwand und Tokens für die Aufgabe aufgewendet werden sollen (Tokens sind das Budget großer KI-Modelle – du kannst auch ein Limit für die Anzahl der Versuche und ein Limit für den Grad der Parallelität einbeziehen).
Metriken machen Autonomie nur ein bisschen zuverlässiger
Eine Metrik im Nachhinein zu entscheiden, ist wahrscheinlich nicht genug. Metriken können im Voraus in einem prägnanten Dokument festgelegt werden. Und das lässt Autonomie zuverlässiger erscheinen und macht den Vertrauensvorschuss ein kleines bisschen leichter.
Obwohl es viele Möglichkeiten gibt, Erfolg zu messen, solltest du in Betracht ziehen, einige Versionen dieser Metriken für jede Autonomiestufe zu verfolgen:
- Mittlere Zeit zwischen Eingriffen
- Längster erfolgreicher unbeaufsichtigter Lauf mit akzeptierter Arbeit
- Anteil der in der Sandbox ausgeführten Aktionen im Vergleich zu eskalierten
- Prozentsatz der automatisch genehmigten vs. abgelehnten Aktionen
- Durchschnittliche Anzahl von Agentenaktionen pro menschlicher Anweisung
- Klarstellungsanforderungsrate / Unterbrechungsanforderungsrate
- Überprüfungszeit pro akzeptierter Änderung
- Nacharbeitsrate auf jeder Vertrauensstufe
- Fehlerdurchschlupfrate auf jeder Vertrauensstufe
- Token-Kosten pro akzeptierter Änderung
Solche Metriken können eine Geschichte erzählen: Ein einzelner Agent, der durch menschliche Übergaben beschäftigt gehalten wird, ist Stufe 4 mit einem Dashboard. Ein konservativer Agent, der ohne automatisierte Aufnahme, Wiederholungen und anständige Beweise nicht fortfahren will, ist Stufe 5 mit einem echten Gate.
Denk über die Bereitschaft nach
Klassifiziere Arbeit nach Risiko und danach, wie leicht sie rückgängig gemacht werden kann. Wende Autonomie konservativ an und steigere sie nur, wenn sich Beweise für die höhere Stufe ansammeln. Eine Refaktorisierung der Zahlungs-Engine, geschützt durch starke Tests und Prüfagenten mit einem sauberen Rollback-Pfad, kann eine viel höhere Autonomie unterstützen als eine Dokumentationsautomatisierungsaufgabe, der eine kanonische Wahrheit fehlt. Die Autonomiestufe sollte dem Überprüfungsprozess folgen, nicht dem Aufgabennamen.
Vier Anti-Patterns
Jedes System kann leicht diesen vier Autonomie-Anti-Patterns zum Opfer fallen, wenn nicht wachsam vermieden.
Autonomie als Status – Die Autonomiebewertung eines Agenten wird zu einem bedeutungslosen Statusabzeichen. Höhere Autonomie wird als Beweis für Fähigkeit behandelt, nicht für Sicherheit, und Agenten werden heißer gefahren, als es die Überprüfung unterstützt. Behebung: Lobe und belohne diejenigen, die sich auf der richtigen Autonomiestufe einpendeln und unerbittlich vermeiden, zu weit zu gehen.
Genehmigungswäsche – Die Tyrannei der Genehmigungsmüdigkeit führt dazu, dass wir KI-Agenten und -Werkzeugen wild breiteren Zugang gewähren als nötig. Behebung: Bessere Grenzen sind immer eine Lösung, wie Sandbox-Profile, eingeschränkte beschreibbare Wurzelverzeichnisse, Whitelist-Befehle, Hooks und Auto-Review.
Zusammenfassungsersatz – Die Arbeitszusammenfassung des Agenten ersetzt die Überprüfung, unter der Annahme, dass die Zusammenfassung ausreicht. Behebung: Bündele dasselbe Beweispaket wie bei vollständig manuellen Überprüfungen (einen Diff, Tests, Logs, Screenshots, Prüfergebnisse, Risiken, Lücken usw.), während du kognitive Kapitulation vermeidest.
Flotten-Cosplay – Dutzende von Agenten laufen parallel, aber ein Mensch orchestriert weiterhin jede Abhängigkeit manuell. Behebung: Gemeinsamer Zustand, Eigentumsregeln und bessere Abhängigkeitsverfolgung reduzieren allmählich die Notwendigkeit, manuell zu koordinieren. Kleinere WIP-Limits erzwingen einen Fokus auf das Kodieren und Dokumentieren der koordinierten Schritte, bis die Orchestrierung automatisiert wird.
Eine Kalibrierungsübung
Überprüfe die letzten zehn Aufgaben, die du mit Agentenunterstützung durchgeführt hast. Notiere für jede Aufgabe die ausgeübte Autonomiestufe, das damit verbundene Risiko, wie leicht die Arbeit rückgängig gemacht werden konnte, die produzierten Beweise zur Erfüllung der Überprüfungsanforderungen, die Überprüfungszeit, ob Nacharbeit erforderlich war und ob die gewählte Autonomiestufe beim nächsten Mal immer noch passen würde.
Wie man sicher aufsteigt
Bewege dich jeweils eine Achse nach oben. Beginne mit einem einzelnen überwachten Agenten, der eine einzelne abgegrenzte Aufgabe erledigt, die verteidigbare Erfolgsbeweise produziert (eine Autonomiestufe 1, wenn ordentlich genug). Erweitere dann schrittweise in die drei orthogonalen Richtungen. Parallelisiere leseintensive Erkundungsaufgaben (Autonomiestufe 4). Füge Schreibagenten hinzu, die in separaten Arbeitsverzeichnissen mit eingeschränkten Dateieigentumsregeln arbeiten (Autonomiestufe 4). Füge wiederkehrende Automatisierungen hinzu, dann agentengeführte Orchestrierung basierend auf Issues, Sprache usw. Jeder Schritt nach oben auf dem Hebel erfordert einen neuen Satz von Sicherheitsmechanismen (wie neue Fehlerarten).
Benenne sie: Längere Einzel-Agenten-Läufe können zu Drift, Kontextverrottung, abgebrochener Kommunikation oder abweichenden Zielen führen. Hintergrundarbeit kann zu veralteten Annahmen und schwachen Übergaben führen. Zu viel parallele Arbeit kann zu Merge-Konflikten oder doppelten Entscheidungen führen. Zu viel wiederkehrende Arbeit kann zu stillem Token-Verbrauch oder veralteten Prompts führen. Management by Exception kann zu langen Review-Warteschlangen und Alarmmüdigkeit führen. Behebe es nicht, indem du mehr vertraust; verenge stattdessen den Umfang, sorge für bessere Beweise, ermögliche billigere Rollback-Pfade, härte die Gates und definiere klarere Eigentumsregeln.
Verwende die Autonomiestufe:
- Stufe 0 ist am besten für heikle Arbeiten und wenn das Urteil noch gebildet wird.
- Stufe 1 ist am besten für die meisten Erkundungen, wenn die Arbeit nahe an den Grenzen des gut Verstandenen durchgeführt wird.
- Stufe 2 ist am besten für die meisten abgegrenzten Aufgaben, wohlwissend, dass es unbekannte Abhängigkeiten und unvorhergesehene Fallstricke geben kann.
- Stufe 3 ist am besten, wenn die Erfolgsbedingungen mit ausreichender Klarheit formuliert werden können.
- Stufe 4 ist am besten, wenn die Arbeit sauber auf diese Erfolgsbedingungen aufgeteilt werden kann.
- Stufe 5 ist am besten, sobald die Koordination und Kommunikation, die über die verschiedenen Erfolgsbedingungen hinweg erforderlich sind, vollständig kodiert sind.
Die Überprüfung wird immer der Engpass sein.
Trotz aktueller Großspurigkeit und aktueller Werkzeuge ist die reife Haltung eines Engineering-Teams, das mit KI-Agenten arbeitet, kalibrierte Autonomie.
Die Engpässe sind Koordination, Überprüfung, Wartung, Produkturteil und Lernen aus Vorfällen.
In naher Zukunft werden wir Schleifen entwerfen wollen, die wissen, wann sie arbeiten, wann sie überprüfen und wann sie fragen müssen – aber die Fähigkeit des Ingenieurs wird immer noch darin liegen, die richtige Autonomiestufe zu wählen und Muster und verteidigbare Beweise zu entwickeln, die vor ihren dunkleren Ecken schützen.
Anmerkung: Pangram kennzeichnet diesen Artikel als 100% menschlich geschrieben: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
