Müde vom Zuschauen: was bei KI-Müdigkeit hilft

18 Uhr. Der dritte Agentenlauf des Tages ist durch, du hast dich durch etwa 400 Zeilen Diff geklickt, zweimal nachgeschärft, und irgendwann durchgewinkt. Die Tickets sind zu. Und du sitzt da mit dem Gefühl, den ganzen Tag nichts gemacht zu haben.

Genau diese Rückmeldung kommt bei uns im Team gerade häufiger: Kolleg:innen sind nicht überarbeitet im klassischen Sinn, sondern leer. Sie schauen der KI beim Programmieren zu, prüfen, was sie nicht selbst gedacht haben, und verlieren dabei etwas, das schwer zu benennen ist: das Handwerk, die eigene Rolle darin, und das Gegenüber.

Ich habe die Literatur dazu durchgesehen. Die gute Nachricht vorweg: Das ist kein Motivationsproblem, und du bist damit nicht allein. Es ist ein beschriebenes arbeitswissenschaftliches Phänomen, und es gibt Gegenmaßnahmen, die mehrere Quellen unabhängig voneinander nennen.

Der Artikel geht in drei Schritten vor: erst woran es liegt, dann was du selbst ändern kannst, dann was nur das Team ändern kann.

Das Problem ist älter als die KI

Wer ein System nur noch beaufsichtigt, verliert zwei Dinge, und beide sind seit 1983 beschrieben. Damals veröffentlichte Lisanne Bainbridge in der Zeitschrift Automatica den Aufsatz Ironies of Automation, untersucht an Cockpits und Leitständen von Kraftwerken. Die beiden Folgen:

• Fertigkeitsverlust. Im Normalbetrieb übt man nichts mehr. Genau die Fähigkeiten, auf die es im Ausnahmefall ankommt, verfallen dabei, unbemerkt.
• Überwachungsermüdung. Eine Anzeige beobachten, auf der fast nie etwas passiert, zermürbt Menschen. Unabhängig davon, wie fähig oder motiviert sie sind.

Daraus folgt die Ironie im Titel: Je besser die Automatisierung wird, desto mehr Training braucht der Mensch, nicht weniger. Der Aufsatz wird bis heute zitiert, 2016 waren es über 1.800 Zitationen.

Auf Coding-Agenten übertragen hat das Uwe Friedrichsen, in Teil 1 die Diagnose und Teil 2 die Empfehlungen. Ein Befund daraus trifft jeden, der schon einen 300-Zeilen-Agentenplan gelesen hat: Für das Aufspüren von Fehlern ist die heutige Agenten-Oberfläche etwa das Schlechteste, was man bauen kann. Sein Vorschlag: abschauen, wie Leitstände in der Industrie gestaltet sind.

Wenn dich das Beaufsichtigen müde macht, funktionierst du korrekt. Die Luftfahrt kennt das Problem seit vierzig Jahren, und hält Gegenmaßnahmen für nicht verhandelbar.

Warum Prüfen nicht sättigt

Programmieren belohnte das Schreiben: das Lösen, das Verstehen, das Gefühl von Kontrolle. KI ersetzt das durch Prüfen, und Prüfen belohnt nicht. So sehen die beiden Abläufe nebeneinander aus:

Links steckt die Belohnung im Ablauf selbst: Am Ende läuft etwas, das du gebaut hast, und du weißt, warum. Rechts endet der Durchlauf im Prüfen, und wenn das Ergebnis nicht taugt, beginnt er von vorn. Es gibt keine Stelle, an der etwas fertig wird.

Deshalb hilft mehr Disziplin hier nicht: Es fehlt keine Anstrengung, sondern ein Ergebnis. Laura Summers nennt das bei Pydantic ein Problem der menschlichen Belohnungsfunktion, ausdrücklich kein persönliches Versagen (The Human-in-the-Loop is Tired):

"Der befriedigende Teil wurde kleiner. Der erschöpfende Teil wurde größer. Und es gibt keine neuen Belohnungen, die die Lücke füllen."

Was alles einzahlt

