Image Description

Eine Stanford-Studie von 2022 hat Entwickler in zwei Gruppen aufgeteilt. Die eine Gruppe nutzte KI-Assistenten beim Programmieren. Die andere nicht. Dann wurde verglichen, wie sicher der produzierte Code war.

Die Gruppe mit KI schrieb unsichereren Code und war gleichzeitig sicherer, dass ihr Code sicher war.

Kein Paradox. Automation Bias in Reinform: Wer einem scheinbar kompetenten System vertraut, überprüft weniger. Wer weniger überprüft, findet nicht, was das System falsch gemacht hat.

Im zweiten Teil dieser Serie ging es darum, warum Überwachen strukturell versagt: Vigilanz-Dekrement, Out-of-the-Loop, kognitive Erosion. Dieser dritte Teil geht ins Konkrete. Was sagen die Softwareentwicklungs-Daten, und was lässt sich daraus ableiten?

Die Daten

Mehrere Studien zeigen dasselbe Muster, von verschiedenen Seiten.

Zwischen 2021 und 2024 stieg Code-Duplikation um 48 Prozent. Refactoring fiel von 25 auf unter 10 Prozent der geänderten Zeilen. Fast 8 Prozent neu hinzugefügter Code wurde innerhalb von zwei Wochen wieder revidiert, 2020 waren es noch 5,5 Prozent. Diese Zahlen stammen aus einer Analyse von 211 Millionen Codezeilen über fünf Jahre, die GitClear veröffentlicht hat.

Auf Sicherheitsebene sieht es ähnlich aus. In einem Vergleich von 470 Open-Source-Pull-Requests enthielten KI-generierte PRs im Schnitt 10,83 Issues, menschlicher Code 6,45. XSS-Sicherheitslücken waren 2,74 mal häufiger. Unabhängig davon hat Veracode über 100 KI-Modelle getestet und festgestellt, dass 45 Prozent der generierten Code-Samples OWASP-Top-10-Schwachstellen enthielten.

Besonders aufschlussreich ist eine Harvard Business School Studie über Unternehmensberater. Für Aufgaben innerhalb der KI-Kompetenz waren die KI-Nutzer 40 Prozent produktiver. Bei Aufgaben außerhalb dieser Kompetenz schnitten sie 19 Prozent schlechter ab als die Gruppe ohne KI. Der Grund: Sie folgten der Maschine, auch wenn sie falsch lag.

Vibe Coding

Anfang 2025 hat Andrej Karpathy einen Begriff geprägt: Vibe Coding. Die Idee ist, einen groben Intent in natürlicher Sprache zu beschreiben und den KI-Agenten den Rest machen zu lassen. Der Entwickler überwacht, korrigiert, iteriert per Prompt.

Seither hat sich der Begriff schnell verbreitet. Zum Wort des Jahres 2025 hat Collins Dictionary ihn gewählt. Bei Y Combinator haben 25 Prozent der Winter-2025-Startups Codebasen, die zu 95 Prozent von KI generiert wurden.

Produktiv ist das, innerhalb seiner Grenzen — das zeigen die Daten. Was die Zahlen nicht abbilden, ist der psychologische Modus, in dem Vibe Coding stattfindet. Csikszentmihalyi hat Flow-Zustände durch drei Merkmale beschrieben: klare Ziele, ausgewogene Herausforderung, unmittelbares Feedback. Genau diese Bedingungen entstehen beim Vibe Coding. Kritische Überwachung braucht das Gegenteil: aktiven Zweifel, Verlangsamung, Perspektivwechsel. Beides gleichzeitig geht nicht.

96 Prozent der Entwickler sagen laut einer Umfrage, dass sie KI-generierten Code nicht vollständig vertrauen. Trotzdem reviewen 48 Prozent ihn nicht konsistent vor dem Commit.

Das strukturelle Problem

Ein zweites Risiko wirkt auf einer anderen Ebene, jenseits des einzelnen Entwicklers.

Kognitive Fähigkeiten verfallen schneller als motorische — das hat Casner 2014 in Pilotenstudien gezeigt. Was verloren geht, wenn man nicht mehr manuell fliegt, ist nicht die Motorik, sondern das mentale Modell. Ähnliches deutet sich in der Softwareentwicklung an: Laut Stack Overflow Blog ist die Beschäftigung von Entwicklern zwischen 22 und 25 Jahren seit Ende 2022 um fast 20 Prozent gesunken.

Verschwunden sind damit genau die Positionen, in denen Entwickler früher die Grundlagen gelernt haben. Nicht durch Kurse, sondern durch das Tun selbst: Tickets bearbeiten, Bugs finden, Codebasen lesen, die andere gebaut haben.

Wer diesen Weg nicht mehr gegangen ist, kann KI-Code strukturell nicht gut evaluieren. Nicht weil er es nicht will, sondern weil ihm das Referenzwissen fehlt, das nötig wäre, um Abweichungen als problematisch zu erkennen. Bainbridge beschrieb das 1983 für eine kommende Generation von Flugzeugpiloten: “Riding on skills which later generations of operators cannot be expected to have.”

Damit sind es zwei verschiedene Risiken. Automation Bias trifft alle, die schon Erfahrung haben. Skill Erosion trifft alle, die sie gerade nicht mehr bekommen.

Image Description

Was die Luftfahrt getan hat

Die Luftfahrt hatte diese Diskussion bereits und hat Antworten gefunden. Nicht perfekte, aber brauchbare.

