# Wenn die Agenten den Code schreiben, prüft der Mensch sich selbst [2/2]

Sozialpsychologisch ist Decision Fatigue beschrieben seit Baumeister und Kollegen 1998 [1]. Die genaue Mechanik (Ego Depletion als zentraler Willensspeicher) ist nach einer multilab-präregistrierten Replikation mit 23 Laboren und über 2000 Teilnehmern stark in Frage gestellt [2]. Das Phänomen selbst ist es nicht: Die Qualität einer Entscheidung sinkt messbar im Laufe einer Entscheidungs-Sequenz. Die robusteste Evidenz dazu kommt aus einer PNAS-Studie über mehr als 1000 reale Bewährungs-Entscheidungen von acht erfahrenen Richtern, beobachtet über 50 Sitzungstage [3]. Direkt nach einer Pause oder dem Mittagessen werden rund 65 Prozent der Anträge bewilligt. Im Laufe der folgenden Session fällt die Quote allmählich, in einzelnen Sessions bis nahe Null, und springt nach der nächsten Pause wieder zurück. Eine konzeptionelle Übersichtsarbeit aus der Health-Psychology bestätigt, dass das Phänomen quer durch Berufsgruppen auftaucht [4]. Aus der klinischen Entscheidungsforschung kommt eine zweite, unabhängige Bestätigung: Eine Studie an über 21.000 ambulanten Visiten in Hausarztpraxen zeigt, dass Ärzte im Verlauf jeder Sprechstunde zunehmend häufiger unangemessen Antibiotika verschreiben, mit Spitze in den letzten Stunden vor der Mittagspause [5]. Gleicher Mechanismus, anderer Kontext, gleiche Richtung.

Was in einem agentischen Setup passiert, ist die schnelle Übersetzung dieses Mechanismus in den Entwickleralltag. Wo ich früher in zwei Stunden vielleicht acht bewusste Entscheidungen getroffen habe („nehme ich diese Library, refactor ich diese Methode, schreibe ich diesen Test“), sind es jetzt gefühlt vierzig. Die Agenten produzieren in derselben Zeit ein Vielfaches des zu entscheidenden Materials. Das Tippen war nicht das Anstrengende. Das Beurteilen ist es.

Für Tester ist das doppelt interessant. Auch wer im klassischen Setup die Rolle „Reviewer von Code, den jemand anderes geschrieben hat“ hatte, kennt diese Müdigkeit schon. Sie wird in der agentischen Welt nicht neu erfunden, sondern verallgemeinert: Plötzlich ist jeder, der mit Agenten arbeitet, ständig in der Reviewer-Position. Was bei klassischen Code-Reviews eine zeitlich abgegrenzte Aufgabe war, wird zum Dauerzustand.

Der Effekt im Alltag klingt unverdächtig. Du fängst an, schneller „OK“ zu klicken. Du liest Diffs, die du eigentlich Zeile für Zeile prüfen müsstest, im Querflug. Du nimmst Architekturvorschläge an, bei denen du gestern noch gefragt hättest „warum eigentlich“. Niemand sagt das laut. Aber fast jeder, der ehrlich mit dem Setup arbeitet, kennt diesen Moment am späten Nachmittag.

Der zweite Kostenfaktor ist Context Switching. Die Kosten von Kontextwechseln sind in der Software-Engineering-Praxis seit Jahrzehnten Folklore und in der CHI-Forschung gut belegt. Eine Feldstudie an Wissensarbeiter:innen findet im Schnitt rund 25 Minuten, bis eine unterbrochene Aufgabe wieder aufgenommen wird, typischerweise nach mehr als zwei zwischenliegenden anderen Aufgaben [6]. Eine Folgestudie zeigt, dass unterbrochene Aufgaben zwar messbar schneller fertig werden, aber zu einem messbaren Preis aus mehr Stress, Frustration und Anstrengung [7]. Speziell für Programmierer-Arbeit ist die Lage noch deutlicher. Parnin & Rugaber 2011 untersuchen empirisch, wie Entwickler nach einer Unterbrechung wieder in den Code zurückfinden, und finden, dass sie nicht einfach dort weitermachen, wo sie aufgehört haben; sie investieren erkennbar Zeit in Wiederherstellungs-Strategien wie Code-Notizen, gezielt offen gelassene Compile-Fehler als Lesezeichen, oder das Wiederlesen des letzten Commits, weil der mentale Stack tiefer ist als bei generischer Wissensarbeit [8].