Die fehlende Belohnung ist der Kern, aber nicht die ganze Geschichte. Und darin liegt ein Grund, warum sich das Gefühl so schwer benennen lässt: Es hat viele kleine Ursachen, von denen keine allein genügt. Den ausführlichsten Praxisbericht liefern Ivan Chepurin und Travis Turner bei Evil Martians (AI-assisted engineers are burning out, is this fine?, Mai 2026), sie benennen zehn Ursachen. Zusammen mit Bainbridge und Summers ergeben sie drei Gruppen:

Die Einzelpunkte stehen in den Quellen, die Gruppierung ist meine. Sie hilft aber bei der Entscheidung, was man zuerst anfasst: Gegen jede Gruppe wirken andere Mittel, und wer nur an einer schraubt, merkt entsprechend wenig.

Erste Frage: Was genau fehlt dir?

Der wichtigste Punkt aus der ganzen Recherche ist auch der, den man am leichtesten überspringt: Frag zuerst, was konkret abhandengekommen ist. Bei manchen ist es das Schreiben, bei anderen das Debuggen, bei wieder anderen das Gespräch mit einem Menschen. Die Gegenmaßnahmen unterscheiden sich stark, und wer die falsche wählt, hält sich für einen hoffnungslosen Fall, obwohl nur die Diagnose nicht passte.

Die Tabelle sagt dir, wo du ansetzen solltest. Die Hebel selbst liegen auf drei Ebenen, und nur die erste gehört dir allein:

Die nächsten drei Abschnitte gehen diese Ebenen der Reihe nach durch, angefangen bei deiner eigenen, weil du dort niemanden überzeugen musst.

Fünf Dinge, die du ab morgen selbst machen kannst

1. Setz ein Iterationslimit. Nach drei bis vier erfolglosen Anläufen brichst du ab und schreibst selbst, oder wechselst den Ansatz. Das beendet die Endlos-Verfeinerungsschleife, die mehrere Quellen als Hauptermüder nennen. Sie ist so verführerisch, weil jeder einzelne weitere Versuch billig aussieht; in Summe kostet sie den Tag. Evil Martians nennt genau diese Zahl.

2. Stapel keine KI-lastigen Aufgaben. Zwischen zwei Agentenläufe kommt etwas, das nicht aus Prüfen besteht: ein Bugfix von Hand, ein Gespräch, Dokumentation. Auch mehrere Läufe gleichzeitig zu betreuen ist keine gute Idee, so effizient es aussieht. Beides steht so bei Evil Martians: nicht zwei KI-schwere Aufgaben hintereinander, keine Parallelarbeit.

3. Zieh deine Denkarbeit nach vorn, mit einem Pre-mortem. Bevor der Agent losläuft, nimm dir zwei Minuten und beantworte drei Fragen:

• Wo wird das hier scheitern?
• Was habe ich in der Aufgabenstellung nicht gesagt, das der Agent falsch annehmen wird?
• Woran würde ich merken, dass das Ergebnis nur aussieht wie eine Lösung?

Das ist dieselbe Denkarbeit, die du sonst nachher beim Prüfen leistest, nur an der Stelle, wo sie noch etwas gestaltet, statt nur abzunicken. Summers beschreibt, dass Teams dafür sogar eine frische Sitzung ansetzen, die von einem Fehlschlag ausgeht und die Lücken in der Spezifikation sucht.

4. Führ ein Erfolgs-Log. Zwei Zeilen am Tagesende: Was ist fertig geworden? Und dann zeig es, Demo im Team, kurz im Kanal. Das klingt nach Selbsthilfe-Ratgeber, ist aber genau die Lücke aus dem Diagramm oben: Wo das Erfolgserlebnis nicht mehr im Ablauf steckt, musst du es bewusst herstellen. Bei Evil Martians steht diese Maßnahme an erster Stelle.

5. Verteidige Handarbeitszeit, als Übungserhalt, nicht als Belohnung. Nimm dir regelmäßig eine Aufgabe, die du komplett selbst machst. Der Grund ist der Fertigkeitsverlust von oben: Expert:innen-Fähigkeiten verfallen überraschend schnell, und regelmäßiges Selbst-Übernehmen ist laut Friedrichsen eine sehr wirksame Übungsform. Die Luftfahrt nennt es Simulatortraining und diskutiert nicht darüber.

