Aktuelle Best Practices für den agentischen SDLC sehen menschliche Freigaben an wesentlichen Übergängen vor. In solchen Prozessen generieren Agenten so schnell so viel Code und so viele Dokumente, dass Menschen die Arbeit kaum noch verfolgen, geschweige denn verstehen können. Damit wächst die Wahrscheinlichkeit, dass die geforderten Entscheidungen nur noch durchgewunken werden.
Das betrifft die Rolle des Owners im SDLC des Spec-Driven Development, den ich hier dokumentiert habe. Dieser Mensch gibt den Plan frei, eröffnet Umsetzungsabschnitte und entscheidet über den Merge. Jede dieser Entscheidungen landet als Eintrag im Repository, neben den Verdikten der Prüfmodelle. Zwischen diesen Punkten arbeiten Implementierer, Subagenten und Prüfmodelle. Von ihrer Arbeit kennt der Owner das, was sie ihm am Rückkehrpunkt vorlegen.
Auch das ist Gegenstand aktueller Forschung. Fünf Arbeiten aus dem vergangenen halben Jahr zeigen zweierlei: Die Aufmerksamkeit lässt im Lauf nach, und Prüfende stützen sich auf Material, das der Agent liefert. Damit handeln sie ihrem eigentlichen Auftrag zuwider.
Das Positionspapier „AI Agents Push Humans Out of the Loop“ von Margaret Mitchell, Avijit Ghosh und Samir Passi hat diese Position am 24. August 2026 zugespitzt. Es führt Forschung zu Automation und Mensch-Computer-Interaktion zusammen.
Aufsicht im laufenden Betrieb
Coding-Agenten erzeugen neben dem Code ihre Pläne, Werkzeugaufrufe und Testergebnisse. Sie ändern ihr Vorgehen während des Laufs und übergeben Arbeit an weitere Agenten. Mitchell, Ghosh und Passi beschreiben, was eine Person leisten müsste, um das zu beaufsichtigen. Sie müsste den Strom verfolgen, frühere Schritte im Gedächtnis behalten und die Wirkung der nächsten Aktion abschätzen. Nebenbei erteilt sie Berechtigungen und bearbeitet ihre fachliche Aufgabe. Die Oberflächen helfen dabei kaum. Sie zeigen lange Protokolle, die für eine Prüfung im laufenden Betrieb nicht aufbereitet sind, und sie wiederholen Abfragen, bis daraus Gewöhnung wird. Als weiteres Risiko nennt das Paper den Verlust von Fachpraxis und eigener Fehlersuche, wenn jemand lange mit automatisierten Systemen arbeitet. Niemand hat bisher gemessen, wie stark dieser Effekt bei Coding-Agenten ausfällt und wie lange er anhält.
Eine formative Untersuchung mit vier Fachkräften aus der Softwareentwicklung zeigt, was im Lauf mit der Aufmerksamkeit geschieht. Die vier bearbeiteten eine einzelne Aufgabe mit dem Coding-Agenten Cline, und ihre beobachtete kognitive Beteiligung sank im Verlauf der Arbeit. Sie prüften vor allem das sichtbare Ergebnis und seltener den Weg dorthin. Aus vier Personen lässt sich kein allgemeiner Effekt ableiten. Die Richtung deckt sich aber mit dem, was eine Interviewstudie mit 17 erfahrenen Entwicklerinnen und Entwicklern im Arbeitsalltag fand. Die Befragten sparten Aufwand mit Faustregeln. Manche behandelten den Plan des Agenten als Abbild seines tatsächlichen Vorgehens. Andere verließen sich auf grüne Tests als Garantie für korrekten Code. Zwölf der 17 Personen arbeiteten im selben großen Technologieunternehmen, weshalb die Forschenden ihre Ergebnisse als explorativ einstufen.
Beide Faustregeln stützen sich auf Material des Agenten. Der Plan ist seine Ankündigung. Grüne Tests belegen, was die Tests abfragen. Hat der Agent sie selbst geschrieben, prüft er sich damit selbst. Wer darauf baut, prüft die Selbstauskunft des Systems, das er prüfen soll. Ein Lauf erzeugt so viel Material, dass kaum etwas anderes übrig bleibt, solange Prüfen heißt, dem Agenten zuzusehen.
Prüfung vor der Ausführung
Den bislang umfangreichsten direkten Vergleich liefert eine im April veröffentlichte Studie mit 48 Teilnehmenden. Sie prüfte vier Formen der Aufsicht über Agenten, die Webseiten bedienen. Die Aufgaben enthielten Datenschutzprobleme, Prompt-Injection und manipulative Oberflächen. Problematische Aktionen wurden seltener, wenn die Versuchspersonen den Plan des Agenten vorher prüften. War eine solche Aktion schon sichtbar, griffen sie deswegen nicht häufiger erfolgreich ein. Keine der vier Varianten schnitt in allen Situationen am besten ab. Nach den Interviews hing ein Eingriff auch davon ab, ob die Oberfläche den kritischen Moment rechtzeitig als Entscheidung markierte.
Für die Frage nach der Freigabe ist das der wichtigste Befund. Der Mensch hat in diesem Versuch etwas bewirkt, wenn er vor der Ausführung prüfte. Er stand dann an einem Punkt, der als Entscheidung markiert war, und hatte einen Plan vor sich. Griff jemand im laufenden Betrieb ein, lag das weniger an der Prüfvariante als an der Oberfläche, die den Moment markierte. Die Agenten der Studie bedienten Webseiten. Ob sich das auf Repositories überträgt, bleibt eine Annahme. Sie passt zu den Faustregeln aus der Interviewstudie und zur nachlassenden Beteiligung im Cline-Versuch.
Was der Owner tatsächlich sieht
Der dokumentierte Prozess im SDLC des Spec-Driven Development beschreibt Rollen mit ausschließlichen Agententätigkeiten. Nur der Owner ist ein Mensch. Der agentengestützte Workflow beginnt mit Ticket und Machbarkeitsprüfung. Es folgen Pre-Gate, Plan-Gate, Umsetzungsabschnitte mit eigenen Prüfschleifen, Completion und Merge. Ein unabhängiger Judge kontrolliert die Arbeit des Implementierers. Der Vorgang geht an den Owner zurück, sobald zwei Korrekturrunden gescheitert sind, der Plan einen Konflikt enthält oder eine irreversible externe Aktion ansteht.
Diese Prüfkette findet Fehler. Die Audit-Artefakte von Projekt A enthalten 77 fehlgeschlagene, 53 bestandene und 9 ergebnislose Verdikte. In Projekt B scheiterten 23 von 82 protokollierten Gate-Durchläufen. Hinter jedem Verdikt liegt ein eigener Prüflauf mit Rohprotokoll. Kein Owner hat so viele Läufe mitgelesen. Gesehen hat er die Stände an den Rückkehrpunkten und die Zusammenfassungen der Agenten dazu. Mehr darf der im Repository gespeicherte Beschluss am Ende nicht behaupten. Ein Eintrag, der nur aus dem Vermerk „freigegeben“, einem Datum und einem Namen besteht, lässt offen, welchen Stand der Owner vor sich hatte und woran er ihn gemessen hat. Wer den Eintrag später liest, kann daraus keine Prüfung des gesamten Laufs ableiten.
Der Prozess sieht dafür schon ein Autonomie-Mandat vor. Der Implementierungsstrang arbeitet innerhalb eines vereinbarten Bereichs und meldet sich an festgelegten Rückkehrpunkten. Diese Punkte liegen dort, wo die Studien den Menschen wirken sehen: vor einem Ausführungsschritt, als markierte Entscheidung, mit einem Plan oder einem festen Stand vor Augen. Mitchell, Ghosh und Passi schlagen dasselbe vor: feste Autonomiegrenzen, Reviews zusammengehöriger Änderungen und Maschinen, die vorab prüfen, was sich automatisch feststellen lässt. Am Rückkehrpunkt braucht der Owner einen bezeichneten Arbeitsstand samt Nachweisen. Ein Gesprächsverlauf oder die Zusammenfassung des Agenten reicht nicht. Der Grund ist derselbe wie bei den Befragten der Interviewstudie: Der Plan des Agenten war kein Abbild seines Vorgehens. Die rechte Spalte der Tabelle zeigt, was ohne neue Freigabe weiterläuft.
| Rückkehrpunkt | Entscheidung des Owners | Erforderliche Nachweise | Was ohne neue Freigabe weiterläuft |
|---|---|---|---|
| Pre-Gate | Sind Aufgabe, Arbeitsbereich und Akzeptanzmaßstäbe fachlich vertretbar? | Ticket, Konfliktliste, betroffene Systeme, vorab formulierte Maßstäbe | Prüfungen auf Vollständigkeit und Widersprüche |
| Plan-Gate | Sind Architekturwahl und geplante Außenwirkungen akzeptabel? | SHA-fixierter Plan, offene Annahmen, erwartete Migrationen | Detailplanung innerhalb der genehmigten Grenzen |
| Stage-Schleife | Muss der Arbeitsbereich verkleinert oder die Umsetzung abgebrochen werden? | Diff, fehlgeschlagene Nachweise, zwei Korrekturberichte, Judge-Verdikt | Implementierung, Tests und bestandene Stage-Prüfungen |
| Completion | Erfüllt der feste Release-Stand die fachlichen Erwartungen? | zurückgehaltene E2E-Fälle, Abweichungsregister, offene Befunde, Rückweg | Vorbereitung des Merge-Artefakts |
| Aktivierung | Darf der Release die bezeichnete Umgebung verändern? | Deployment-Plan, Sicherung, erprobter Rollback, externe Auswirkungen | die ausdrücklich genehmigte Aktivierung |
Das Freigabepaket
Vor Beginn hält der Owner die fachlichen Erwartungen und die erlaubten Außenwirkungen fest. Erst danach sieht er den Plan oder das Verdikt eines Agenten. Mitchell, Ghosh und Passi empfehlen diese Reihenfolge, damit das Protokoll zeigt, ob das Modell das Urteil des Menschen geprägt hat. Für die Freigabe hat die Reihenfolge einen zweiten Zweck: Sie liefert den Maßstab, an dem sich ein fester Stand messen lässt. Ohne ihn bleibt dem Owner am Rückkehrpunkt nur die Einschätzung des Agenten, dieselbe Abkürzung, die die Befragten der Interviewstudie nahmen.
Am Rückkehrpunkt beantwortet der Owner sechs Fragen:
- Welcher Commit und welche Zustandsänderung werden genehmigt?
- Welche fachlichen Erwartungen wurden vor dem Agentenurteil festgelegt?
- Welche Nachweise prüfen den realen Ausführungspfad?
- Welche Abweichungen und offenen Befunde bleiben bestehen?
- Welche Systeme, Daten oder Personen können betroffen sein?
- Lässt sich die Änderung zurücknehmen, und wurde dieser Weg erprobt?
Die Fragen zielen auf die Abkürzungen aus den Studien. Frage 3 verlangt Nachweise über den realen Ausführungspfad, weil die Befragten den Plan als Abbild des tatsächlichen Vorgehens verstanden hatten. Die vorab notierte Erwartung setzt Frage 2 vor das Urteil des Agenten, das sonst zum Maßstab wird. Frage 1 bringt den Commit-Hash in den Beschluss. So lässt sich später nachschlagen, welcher Stand gemeint war. Frage 6 prüft, was das Modell von Gaube et al. als Recht auf Eingriff voraussetzt. Deshalb muss der Freigabenachweis auch belegen, dass der Rückweg erprobt wurde.
Die Antworten bilden zusammen mit dem Diff, den Testergebnissen und dem Prüfbericht das Freigabepaket. Der Implementierer stellt es zusammen. Ein unabhängiges Prüfmodell gleicht die Angaben mit dem Repository, den Rohprotokollen und den Laufzeitnachweisen ab. Die Freigabe gilt für den genannten Commit und für einen Zustandswechsel. Nach jeder Änderung legt der Implementierer den neuen Stand erneut vor.
Bleibt das maschinelle Verdikt ergebnislos, klärt das Team den Befund oder verkleinert den Arbeitsbereich. Neben Genehmigung und Ablehnung braucht der Prozess zwei weitere Ausgänge: erneute Vorlage mit Auflagen oder Abbruch.
Nach meiner Erfahrung können Menschen mit der Geschwindigkeit nicht mithalten, mit der Agenten in jedem Schritt Ergebnisse produzieren.
Schlussfolgerung
Kognitive Überlastung ist real. Einen Menschen als Human in the Loop (HITL) in einen SDLC-Prozess einzubinden, gaukelt Sicherheit und menschliche Teilhabe am Prozess vor. Nur konsequente Validierungen durch Judges oder Auditor-Agenten sichern nach meiner Erfahrung den laufenden Prozess ab. Fachliche End-to-End-Tests müssen dabei eine neue Funktion im SDLC-Prozess übernehmen.
Quellen
- Margaret Mitchell, Avijit Ghosh, Samir Passi: AI Agents Push Humans Out of the Loop, arXiv 2608.23642 (24. August 2026), https://arxiv.org/abs/2608.23642
- Chaoran Chen et al.: Comparing Human Oversight Strategies for Computer-Use Agents, arXiv 2604.04918 (6. April 2026), https://arxiv.org/abs/2604.04918
- Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu: Human oversight of agentic systems in practice, arXiv 2606.05391 (3. Juni 2026), https://arxiv.org/abs/2606.05391
- Carlos Rafael Catalan, Lheane Marie Dizon, Patricia Nicole Monderin, Emily Kuang: “I’m Not Reading All of That”, arXiv 2603.14225 (15. März 2026), https://arxiv.org/abs/2603.14225
- Susanne Gaube et al.: Keeping an Eye on AI: A Framework for Effective Human Oversight of AI Systems, arXiv 2605.16278 (9. April 2026), https://arxiv.org/abs/2605.16278