Vom vollständigen Code-Review zu Human-on-the-Loop

Ausgangslage und Ziel

Im betrachteten Team lässt ein Mensch den Agenten bereits relativ selbständig Code erzeugen und gibt einige Regeln vor, prüft anschließend aber weiterhin jede Codezeile. Das ist ein Human-in-the-Loop-Modell mit partieller Delegation: Die Ausführung ist agentisch, die entscheidende Qualitätskontrolle bleibt ein obligatorisches menschliches Gate.

Der Übergang zu Lässigs Human-on-the-Loop-Modell besteht nicht darin, dieses Gate ersatzlos zu entfernen. Seine bislang impliziten Kontrollleistungen müssen schrittweise in explizite Guides, wirksame Sensors, begrenzte Agentenrechte und überprüfbare Rückkopplungen überführt werden. Der Mensch prüft dann primär Ziele, Risiken, Systemgrenzen, Ausnahmen, Stichproben und den Harness selbst statt grundsätzlich jede einzelne Codezeile.

Lässig selbst liefert weder ein operationalisiertes Maturity Model noch empirisch validierte Schwellenwerte. Das folgende Modell ist eine eigene Synthese aus seiner Konzeption, Böckelers Harness-Modell, Containment, empirischer Agentennutzung und Human-Factors-Evidenz. Es muss im jeweiligen Team gegen reale Fehler und Wirkungen geprüft werden.

Das angestrebte Regelungssystem

Der innere Regelkreis führt Softwarearbeit aus:

1. Ein Agent plant, verändert Code, führt Prüfungen aus und korrigiert seine Arbeit.
2. Tests, Analysen, Reviewer-Agenten und Laufzeitbeobachtung erzeugen Rückmeldungen.
3. Der Agent bearbeitet erkennbare Abweichungen innerhalb seiner erlaubten Grenzen selbst.

Der äußere Regelkreis steuert dieses Arbeitssystem:

1. Menschen bestimmen Ziele, Risiken und Autoritätsgrenzen.
2. Guides, Policies und Werkzeuge verstärken diese Vorgaben über viele Agentenläufe.
3. Sensors verdichten Zustand, Verhalten und Ergebnisse des Systems zu überprüfbarer Evidenz und Ausnahmen.
4. Menschen greifen bei Abweichungen ein und verbessern anschließend Regeln, Sensors, Werkzeuge oder Systemstruktur.

Human-on-the-Loop bedeutet daher nicht Human-out-of-the-Loop. Der Mensch bleibt Teil eines größeren sozio-technischen Regelkreises und verantwortlich für die Angemessenheit der Steuerung.

Notwendige Transformationsmaßnahmen

1. Den Nutzen des heutigen Reviews vermessen

Bevor das vollständige Review reduziert wird, muss das Team wissen, welche Probleme es tatsächlich erkennt. Für jeden substanziellen Befund sollten mindestens Fehlerklasse, Schweregrad, Änderungsgröße, Reviewzeit und der bereits vorhandene maschinelle Nachweis dokumentiert werden.

Die zentrale Baseline ist die Human-only finding rate: der Anteil relevanter Fehler, die ausschließlich ein Mensch entdeckt und kein bestehender Sensor gemeldet hat. Ohne diese Basis lässt sich später nur eine Verringerung des Reviewaufwands, nicht aber der Erhalt der Kontrollwirkung feststellen.

2. Änderungen nach Risiko und Reversibilität klassifizieren

Der Steuerungsmodus ist eine Eigenschaft einer Änderungsklasse, nicht des gesamten Teams oder Repositorys.

Risikoklasse	Beispiele	Vorläufiger Steuerungsmodus
niedrig	Dokumentation, generierter Code, lokale mechanische Refactorings	frühe Kandidaten für Human-on-the-Loop
mittel	gewöhnliche Features, interne APIs, kontrollierte Dependencies	automatische Prüfung, Ausnahmen und Stichproben
hoch	Authentisierung, Berechtigungen, Datenmigrationen, öffentliche APIs	menschliche Freigabe
kritisch	Produktion, irreversible Datenänderungen, Compliance, Secrets	Human-in-the-Loop und gegebenenfalls Vier-Augen-Prinzip

Zur Einordnung gehören möglicher Schadensradius, Umkehrbarkeit, Beobachtbarkeit, Neuartigkeit und die Zeit, die nach einem Alarm für einen wirksamen Eingriff verbleibt. Maximale Autonomie ist kein Reifeziel.