Auf die Begründung kommt es an: Wer Handarbeit als Hobby verkauft, verliert sie beim nächsten Termindruck. Wer sie als Übungserhalt begründet, hat ein Argument.

Vier Dinge, die das Team ändern muss

Diese Hebel kann niemand allein ziehen, sie gehören in die Retro, nicht in den eigenen Kalender.

• Review-Last verteilen statt konzentrieren. CODEOWNERS auf Teams statt Einzelpersonen, Round-Robin, und ein Deckel, zum Beispiel: niemand prüft dauerhaft mehr als ein Viertel aller PRs. Ohne das tragen die erfahrenen Leute die gesamten Kosten der Beschleunigung und haben nichts von der Freude. Review-Staus stehen bei Evil Martians ausdrücklich in der Ursachenliste.
• Kleine Diffs erzwingen. Je schneller Code entsteht, desto kleiner müssen die Häppchen werden. Ab einer bestimmten Größe ist ehrliches Prüfen nicht mehr möglich, nur noch Abnicken, und Abnicken ist der Zustand, der leer macht und riskant ist. Wie schnell die Prüfung zur Formalie wird, zeigt Die 79-Prozent-Falle.
• Pairing beibehalten. Allein mit einem Agenten fehlt das Gegenüber; Vereinzelung ist der unterschätzte Teil der Erschöpfung. Thoughtworks nennt Pair Programming und aktiven Wissenstransfer als Gegenmittel.
• Implizites Wissen kodifizieren. Eure Review-Muster und Architekturregeln wandern in die Agenten-Guidelines. Summers beschreibt jemanden, der Jahre eigener Review-Kommentare in Agenten-Anweisungen übersetzt hat. Das ist anspruchsvolle Expertenarbeit, sie bleibt sichtbar menschlich, und sie macht die Aufsicht danach leichter. Wie so ein Netz aus Regeln und Prüfungen aufgebaut ist, steht in Harness Engineering.

Was das Management hören muss

Geschützte Qualitätszeit bekommst du leichter budgetiert, wenn du sie nicht als Handwerksstolz begründest, sondern als Risikominderung. So argumentiert Cecilia Geraldo bei Thoughtworks in Why AI is raising the stakes of the software engineering craft: Handwerk ist keine Ästhetikfrage. Damit wird es budgetierbar, statt ein Hobby zu sein, das man sich nach Feierabend erlaubt.

Der zweite Punkt fürs Gespräch: KI wirkt vor allem als Verstärker und vergrößert die bestehenden Stärken und Schwächen einer Organisation. Der Satz steht im State of AI-assisted Software Development 2025 von DORA. Für uns heißt das: Wenn die Erschöpfung jetzt sichtbar wird, liegt der Hebel wahrscheinlich nicht am Werkzeug, sondern an den Engpässen, die vorher schon da waren: Review-Staus, Zeitdruck, unklare Zuständigkeiten. Genau dort ansetzen.

Und eine Sache braucht gar keine Maßnahme, nur eine Entscheidung: Die ersten Wochen mit einem neuen Werkzeug sind kein Maßstab. Wird die Anfangsspitze zur Erwartung, entsteht genau der Druck, der ermüdet. Evil Martians führt diese falsche Erwartung als eigene Ursache.

Die Identitätsfrage, drei Antworten, die ich brauchbar finde

Bleibt der Teil, der sich am wenigsten mit Prozess lösen lässt: das Gefühl, dass das eigene Handwerk abgewertet wird. Drei Autoren beantworten das unterschiedlich, und alle drei fand ich brauchbar.

Das Handwerk verschwindet nicht, es verschiebt sich. Kent Beck, seit fünfzig Jahren dabei, beschreibt den Wechsel so: Man trifft mehr folgenreiche Entscheidungen pro Stunde und weniger langweilige. Wer am Programmieren das Mustererkennen liebte, findet es wieder. Dass Beck weiter öffentlich Code schreibt, ist der Grund, warum ihm das jemand abnimmt (Augmented Coding: Beyond the Vibes).