In einer agentischen Supervision sitzt der Kontextwechsel nicht zwischen den Stunden, sondern innerhalb des Arbeitsblocks. Du springst vom Refactor-Review zur E2E-Diagnose zum Architektur-Entscheid zum Logging-Detail. Vier verschiedene Kontexte, vier verschiedene mentale Modelle, alle in dreißig Minuten. Jeder Sprung kostet Aufbau. Und weil die Agenten parallel arbeiten und nicht warten, ist die Versuchung groß, jeden so anzunehmen, wie er gerade reinkommt.

Was hilft, ist klassische Engineering-Disziplin in neuem Gewand: Class-batched Reviews. Alle Refactor-Reviews in einem Block. Alle Architektur-Entscheide in einem zweiten. Test-Diagnosen in einem dritten. Das klingt nach Selbstverständlichkeit und ist es nicht; die Agenten verhalten sich wie ein Großraumbüro, in dem ständig jemand an deinem Schreibtisch steht.

Der Trick ist nicht, mehr Agenten gleichzeitig zu führen. Der Trick ist, dass nur eine Sorte Frage zu einer Zeit bei dir ankommt.

Der dritte Bottleneck ist der heimtückischste, weil er sich nicht als Müdigkeit anfühlt, sondern als Routine. Aufmerksamkeitsspanne unter Dauer-Review.

Die kognitive Psychologie kennt das Phänomen als Vigilance Decrement, dokumentiert seit Mackworths Klassiker-Studie zur Radar-Beobachtung im Zweiten Weltkrieg [9]: Wer über längere Zeit aufmerksam etwas überwachen soll, bei dem nur selten ein Fehler auftaucht, verliert die Fähigkeit, ihn zu entdecken. Mackworth fand im Labor einen Rückgang der Erkennungsrate um 10 bis 15 Prozent innerhalb der ersten dreißig Minuten, mit weiterer Verschlechterung danach. Eine viel zitierte Übersichtsarbeit aus den Human Factors überträgt das Muster auf moderne Automation: Wenn der Mensch eine automatisierte Pipeline überwacht und parallel selbst Aufgaben hat, steigt die Complacency, und einfaches Üben hilft nicht dagegen [10]. Aktuellere Forschung speziell zur menschlichen Aufsicht über KI-Vorschläge zeigt das Muster in seiner heutigen Form. Vasconcelos und Kollegen belegen 2023 empirisch, dass Nutzer KI-Vorschläge tendenziell ohne eigene Prüfung übernehmen, sobald sie den kognitiven Aufwand der Verifikation als zu hoch wahrnehmen; selbst gut konstruierte Erklärungen senken diese Über-Übernahme nur bedingt, weil der Mensch eine simple Kosten-Nutzen-Rechnung anstellt [11]. In der agentischen Supervision ist das exakt die Situation: viele Vorschläge, jeder einzeln plausibel klingend, eine echte Verifikation teurer als das Akzeptieren.

Praktisch heißt das: Nach dreißig Minuten kontinuierlicher Review-Arbeit fällt die Erkennungsrate. Du siehst Bugs nicht mehr, die du nüchtern sofort gesehen hättest. Und weil die Agenten weiterproduzieren, summiert sich dieser Effekt schnell.

Aus meiner eigenen Praxis, eine Einzel-Beobachtung, kein Studienbefund: Wenn ich länger als eine halbe Stunde am Stück Agenten-Output prüfe, finde ich beim wiederholten Lesen nach einer Pause Dinge, die ich beim ersten Durchgang nicht gesehen habe. Das ist derselbe Mechanismus, den die Code-Review-Forschung seit den Anfängen formaler Inspektionen kennt; bereits Fagan empfiehlt 1976, eine Inspektions-Session auf maximal zwei Stunden zu begrenzen und nicht mehr als 150 Zeilen pro Stunde durchzusehen, weil die Defekt-Detektionsrate sonst signifikant einbricht [12]. Eine moderne empirische Untersuchung der Code-Review-Praxis bei Microsoft erweitert das Bild: Reviews drehen sich in der heutigen, asynchronen Praxis weniger um reine Defekt-Detektion als erwartet; ein Großteil der dokumentierten Reviewer-Hinweise zielt auf Code-Verständnis und Wissenstransfer im Team [13]. Das macht die Aufmerksamkeits-Anforderung an den Reviewer nicht kleiner, sondern verschiebt sie. In der agentischen Welt wird derselbe Effekt nur permanent statt situativ.