3. Implizites Reviewerwissen in Guides überführen

Wiederkehrende Beanstandungen sollten möglichst vor der Ausführung maschinenlesbar werden. Geeignete Guides sind unter anderem:

• Architekturregeln und erlaubte Abhängigkeiten;
• Coding-, Security- und Datenschutzstandards;
• fachliche Invarianten und Akzeptanzkriterien;
• sichere Muster für Datenmigrationen;
• Definition of Done und Nachweispflichten;
• Beispiele erwünschter und verbotener Lösungen;
• erlaubte Werkzeuge, Pfade und Berechtigungen;
• maximale Änderungsgröße sowie Abbruch- und Eskalationsbedingungen.

Guides müssen versioniert, verantwortlich gepflegt und möglichst gezielt geladen werden. Die Evaluation von AGENTS.md warnt davor, Umfang mit Wirksamkeit gleichzusetzen.

4. Sensors nach Fehlerklassen aufbauen

Ein grüner Build ist kein umfassendes Qualitätsurteil. Der Harness benötigt komplementäre Beobachtungskanäle:

• Funktionalität: Unit-, Integrations-, Contract- und End-to-End-Tests;
• Architektur: Dependency-Regeln, Modulgrenzen und Architecture Fitness Functions;
• Security: Secret-, Dependency-, SAST-, Berechtigungs- und Datenflussprüfungen;
• Daten: Migrationstests, Rückwärtskompatibilität, Probe-Migrationen und Integritätsbedingungen;
• Betrieb: Performancebudgets, strukturierte Logs, Metriken, Traces, SLOs und Kosten;
• Fachlichkeit: ausführbare Akzeptanzkriterien, Referenzfälle und Invarianten;
• Inferentielle Prüfung: spezialisierte Reviewer-Agenten für Anforderungen, Risiken und ungewöhnliche Änderungen.

Ein inferentieller Reviewer ist kein unabhängiges Orakel, insbesondere wenn Erzeuger und Prüfer dasselbe Modell, denselben Kontext oder dieselben Annahmen teilen. Deterministische und inferentielle Kontrollen müssen daher bewusst kombiniert werden.

Der Agent sollte die Sensors selbst verwenden, bis die Prüfungen erfolgreich sind oder eine definierte Eskalationsbedingung eintritt. Anschließend erzeugt er ein standardisiertes Evidenzpaket mit Aufgabe, Akzeptanzkriterien, betroffenen Komponenten, Risikoklasse, ausgeführten Prüfungen, Abweichungen, Unsicherheiten sowie Rollout- und Rollbackplan.

5. Den Schadensradius technisch begrenzen

Mehr Autonomie verlangt stärkere, nicht lediglich dialogbasierte Grenzen:

• isolierte Worktrees, Sandboxes oder ephemere Umgebungen;
• minimale Dateisystem-, Netzwerk- und Toolrechte;
• keine Produktions-Credentials für Coding Agents;
• getrennte Agentenidentitäten und Audit Logs;
• Zeit-, Kosten- und Iterationsgrenzen;
• Branch Protection und kontrollierte Dependency-Änderungen;
• kleine, reversible Commits;
• Feature Flags, Canary Releases und getesteter Rollback.

Anthropics Containment-Bericht problematisiert häufige Einzelgenehmigungen wegen Approval Fatigue. Harte Zugriffs- und Umgebungsgrenzen bleiben deshalb auch bei guter Prüfung erforderlich.

6. Das neue Modell zunächst im Shadow Mode messen

In einer Übergangsphase läuft die neue Kontrollarchitektur parallel zum vollständigen menschlichen Review:

1. Der Agent implementiert und korrigiert sich anhand der Sensors.
2. Das System erzeugt ein Evidenzpaket und eine Freigabeempfehlung.
3. Ein Mensch prüft weiterhin vollständig, ohne die Empfehlung blind zu übernehmen.
4. Menschliche Befunde werden systematisch mit den Sensorergebnissen verglichen.
5. Nicht erkannte Befunde fließen in Guides, Sensors, Autoritätsgrenzen oder Risikoklassen zurück.

Erst diese Phase erzeugt lokale Evidenz dafür, bei welchen Aufgaben die direkte Prüfung reduziert werden kann.

7. Human-on-the-Loop begrenzt pilotieren

