Was ich kritisch sehe

Diesen Beitrag anhören (12 Min.)

An einem Donnerstagabend im Januar habe ich einen Pull Request beinahe durchgewunken, den ich selbst in Auftrag gegeben hatte. Claude Code hatte eine Datenbank-Migration geschrieben, sauber formatiert, mit Kommentaren, mit Rollback-Pfad. Ich habe sie gelesen, genickt, den Mauszeiger schon über dem Merge-Button gehabt – und dann, eher aus Gewohnheit als aus Misstrauen, doch noch die betroffene Tabelle im Staging-System angeschaut. Die Migration hätte funktioniert. Sie hätte nur nebenbei eine Spalte umbenannt, auf die ein Report zugreift, von dem die Session nichts wissen konnte. Kein Drama, schnell gefunden. Aber der Moment davor beschäftigt mich bis heute: Ich hatte nicht geprüft. Ich hatte gelesen, wie man einen gut geschriebenen Text liest – wohlwollend, mit dem Strom.

Teil 4 der Serie „Von der Session zum System“ – hier geht es zum Auftakt.

In der letzten Folge habe ich beschrieben, warum das Delegieren an KI für mich erst mit einem guten Harness funktioniert – mit Werkzeugen, Rückkopplung und Leitplanken um das Modell herum. Am Ende stand ein Unbehagen, das mit jeder delegierten Aufgabe lauter geworden ist. Dieses Unbehagen will ich heute ernst nehmen. Nicht als Alarmruf – ich arbeite weiter jeden Tag mit diesen Werkzeugen, gern und produktiv. Sondern als das, was Kritik eigentlich sein sollte: genau hinschauen, bevor man weitermacht. Fünf Punkte haben sich bei mir angesammelt.

Wer nur noch prüft, verlernt das Bauen

Vor ein paar Wochen war mein bevorzugtes KI-Werkzeug für einen halben Tag nicht erreichbar. Kein Weltuntergang – ich habe die anstehende Aufgabe, einen etwas verzwickten Datenabgleich, eben selbst geschrieben. Und dabei etwas gemerkt, das ich ungern zugebe: Ich war langsamer, als ich es vor meinem Einstieg gewesen wäre – nach erst wenigen Monaten intensiver Delegation. Nicht beim Denken, das Konzept stand schnell. Beim Handwerk. Welche Signatur hatte diese Bibliotheksfunktion noch mal genau? Wie war die Syntax für diesen etwas selteneren Fall? Dinge, die früher in den Fingern saßen, musste ich nachschlagen. Das Nachschlagen selbst ist nicht das Problem – das habe ich immer getan. Das Problem ist die Richtung der Bewegung: Fähigkeiten, die man nicht benutzt, bauen ab. Muskeln, Sprachen, Code – überall dasselbe Prinzip.

Eine Studie von Microsoft Research und Carnegie Mellon hat Anfang 2025 genau das bei Wissensarbeitern untersucht: Je mehr Vertrauen in die KI, desto weniger eigenes kritisches Denken – und die Autoren benennen die Ironie der Automatisierung sehr präzise. Wer die Routinearbeit abgibt und nur noch die Ausnahmen behandelt, verliert genau die Übung, die er für die Ausnahmen bräuchte.

Für mich als Senior ist das ein schleichendes Risiko, das ich aktiv managen kann – mein Fundament aus drei Jahrzehnten trägt noch eine Weile. Für Juniors sieht die Rechnung anders aus, und das treibt mich mehr um als mein eigenes Rosten. Ich habe mein Handwerk gelernt, indem ich tausend Mal auf die Nase gefallen bin: Speicherlecks selbst gejagt, Race Conditions selbst gebaut und selbst verstanden. Wer heute anfängt, bekommt funktionierenden Code, bevor der Schmerz einsetzt, aus dem Verständnis entsteht. Das ist nicht die Schuld der jungen Leute – es ist die Umgebung, die wir ihnen hinstellen. Ein Senior, der nur noch prüft, zehrt von Substanz. Ein Junior, der nur noch prüft, hat nie welche aufgebaut. Und wer das Handwerk nicht beherrscht, prüft bald gar nichts mehr – er nickt nur noch.

Plausibel ist nicht richtig

Die Szene vom Anfang ist kein Einzelfall, und sie hat einen Namen: Automation Bias – die gut belegte Neigung, Vorschlägen eines automatischen Systems mehr zu glauben, als sie verdienen. Die Forschung dazu ist älter als die aktuellen Sprachmodelle; eine systematische Übersicht von Goddard und Kollegen zeigte schon 2012, dass Menschen fehlerhaften automatischen Empfehlungen deutlich häufiger folgen, als sie denselben Fehler allein machen würden. Sprachmodelle verschärfen das, weil ihre Ausgabe nicht nur automatisch ist, sondern auch rhetorisch überzeugend. Ein Vorschlag mit sauberer Einrückung, treffenden Variablennamen und einem selbstbewussten Begleitsatz sieht aus wie das Werk eines sorgfältigen Kollegen. Er aktiviert dieselben Vertrauensreflexe.