Die Abgrenzung ist die Verteidigung, nicht die Aufgabe des Berufsbildes. Addy Osmani argumentiert, dass erst das Vermischen von Vibe Coding und professioneller KI-gestützter Entwicklung die Ingenieursdisziplin entwertet. Wer den Unterschied sauber zieht, verteidigt also das Berufsbild. Sein Buch Beyond Vibe Coding ist kostenlos online lesbar; wo die Grenze in der Praxis verläuft, beschreibt Von Vibe Coding zu Agentic Engineering.

Agentenarbeit ist selbst eine Disziplin, die man üben kann. Das fand ich praktisch am hilfreichsten: Simon Willison behandelt sie als eigenständiges Handwerk mit erlernbaren Mustern (Agentic Engineering Patterns). Damit gibt es wieder etwas, worin man besser werden kann, genau die Schleife, die beim reinen Beaufsichtigen fehlt.

Ehrlich zu den Belegen

Drei Einschränkungen, die dazugehören:

Keine dieser Quellen hat belastbare Langzeitdaten. Es sind gut begründete Erfahrungsberichte plus übertragene Forschung aus anderen Domänen. Als solche brauchbar, als bewiesene Wahrheit nicht.

Der Identitätsverlust steht nicht bei Bainbridge. Ihr Aufsatz belegt Fertigkeitsverlust und Überwachungsermüdung. Das Gefühl, vom Experten zum Aufseher degradiert zu werden, beschreiben die aktuellen Praxisberichte, nicht die Arbeit von 1983.

DORA belegt den Verstärker-Effekt, nicht mehr. Einen Befund "KI verursacht (kein) Burnout" habe ich dort nicht gefunden. Die Suchrichtung "schaut auf die Engpässe" trägt trotzdem.

Und ein Filter für alles, was dir zu diesem Thema noch zugeschickt wird: Texte, die ein Defizit bei dir diagnostizieren und nichts vorschlagen, helfen nicht. Nachwuchs-Untergangsprognosen, Nostalgie-Essays über das verlorene Handwerk, "wer nicht mitzieht, wird ersetzt", das erzeugt Scham oder Zynismus. Beides macht nicht handlungsfähig.

Nicht du bist zu langsam für die KI. Die Belohnung ist an die falsche Stelle gewandert, und das lässt sich zurückbauen.

Jetzt bist du dran

Fang mit einer Sache an, nicht mit allen. Die mit dem besten Verhältnis von Aufwand zu Wirkung:

Setz dir diese Woche ein Iterationslimit von drei Anläufen und schreib den vierten selbst. Notier abends in zwei Zeilen, was fertig geworden ist. Das kostet dich nichts, und du merkst nach drei Tagen, ob es wirkt.

Und dann, wenn du magst, weiter:

• Im Team ansprechen: Bring die Frage "Was genau fehlt dir?" in die nächste Retro, die Tabelle oben taugt als Gesprächseinstieg.
• Teilen: Deine Review-Muster als Agenten-Guidelines kodifiziert? Leg sie dort ab, wo die anderen Teams in eurem Haus sie finden. Die stehen vor derselben Aufgabe.
• Mitschreiben: Bei dir hat etwas geholfen, das hier nicht steht? Genau solche Berichte fehlen der Literatur noch. Melde dich, wir helfen beim Schreiben.

Wenn du nur zwei Dinge weiterleitest: Evil Martians für Anerkennung samt Rezept, und Friedrichsen Teil 1 + 2 für die Einsicht, dass das Problem älter ist als die KI.

Wer es strukturiert angehen will, findet in Exploring Generative AI von Birgitta Böckeler und Kolleg:innen bei Thoughtworks laufende Feldnotizen aus echten Projekten, inklusive der Stellen, an denen es nicht funktioniert hat. Besonders passend sind die Memos zu Harness Engineering und Context Engineering: anspruchsvolle Arbeit, die sichtbar von Menschen gemacht wird.

Gastbeitrag von Andy-Kim Möller, AI Evangelist bei der ATVANTAGE GmbH. Der Text erschien zuerst im internen ATVANTAGE AI Hub und steht hier mit seiner Erlaubnis.