Der erste Pilot sollte nur eine klar definierte, risikoarme Änderungsklasse umfassen. Vollständiges Zeilenreview wird dort durch automatische Freigabekriterien, Ausnahmealarme, zufällige und risikobasierte Stichproben, kontrollierten Rollout und schnelle Rücknahme ersetzt. Änderungen außerhalb der freigegebenen Klasse bleiben im bisherigen Modus.

Die empirische Analyse gescheiterter agentischer Pull Requests spricht dabei für kleine, thematisch kohärente Änderungen und belastbare CI. Die Studie professioneller Entwickler stützt eine aufgabenspezifische, begrenzte Delegation statt pauschaler Autonomie.

8. „Go See“ und Harness-Lernen institutionalisieren

Aggregation und Schwellenwerte vernichten Information. Deshalb müssen Menschen regelmäßig konkrete Änderungen und Agentenläufe untersuchen, obwohl alle Sensors grün sind. Die Auswahl sollte zufällige Stichproben, risikobasierte Fälle und ungewöhnliche Systemzustände kombinieren.

Ein relevanter Befund muss anschließend mindestens eine der folgenden Wirkungen haben:

• einen Guide oder Sensor verbessern;
• die Risikoklassifikation verändern;
• eine Agentenberechtigung begrenzen;
• eine neue Eval-Aufgabe erzeugen;
• oder bewusst als vorerst nicht automatisierbares menschliches Urteil dokumentiert werden.

Da passive Aufsicht Situationsverständnis und Eingriffskompetenz schwächen kann, sollten Teammitglieder außerdem regelmäßig Diagnose- und Wiederherstellungsübungen durchführen. Die Übertragung der Out-of-the-Loop-Forschung auf Coding Agents ist noch nicht direkt belegt, liefert aber eine ernstzunehmende Warnung.

Vorgeschlagenes Reifegradmodell

Stufe	Arbeitsweise	Erforderlicher Nachweis
0 – Ad hoc	Agent erzeugt Code, Menschen prüfen alles; Regeln bleiben überwiegend implizit.	Keine belastbaren Kontrollmetriken
1 – Guided HITL	Versionierte Regeln, CI und vollständiges menschliches Review sind etabliert.	Kontrollen sind reproduzierbar, ihre tatsächliche Erkennungsleistung aber unbekannt
2 – Instrumented HITL	Fehlerklassen, Risikostufen, Evidenzpakete und Sensorwirksamkeit werden im Shadow Mode gemessen.	Human-only findings, Fehlalarme und entkommene Defekte sind nach Klassen bekannt
3 – Bounded HOTL	Bestimmte risikoarme Änderungen laufen ohne vollständiges Zeilenreview; Menschen behandeln Ausnahmen und Stichproben.	Stabile Ergebnisqualität, wirksames Containment und getestete Wiederherstellung
4 – Adaptive HOTL	Produktionsfeedback, Incidents, Übungen und Stichproben verbessern systematisch Guides, Sensors und Autoritätsgrenzen.	Wiederholungsfehler sinken, während Produkt-, Betriebs- und Kompetenzmetriken stabil bleiben

Nach der beschriebenen Ausgangslage liegt das Team vermutlich auf Stufe 1, möglicherweise in einzelnen Kontrolldimensionen zwischen Stufe 1 und 2. Die Einstufung muss je Änderungsklasse erfolgen: Dokumentation kann Stufe 3 erreichen, während Datenmigrationen bewusst auf Stufe 1 oder 2 verbleiben.

Metriken für die Umsetzung

Wirksamkeit der Sensors

• Erkennungsrate je Fehlerklasse auf einem kuratierten Fehler- oder Eval-Korpus;
• Mutation-Test-Score für geeignete Komponenten;
• Human-only finding rate;
• False-positive-Rate und Zahl irrelevanter Alarme;
• Anteil der Änderungen mit vollständigem Evidenzpaket;
• Anteil fachlicher Anforderungen mit ausführbarem Orakel;
• Fehler, die trotz grüner Sensors Test, Rollout oder Produktion erreichen.

Begrenzung und Wiederherstellung

• Anteil kleiner und sicher reversibler Änderungen;
• maximaler Schadensradius je Agentenrecht und Änderungsklasse;
• Zeit vom Fehler bis zur Erkennung;
• Zeit vom Alarm bis zum menschlichen Eingriff;
• Rollback-Erfolgsrate und Wiederherstellungszeit;
• Zahl blockierter Policy- oder Berechtigungsverstöße.