In einem größeren Konzernumfeld habe ich erlebt, wie ein Team einen generierten Berechtigungs-Check übernommen hat, der in neun von zehn Fällen korrekt war. Der zehnte Fall – ein Sonderpfad für einen bestimmten Rollentyp – war schlicht erfunden, klang aber exakt so, wie so ein Sonderpfad klingen würde. Zwei Reviews haben ihn passieren lassen. Aufgefallen ist er erst, als ein echter Nutzer in genau diese Lücke lief. Das Beunruhigende daran ist nicht der Fehler. Fehler haben wir immer gebaut. Beunruhigend ist, dass die üblichen Abwehrmechanismen – Review, Vier-Augen-Prinzip – gegen plausible Ausgaben schlechter greifen als gegen menschliche Schlampigkeit. Menschlicher schlechter Code sieht meistens schlecht aus. Generierter schlechter Code sieht gut aus.

Passend dazu haben Perry und Kollegen in einer Stanford-Studie gezeigt, dass Entwickler mit KI-Assistent nicht nur unsicheren Code schrieben, sondern gleichzeitig überzeugter waren, sicheren geschrieben zu haben. Die Kombination aus sinkender Qualität und steigender Zuversicht ist das eigentliche Gift.

„Das hat die KI so gemacht“ ist keine Antwort

Ein Satz, den ich in Reviews inzwischen öfter höre, als mir lieb ist: „Das hat mir die KI so vorgeschlagen.“ Gemeint ist er meist harmlos, als Erklärung der Herkunft. Aber er rutscht schnell in etwas anderes – in eine Abgabe von Verantwortung an eine Instanz, die keine tragen kann. Ich habe in einem Gespräch mit einem Kollegen einmal nachgehakt: „Warum ist der Timeout hier auf dreißig Sekunden gesetzt?“ Antwort: „Das war der Vorschlag.“ Zweite Nachfrage: „Und warum ist das für unseren Fall richtig?“ Schweigen. Er wusste es nicht – und in diesem Moment wusste es niemand im Raum, denn die Session, die den Wert gewählt hatte, war längst beendet und hatte ihre Gründe, falls es welche gab, mitgenommen.

In einem Review gibt es keine dritte Partei. Es gibt den Menschen, der den Code einbringt, und den Menschen, der ihn freigibt – beide mit Namen, beide ansprechbar, beide morgen noch da. Was das Werkzeug vorgeschlagen hat, ist so relevant wie die Frage, in welchem Editor der Code getippt wurde. Wer einen Pull Request stellt, sagt damit: Ich stehe dafür ein. Wenn diese Zusage sich auflöst, weil „die KI“ als diffuser Mitautor im Raum steht, verliert das Review seinen Kern. Dann prüfen zwei Menschen etwas, für das sich keiner zuständig fühlt.

Schulden, die keiner aufgenommen hat

Technische Schulden waren bisher meistens eine bewusste Entscheidung: Wir bauen jetzt die schnelle Lösung und räumen später auf. Man wusste, wo die Leichen liegen, weil man sie selbst vergraben hatte. Die neue Variante ist heimtückischer: Code, der funktioniert, alle Tests besteht – und den niemand im Team wirklich versteht. Nicht, weil er unverständlich wäre, sondern weil ihn nie jemand verstehen musste. Er wurde generiert, er lief, er wurde gemerged.

Ich habe das in einem eigenen Nebenprojekt erlebt, ganz ohne Konzern und ohne Termindruck. Ein generierter Synchronisierungs-Mechanismus, den ich beim Einbau „im Groben nachvollzogen“ hatte – so nannte ich das damals vor mir selbst. Drei Monate später brauchte ich eine kleine Änderung und stand vor dem Ding wie vor fremdem Legacy-Code. Ich habe länger gebraucht, das Vorhandene zu verstehen, als ich damals gespart hatte, und am Ende habe ich es neu geschrieben. Die Schuld war da, nur hatte sie nie jemand bewusst aufgenommen – kein Vermerk, keine Entscheidung, kein „später räumen wir auf“. Bequemlichkeits-Schulden entstehen lautlos, und genau das unterscheidet sie von den alten. Ein System, das zu größeren Teilen aus solchem Code besteht, ist nicht kaputt. Es ist etwas Schlimmeres: unverstanden bei voller Funktion.

Wenn alle dasselbe fragen, bauen alle dasselbe