Nach dem Absturz von Air France 447 hat die BEA 25 Empfehlungen herausgegeben. Die FAA hat 2013 und 2017 offizielle Safety Advisories veröffentlicht, die Fluggesellschaften auffordern, manuelle Flugstunden wieder einzuplanen. Der Absturz von Eastern Airlines 401, 1972, hat direkt zur Entwicklung von Crew Resource Management geführt: strukturiertes Training für Kommunikation, Entscheidungsfindung und Aufgabenverteilung unter Stress.

Das Grundprinzip dahinter ist simpel. Überwachung allein hält Fähigkeiten nicht aufrecht. Menschen müssen aktiv eingebunden bleiben, nicht als passive Monitore.

Konkrete Konsequenzen

Übertragen lassen sich die Luftfahrtprinzipien, aber nur wenn man beim richtigen Ausgangspunkt beginnt. Die erste Konsequenz betrifft keine Werkzeuge. Sie betrifft den Einstieg in die Arbeit.

Vibe Coding in seinem schlechtesten Modus bedeutet einen bestimmten Ablauf: Intent formulieren, ausführen lassen, Ergebnis hinnehmen. Die Designfragen werden nie gestellt. Man erhält Code ohne mentales Modell. Wer ihn später evaluieren soll, hat keine Grundlage dafür.

Das Gegenmittel ist ein anderer Einstieg. Frederick Brooks hat in “The Design of Design” beschrieben, wie jede Designentscheidung neue Äste öffnet. Alle müssen aufgelöst sein, bevor man anfängt zu bauen. In der Praxis bedeutet das: bevor ein Agent anfängt zu coden, kommen zuerst die Fragen. Nicht eine oder zwei, sondern systematisch alle, bis jede Abhängigkeit zwischen Entscheidungen geklärt ist. Kein Plan, bis alle Branches durch sind. Was dabei entsteht, ist kein Dokument. Es ist ein mentales Modell.

Dazu kommt ein zweites, subtileres Problem. KI-Modelle arbeiten mit den Konzepten, die durch den Prompt definiert werden. Wenn dasselbe Wort zwei verschiedene Konzepte bezeichnet, produziert das Modell Code für das falsche Problem. Das erzeugt keine Fehlermeldung. Es erzeugt falsches Verhalten, das wie richtiges aussieht. Ein kurzer Abgleich vor dem ersten Prompt, welche Begriffe mit welcher Bedeutung gelten, verhindert eine Klasse von Architekturfehlern, die schwer zu debuggen sind.

Was darüber hinaus hilft, sind Designentscheidungen auf Ebene der Werkzeuge und Workflows.

Plan trennen von Ausführung. Ein Agent, der direkt ausführt, lässt keine Entscheidung zu. Wer zuerst einen Entscheidungsplan vorlegt und auf Freigabe wartet, erzwingt Auseinandersetzung. Das ist Sheridans Stufe 4: Maschine empfiehlt, Mensch entscheidet. Klingt trivial. Als explizites Designprinzip ist es fast nirgends implementiert.

Alternativen statt Empfehlungen. Eine einzige Lösung lädt zur Bestätigung ein. Drei Optionen mit expliziten Trade-offs erzwingen kognitive Evaluierung. Der Unterschied ist nicht kosmetisch, er verändert die kognitive Aufgabe des Entwicklers grundlegend.

Reasoning-first. Vor jeder Aktion: “Ich tue X, weil Y, Konsequenz Z.” Nicht als Log, sondern als Interaktionsmuster. Ein System, das Entscheidungen trifft ohne sie erklärbar zu machen, schafft dieselbe Situation wie Boeing MCAS: Die Piloten wussten nicht, dass es existiert.

Forced Manual Intervals. Analog zu Pflicht-Handflugstunden: bestimmte Aufgaben werden bewusst nicht delegiert, auch wenn der Agent es könnte. Nicht als Strafe, sondern um das mentale Modell zu erhalten. Wer drei Monate keine Datenbankabfrage selbst geschrieben hat, verliert die Intuition für das, was dort schief gehen kann.

Active Review statt Passive Approval. Ein Review-Interface, das “Approve/Reject” anbietet, erzeugt Complacency. Wer stattdessen gefragt wird “Was würdest du ändern?”, muss sich auseinandersetzen. Die Frage bestimmt die kognitive Aufgabe.

Red-Team als Standard. Ein zweiter Agent, der den Plan des ersten kritisiert, bevor der Entwickler ihn sieht, liefert einen Ausgangspunkt für echtes Review. Statt eine Empfehlung zu bestätigen, bewertet man einen Konflikt. Das ist strukturell ein anderes Engagement.

Der eigentliche Punkt

Das ist keine Warnung vor KI. Flugzeuge sind seit dem Einzug der Automatisierung deutlich sicherer geworden, die Unfallrate ist gesunken. Aber nicht, weil man die Probleme ignoriert hat, sondern weil man sie ernst genommen hat.

Automation Bias und Skill Erosion sind keine Charakterfehler von Entwicklern. Beides sind vorhersehbare Konsequenzen davon, wie automatisierte Systeme mit menschlicher Kognition interagieren. Sie entstehen durch Design, das diese Effekte nicht berücksichtigt.

KI-Agenten werden in der Softwareentwicklung bleiben. Ob die Konsequenzen beherrschbar bleiben, hängt davon ab, ob die Werkzeuge so gebaut werden, dass Menschen entscheiden, statt bestätigen.

Quellen