Wenn die drei Bottlenecks zusammenkommen, gibt das ein Muster, das ich inzwischen ernst nehme. Drei Hebel, die in meiner täglichen Praxis funktionieren:

Erstens, eine Decision-Budget-Logik. Eine Langzeitstudie an 27 CEOs großer Unternehmen, die über 13 Wochen rund um die Uhr begleitet wurden, zeigt das Muster sauber: Top-Führungskräfte verbringen den größten Teil ihrer Arbeitszeit in Meetings, in denen vor allem priorisiert, eingeordnet und weitergegeben wird; die echten strategischen Eigen-Entscheidungen sind eine deutliche Minderheit [14]. Im agentischen Setup entscheidest du dagegen erstmal alles selbst. Das musst du explizit korrigieren: Welche Entscheidungen sind reversibel und billig (Code-Kommentar, kleines Refactor in interner Library) und gehen ohne Review durch? Welche sind reversibel und teuer (größerer Refactor, Architektur-Detail)? Welche sind nicht reversibel (Schemaänderung in der Produktion, externe Schnittstelle)? Die erste Kategorie wandert in Auto-Approve, die dritte bleibt strikt beim Menschen.

Zweitens, in Gruppen führen statt zwischen Einzelagenten zappeln. Drei feste Slots am Tag sind die saubere Idealfigur und in der Praxis selten machbar; in einer warmen Agenten-Flotte musst du ständig irgendwo einhaken. Was aber funktioniert, sobald du nicht mehr nur vier Agenten parallel führst, sondern eher zwölf oder sechzehn, ist eine Bündelung in thematische Gruppen mit eigenem Schwerpunkt. Eine Gruppe arbeitet am Backend, eine an den Tests, eine an Doku und kleinen Bugfixes. Du widmest dich aktiv jeweils einer Gruppe, statt zwischen den Agenten verschiedener Gruppen hin und her zu springen.

Das funktioniert wie bei einem Dogwalker mit mehreren Hundegruppen gleichzeitig. Er führt aktiv eine Gruppe; die anderen stehen herum, schauen sich um oder laufen am Ziel, an dem sie ohnehin gerade spielen. Wenn er wechselt, wechselt er auf Gruppen-Ebene, nicht zwischen einzelnen Hunden zweier paralleler Gruppen. Genau das ist der Unterschied zwischen funktionierender Parallel-Aufsicht und chronischem Zappeln.

Drittens, einen dreißig-Minuten-Cap auf kontinuierliche Review-Arbeit. Mit anschließender Pause, die nicht wieder Bildschirm ist. Bewegung, Kaffee, Wand anschauen. Die Vigilance-Forschung ist da deutlich genug, dass man nicht weiter optimieren muss.

Wer agentisches Entwickeln nur über die Achse „schneller und billiger“ misst, misst die falsche Sache. Geschwindigkeit ist eine Selbstverständlichkeit geworden, kein Differenzierungsmerkmal. Was Software heute auszeichnet, ist nicht mehr, dass sie geliefert wird, sondern dass sie einzigartig ist. Dass sie etwas tut, was nicht in jedem zweiten Repository auch steht. Dass der Mensch, der sie verantwortet, sich wirklich noch im Loop befindet, mit den drei oben genannten Bottlenecks unter Kontrolle.

Für die Testing-Community heißt das, finde ich, zwei Dinge.

Das eine: Die Rolle des Testers verschwindet nicht in einer agentischen Welt. Sie wird zentraler. Was die Agenten produzieren, muss jemand prüfen, der den Kontext hält. Das ist exakt die Kompetenz, die gute Tester schon immer hatten. Sie wird jetzt nur unter neuen Bedingungen abgefragt.

Das andere: Die drei Bottlenecks oben gelten besonders für Menschen in Review-Rollen. Wer das Setup ernst nimmt, baut Schutzwälle. Wer das nicht tut, läuft Gefahr, die KI in einem halben Jahr mit dem Argument, „war nichts für uns“, wieder abzuschaffen. Der Unterschied liegt nicht in der KI. Er liegt in der Architektur drumherum.