Der fünfte Punkt ist mir zuerst in einem Team aufgefallen, das eine Entwurfsaufgabe bewusst als Wettbewerb angelegt hatte: vier Zweiergruppen, dieselbe Aufgabenstellung, ein offen gehaltenes Architektur-Problem. Solche Übungen kenne ich aus früheren Architektur-Runden zur Genüge: Da kamen vier verschiedene Lösungen heraus – manchmal eine abwegige darunter, aber gerade die abwegigen haben die besten Diskussionen ausgelöst. Diesmal: viermal fast dieselbe Struktur, dieselben Bibliotheken, teilweise dieselben Namen für die Module. Alle vier Gruppen hatten dasselbe Modell gefragt, und das Modell hatte viermal die statistisch naheliegendste Antwort gegeben. Die erwähnte Microsoft-Studie beobachtet denselben Effekt: Mit KI-Unterstützung wird die Menge der produzierten Lösungen messbar gleichförmiger.

Man kann achselzucken und sagen: Konvergenz auf bewährte Muster ist doch gut. Teilweise stimmt das – ich bin der Letzte, der für Exotik um der Exotik willen wirbt. Aber Architektur-Vielfalt ist kein Selbstzweck, sondern ein Suchverfahren. Ungewöhnliche Lösungen sind der Mutationsmechanismus, aus dem die bewährten Muster von übermorgen entstehen. Ein Modell schlägt vor, was in seinen Trainingsdaten häufig war – also das, was gestern Konsens war. Wenn eine ganze Branche ihre Entwurfsentscheidungen durch denselben Filter schickt, optimieren wir kollektiv auf den Durchschnitt der Vergangenheit. Das merkt man nicht in einem Projekt. Man merkt es in zehn Jahren, wenn man sich fragt, warum eigentlich alles gleich aussieht.

Kritik heißt nicht Ablehnung

An dieser Stelle könnte der Text kippen – in Kulturpessimismus, in „früher haben wir noch richtig programmiert“. Das wäre bequem und falsch. Keiner der fünf Punkte ist ein Argument gegen die Werkzeuge. Jeder einzelne ist ein Argument gegen einen bestimmten Umgang mit ihnen: den passiven. Kompetenz verfällt nicht, weil KI existiert, sondern weil ich aufhöre zu üben. Automation Bias schlägt zu, weil ich Plausibilität mit Korrektheit verwechsle. Verantwortung diffundiert, weil ich sie diffundieren lasse. Das ist der Haken an der Sache: Die Antwort liegt nicht im nächsten Modell-Release. Sie liegt bei mir.

Ich habe für mich ein paar Regeln aufgestellt. Keine Weisheiten, eher Hausregeln:

Regelmäßig bewusst ohne KI arbeiten. Kein Verzichtsritual, eher ein Lauf ohne Uhr: bestimmte Aufgaben – ein Algorithmus, ein Datenmodell, ein kniffliger Bugfix – von Hand, um zu spüren, wo es hakt. Wo es hakt, ist die Atrophie.
Verstehens-Pflicht vor dem Merge. Nichts geht in den Hauptzweig, was ich nicht einem Kollegen an der Tafel erklären könnte – Zeile für Zeile bei kritischen Stellen. „Im Groben nachvollzogen“ zählt seit dem Nebenprojekt nicht mehr.
Erst das eigene Urteil, dann das Modell. Bei Entwurfsfragen schreibe ich meine Position in drei Sätzen auf, bevor ich frage. Sie muss nicht die bessere sein; sie ist ein Anker gegen die plausible Erstantwort – Abweichungen werden dann zu echter Information.
Herkunft benennen, Verantwortung behalten. Wenn Code generiert wurde, sage ich das im Review offen – und übernehme ihn trotzdem so, als hätte ich ihn getippt.

Nichts davon ist originell. Es ist dieselbe Disziplin, die gute Ingenieure schon immer von schnellen Ergebnissen getrennt hat, nur an neuer Stelle angewandt. Und ich merke: Sie kostet Kraft. Der Sog der bequemen Variante lässt keinen Tag aus.

Genau da endet allerdings die Reichweite dieses Textes. Alles, was ich hier beschrieben habe, sind Maßnahmen eines Einzelnen – meine Regeln, meine Disziplin, meine Hausregeln. Das trägt genau so weit, wie meine Selbstkontrolle trägt, und sie trägt an schlechten Tagen erstaunlich kurz. Ein Team kann sich nicht auf die private Disziplin seiner Mitglieder verlassen; zehn Leute mit zehn verschiedenen Hausregeln ergeben noch keine gemeinsame Arbeitsweise. Was mit diesen Beobachtungen passiert, wenn nicht einer so arbeitet, sondern ein ganzes Team – mit unterschiedlicher Erfahrung, unterschiedlicher Sorgfalt und Termindruck obendrauf – das ist die Frage, die ich mir für die nächste Folge vorgenommen habe.