Ich saß mal in einem Seminar, und der Dozent fragte: Was ist das Gefährlichste an einem zuverlässigen System? Niemand antwortete. Er sagte: Dass du ihm vertraust.
Das war Human Factors, irgendwann im zweiten oder dritten Semester. Luftfahrt- und Automatisierungsychologie, Mensch-Maschine-Interaktion. Ich fand das damals faszinierend, aber auch ziemlich weit weg von dem, was ich täglich tat. Jetzt, wo autonome Agenten Code schreiben und committen und deployen, denke ich an diesen Satz öfter als mir lieb ist.
Die Luftfahrt hat diese Fragen Jahrzehnte vor uns durchgearbeitet. Und die wichtigsten Antworten liegen in Papieren, die die meisten Entwickler nie gelesen haben.
228 Menschen und ein Autopilot
Juni 2009. Ein Airbus A330 fliegt über den Atlantik, 35.000 Fuß hoch, mitten in der Nacht. Die Pitot-Rohre vereisen. Die Geschwindigkeitssensoren liefern widersprüchliche Werte. Der Autopilot trennt sich. Das System gibt die Kontrolle zurück an die Piloten.
In den nächsten dreieinhalb Minuten ignorieren die Piloten 75 Stall-Warnungen. Der Pilot am Steuer zieht die Nase des Flugzeugs permanent nach oben, was den Strömungsabriss vertieft. Niemand bemerkt es, weil niemand mehr wirklich versteht, was gerade passiert. Air France Flug 447 stürzt in den Atlantik. 228 Menschen sterben.
Das war kein Pilotenfehler im klassischen Sinne. CRM hatte versagt, das Cockpit-Design verbarg, dass beide Piloten gleichzeitig gegenläufig steuerten, die Ausbildung hatte diesen Grenzfall nie abgedeckt. Automatisierung war der Auslöser, nicht die einzige Ursache. Aber es gibt eine Ursache, die in keinem Unfallbericht steht.
Vier Stufen, vier Eingriffspunkte
Seit rund zwanzig Jahren gibt es in der Luftfahrtpsychologie ein Modell, das genau diese Ursache beschreibt. Und es trifft mit erschreckender Präzision, was gerade in der Softwareentwicklung passiert.
Das Modell stammt von Raja Parasuraman, Thomas Sheridan und Christopher Wickens. Ihr Paper von 2000 beschreibt Automatisierung nicht als An-oder-Aus-Schalter, sondern als Eingriff in spezifische Stufen menschlicher Informationsverarbeitung.
Es gibt vier Stufen:
Die erste ist die Informationsaufnahme. Was nehme ich wahr? Welche Daten bekomme ich? Automatisierung hier bedeutet: ein Radar filtert Ziele, ein Lint-Tool markiert Fehler, ein Monitoring-Dashboard hebt Anomalien hervor.
Die zweite ist die Informationsanalyse. Was bedeuten diese Daten? Ein Wettermodell berechnet Prognosen. Ein Codeanalyse-Tool schlägt Refactorings vor.
Die dritte ist die Entscheidung. Was tue ich jetzt? Hier beginnt die gefährliche Zone. Der Autopilot wählt die Flugroute. Das KI-Modell schlägt eine Architektur vor, schreibt die Implementierung.
Die vierte ist die Ausführung. Die Maschine setzt die Entscheidung um. Fly-by-wire. Oder: ein autonomer Agent schreibt Code, öffnet einen Pull Request, merged ihn.
Jede Stufe kann automatisiert werden. Aber der Grad der Automatisierung bestimmt, wie viel der Mensch noch versteht, was gerade passiert.
Stufe 4 oder Stufe 9?
Thomas Sheridan hat das schon 1978 auf eine einfache Skala gebracht. Zehn Stufen, von eins bis zehn.
Auf Stufe 1 macht der Mensch alles selbst. Auf Stufe 4 empfiehlt der Computer eine Option, der Mensch entscheidet. Auf Stufe 6 führt der Computer aus, außer der Mensch vetot rechtzeitig. Auf Stufe 10 agiert der Computer vollständig autonom und ignoriert den Menschen.
GitHub Copilot bewegt sich ungefähr auf Stufe 4 bis 5. Autonome Coding-Agenten, die selbstständig Aufgaben abarbeiten und committen, sind auf Stufe 7 bis 9.
Das klingt nach einer technischen Unterscheidung. Es ist aber eine psychologische.
Die Ironie der Automatisierung
1983 hat Lisanne Bainbridge einen Aufsatz geschrieben, der in der Human Factors Forschung bis heute als Grundlagentext gilt. “Ironies of Automation” heißt er, fünf Seiten, über 1800 Zitierungen. Die zentrale These ist brutal einfach.
Automatisierung entsteht, weil Menschen unzuverlässig sind. Also übernimmt die Maschine die Routinearbeit. Der Mensch überwacht. Klingt vernünftig.
Aber genau hier beginnt das Problem.
Erstens: Je zuverlässiger die Maschine, desto seltener greift der Mensch ein. Desto weniger übt er. Desto schlechter werden seine Fähigkeiten. Und genau dann, wenn die Maschine ausfällt, braucht er diese Fähigkeiten am meisten.
Zweitens: Das Überwachen einer zuverlässigen Maschine ist kognitiv langweilig. Der Mensch verliert das Situationsbewusstsein. Er weiß irgendwann nicht mehr genau, was die Maschine eigentlich tut und warum.
Drittens: Je autonomer die Maschine, desto weniger transparent ihre Entscheidungen. Um sie zu überwachen, bräuchte der Operator tiefes Prozesswissen. Aber er hat es nicht mehr, weil die Maschine es für ihn abgewickelt hat.
Bainbridge nennt das die Ironie. Die Automatisierung, die den Menschen entlasten soll, macht ihn zu einem schlechten Backup-System.
Die Forschung seitdem hat dieses Bild verfeinert. Adaptive Automatisierung, Human-Automation-Teaming, geteilte Kognition. Die Kernthese ist geblieben. Was sich verändert hat, ist das Verständnis davon, wie man damit umgeht. Dazu komme ich noch.
Was beim Entwickler verkümmert
Die Piloten von Air France 447 hatten zusammen Tausende Flugstunden. Aber kaum manuelle Erfahrung bei 35.000 Fuß, nachts, ohne verlässliche Geschwindigkeitsdaten. Dafür war der Autopilot zuständig. Bis er es nicht mehr war.
Ich sage bewusst nicht, dass Softwareentwicklung dasselbe ist wie das Fliegen eines Verkehrsflugzeugs. Entwickler haben Git. Sie haben Code Reviews, Staging-Umgebungen, Deploymentgates. Ein schlechter Commit tötet niemanden in drei Minuten. Die Konsequenzen sind anders, die Reversibilität ist größer.
Aber der psychologische Mechanismus ist identisch. Was bei einem Piloten die Fähigkeit zur manuellen Steuerung unter Stress ist, das ist bei einem Entwickler etwas anderes. Es ist das Gefühl dafür, wo in einem System ein Fehler entstehen kann. Die Fähigkeit, Code zu lesen und zu verstehen, auch wenn man ihn nicht selbst geschrieben hat. Das Debuggen-Können, wenn kein Werkzeug mehr hilft. Das mentale Modell eines Systems, das man nicht nur bedient, sondern begreift.
Das sind die Fähigkeiten, die verkümmern, wenn ein Agent alles schreibt, während man zuschaut.
Die Luftfahrtpsychologie hat dafür einen Begriff: out of the loop.
Im nächsten Teil dieser Serie geht es darum, was das psychologisch bedeutet. Warum Überwachen so schwer ist, warum Fähigkeiten verfallen, und warum es nicht reicht, Menschen einfach aufmerksamer sein zu lassen.
Quellen
- Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics, 30(3), 286–297.
- Sheridan, T. B., & Verplank, W. L. (1978). Human and computer control of undersea teleoperators. MIT Man-Machine Systems Laboratory.
- Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779.
- Bureau d’Enquêtes et d’Analyses (BEA). (2012). Final report on the accident on 1st June 2009 to the Airbus A330-203 registered F-GZCP operated by Air France, flight AF 447, Rio de Janeiro–Paris.