1943 beauftragte die britische Royal Air Force einen Psychologen namens Norman Mackworth mit einer Frage: Warum verpassten ihre Radaroperatoren deutsche U-Boot-Signale, obwohl sie direkt vor dem Bildschirm saßen?
Mackworth baute einen Apparat, der heute als Mackworth Clock bekannt ist. Ein Zifferblatt, ein Zeiger, der in regelmäßigen Abständen springt. Hin und wieder macht der Zeiger einen doppelten Sprung. Die Aufgabe: diesen doppelten Sprung melden.
Das Ergebnis war unangenehm. Die Erkennungsrate fiel innerhalb der ersten fünfzehn Minuten messbar ab. Nach dreißig Minuten war sie deutlich schlechter als zu Beginn. Den Versuchspersonen zu sagen, sie sollen aufmerksamer sein, half nichts.
Das war 1943. Wir haben seitdem nichts Wesentliches daran geändert.
Vigilanz-Dekrement
Im ersten Teil dieser Serie habe ich beschrieben, was die Luftfahrt über Automatisierung gelernt hat. Dieser Teil geht eine Ebene tiefer: Warum funktioniert menschliche Überwachung von automatisierten Systemen strukturell nicht — und was verlieren wir dabei über die Zeit?
Das Phänomen, das Mackworths Experiment beschreibt, heißt Vigilanz-Dekrement. Gemeint ist der Leistungsabfall bei monotonen Überwachungsaufgaben über die Zeit. Der Befund ist robust, gut repliziert und gilt für praktisch alle Menschen.
Das klingt paradox: Wer nichts tut, ist trotzdem erschöpft. Aber genau das zeigen Warm, Parasuraman und Matthews in einer Studie von 2008. Überwachen ist kognitiv anstrengend. Das Gehirn erschöpft tatsächlich Ressourcen, es läuft nicht im Leerlauf. Nur dass die Erschöpfung nicht als Anstrengung wahrgenommen wird, sondern als Langeweile und Drift.
Was das für die Softwareentwicklung bedeutet: Ein Entwickler, der KI-generierten Code reviewed, sitzt an einer Mackworth Clock. Die meisten Zeigerbewegungen sind normal. Fehler sind selten. Die Aufmerksamkeit driftet. Und wer in diesem Moment sagt “du musst einfach aufmerksamer sein”, löst das Problem genauso wenig wie es 1943 bei den Radaroperatoren funktioniert hat.
Out of the Loop
Das zweite Problem ist struktureller. Es heißt Out of the Loop.
Das Konzept dafür heißt Situationsbewusstsein. Mica Endsley hat es 1995 in drei Ebenen aufgedröselt. Erste Ebene: Wahrnehmen, was gerade passiert. Zweite Ebene: Verstehen, was das bedeutet. Dritte Ebene: Antizipieren, was als nächstes kommt.
Automatisierung greift in alle drei Ebenen ein. Wer eine Maschine überwacht statt selbst zu handeln, nimmt weniger wahr, versteht weniger und kann weniger voraussehen. Die Dritte Ebene wird am stärksten beschädigt, weil das aktive Aufbauen eines mentalen Modells aufhört.
Kein Versagen, sondern was passiert, wenn ein Mensch passiv beobachtet statt aktiv handelt.
Wenn der Autopilot sich trennt, muss der Pilot nicht nur die Kontrolle übernehmen. Er muss gleichzeitig herausfinden, wo das Flugzeug überhaupt steht, was es gerade macht, und warum das System ausgefallen ist. Mit einem mentalen Modell, das seit Stunden nicht mehr aktiv aufgebaut wurde.
Ein Entwickler, dessen Agent Code selbstständig schreibt, merged und deployed, hat dasselbe Problem. Wenn etwas schiefläuft, muss er sich in eine Codebase eindenken, die er nicht geschrieben hat, in Entscheidungen, die er nicht getroffen hat, in ein System, das er zuletzt wirklich verstanden hat, bevor die Automatisierung anfing.
Automation Complacency
Das dritte Problem ist Complacency.
Wer einem zuverlässigen System vertraut, hört auf, aktiv nach seinen Fehlern zu suchen. Parasuraman und Manzey nennen diesen Mechanismus Automation Complacency, so der Kernbefund ihrer Studie von 2010. Manzey habe ich übrigens selbst gehört. Luftfahrtpsychologie und Arbeits- und Organisationspsychologie. Was damals nach solider Theorie klang, bekommt im Kontext von KI-Agenten eine andere Dringlichkeit.
Es gibt zwei Ausprägungen. Die erste sind Omission Errors: Fehler werden nicht bemerkt, weil das System sie normalerweise meldet, und das Gehirn aufgehört hat, aktiv danach zu suchen. Die zweite sind Commission Errors: Automatisierten Empfehlungen wird gefolgt, auch wenn andere Informationen widersprechen, weil das Vertrauen in das System größer ist als das eigene Urteil.
Der unangenehme Befund: Das gilt für Neulinge genauso wie für Experten. Training allein verhindert es nicht.
Kognitive Erosion
Das vierte Problem ist das, was am tiefsten geht.
Steve Casner untersuchte 2014 sechzehn Airline-Piloten in einem Boeing-747-Simulator bei systematisch variiertem Automatisierungsgrad. Die Frage: Was genau verfällt? Sein Befund war präzise: Motorische Fähigkeiten bleiben weitgehend stabil, kognitive verfallen.
Casner beschrieb es so: Weniger Sorgen machen sollten wir uns um das, was Piloten mit der Hand tun. Mehr Sorgen um das, was sie mit dem Kopf tun.
Was Piloten verlieren, ist nicht die Motorik, sondern das Denken: die mentale Simulation, was als nächstes passieren wird, das Verständnis von Systemzuständen ohne visuelle Darstellung und die Intuition für anomale Muster.
Für die Softwareentwicklung ist das der entscheidende Übertrag: nicht die Fähigkeit, Code zu tippen, sondern die Fähigkeit, über Code nachzudenken, Architekturentscheidungen zu evaluieren, Bugs in fremdem Code zu finden und Systeme zu verstehen, die man nicht selbst gebaut hat.
Genau diese Fähigkeiten braucht man, um KI-generierten Code sinnvoll zu reviewen.
Malleable Attentional Resources
Es gibt noch einen letzten Aspekt, der selten diskutiert wird.
Kognitive Kapazität ist keine Konstante. Das Gehirn schrumpft mit den Anforderungen. Young und Stanton haben diesen Mechanismus 2002 als Malleable Attentional Resources beschrieben. Wenn die Anforderungen sinken, schrumpft die verfügbare Kapazität.
Wer passiv KI-Output beobachtet, spart keine mentale Energie für schwierige Momente auf. Stattdessen reduziert das Gehirn die bereitgestellten Ressourcen. Wenn der schwierige Moment kommt, steht weniger Kapazität zur Verfügung als erwartet.
Daraus erklärt sich, warum selbst erfahrene Entwickler bei einem Produktionsausfall im KI-generierten Code überfordert wirken, obwohl sie technisch dazu in der Lage sein sollten. Sie sind nicht plötzlich schlechter. Ihr Gehirn war gerade woanders.
Der eigentliche Befund
Das ist der eigentliche Befund. Nicht: Menschen sind zu unaufmerksam für Überwachungsaufgaben. Sondern: Überwachungsaufgaben bauen systematisch genau die Fähigkeiten ab, die man braucht, wenn etwas schiefgeht. Wer einen Agent beobachtet statt mitzudenken, ist in dem Moment, in dem er gebraucht wird, schlechter vorbereitet als vorher.
Im dritten Teil dieser Serie geht es darum, was das für die Praxis bedeutet. Welche Daten es aus der Softwareentwicklung gibt. Und was die Luftfahrt getan hat, um mit diesen Problemen umzugehen.
Quellen
- Mackworth, N. H. (1948): The breakdown of vigilance during prolonged visual search
- Warm, J. S., Parasuraman, R. & Matthews, G. (2008): Vigilance Requires Hard Mental Work and Is Stressful. Human Factors, 50(3), 433–441.
- Endsley, M. R. (1995): Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors, 37(1), 32–64.
- Parasuraman, R. & Manzey, D. H. (2010): Complacency and Bias in Human Use of Automation. Human Factors, 52(3), 381–410.
- Casner, S. M., Geven, R. W., Recker, M. P. & Schooler, J. W. (2014): The Retention of Manual Flying Skills in the Automated Cockpit. Human Factors, 56(8), 1506–1516.
- Young, M. S. & Stanton, N. A. (2002): Malleable Attentional Resources Theory. Human Factors, 44(3), 365–375.