Für echte Human-on-the-Loop-Kontrolle muss die Summe aus Erkennung, Benachrichtigung, Bewertung und Eingriff kürzer sein als die Zeit, nach der eine Wirkung nicht mehr sicher rückgängig gemacht werden kann.

Menschliche Belastung und Eingriffsfähigkeit

• Reviewminuten pro Änderung;
• Zahl und Bearbeitungszeit der Ausnahmen pro Person;
• Anteil vollständig manuell geprüfter Änderungen;
• Zeit für Stichproben und Harness-Pflege;
• Unterbrechungen durch falsche Alarme;
• Diagnose- und Wiederherstellungsleistung bei Übungen;
• Verteilung des Systemwissens im Team.

Sinkende Reviewzeit ist nur dann ein Fortschritt, wenn Ergebnisqualität, Verständnis und Eingriffsfähigkeit erhalten bleiben.

Lernen des Harnesses

• Anteil menschlicher Befunde, die innerhalb einer festgelegten Frist in Guide, Sensor oder Eval überführt werden;
• Wiederholungsrate bereits bekannter Fehler;
• Zahl veralteter oder widersprüchlicher Regeln;
• Trefferquote und Schweregrad der Befunde aus Go See;
• Zeit zwischen Produktionsbefund und Harness-Anpassung;
• Anteil der Harness-Änderungen mit eigener vergleichender Evaluation.

Ergebnis und Flow

• Change Failure Rate;
• Produktionsdefekte und Security Incidents;
• Wiederherstellungszeit;
• Lead Time und Nacharbeit pro Änderung;
• SLO-Verletzungen;
• Performance- und Kostenregressionen;
• fachliche Outcome-Metriken.

Erzeugte Codezeilen, Agentenläufe oder Pull Requests sind keine Reifemetriken. Sie messen Aktivität und können sogar den nachgelagerten Engpass vergrößern.

Beispiel für ein lokales Freigabekriterium

Für eine konkrete risikoarme Änderungsklasse könnte das Team vor einem Bounded-HOTL-Pilot verlangen:

• mindestens 100 aufeinanderfolgende Änderungen im Shadow Mode;
• keinen ausschließlich menschlich gefundenen kritischen Fehler in dieser Stichprobe;
• eine vorab festgelegte Erkennungsrate auf einem repräsentativen Fehlerkorpus;
• vollständige automatische Build-, Test-, Policy- und Security-Prüfung;
• kleine, automatisch rücknehmbare Änderungen;
• keine Verschlechterung von Change Failure Rate oder Produktionsdefekten;
• erfolgreich geübte Alarm-, Eingriffs- und Rollbackkette;
• verbindliche Stichproben nach der Umstellung.

Diese Zahlen sind ein Beispiel für eine lokale Entscheidung und keine allgemeingültige Sicherheitsgrenze. Selbst null beobachtete Fehler in 100 Fällen beweisen keine Fehlerfreiheit; bei null Ereignissen liegt die grobe obere 95-Prozent-Grenze der unbekannten Rate nach der Dreierregel noch bei ungefähr drei Prozent. Für seltene, schwerwiegende Schäden reichen reine Betriebsbeobachtungen daher nicht aus. Hochriskante oder irreversible Änderungen benötigen stärkere konstruktive Nachweise und weiterhin menschliche Freigaben.

Gesamtmaßstab

Der Reifegrad beantwortet nicht primär die Frage, wie wenig Code Menschen noch lesen. Entscheidend ist, wie gut das Team:

1. gewünschtes Verhalten und Risiken spezifiziert;
2. Abweichungen zuverlässig und rechtzeitig erkennt;
3. Agentenautorität und Schadensradius begrenzt;
4. wirksam eingreifen und Änderungen zurücknehmen kann;
5. aus Befunden dauerhaft Guides, Sensors und Systemstruktur verbessert;
6. dabei Produktwirkung, Betriebsqualität und menschliche Kompetenz erhält.

Die offene Assurance-Frage bleibt damit bestehen, wird aber messbar: Menschliches Review kann für eine definierte Änderungsklasse erst dann teilweise ersetzt werden, wenn das alternative Kontrollsystem nachweislich vergleichbare oder bessere relevante Fehlererkennung, Begrenzung und Wiederherstellung bietet.