Was ich kritisch sehe

Diesen Beitrag anhören (10 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 Tools, 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. Ich trenne dabei vier Beobachtungen von einer offenen Hypothese.

Wer nur noch prüft, verlernt das Bauen

Wenn ich Code nur selten selbst schreibe, muss ich inzwischen genauer unterscheiden: Fehlt mir nur eine API-Signatur, oder fehlt mir Übung in der Routine? Wer eine selten genutzte Bibliotheksfunktion braucht, schlägt ihre Signatur nach – das war immer so und ist kein Problem. Das Problem wäre die Richtung der Bewegung: Wenn nicht mehr nur die Ausnahme nachgeschlagen wird, sondern die Routine ganz entfällt, fehlt die Wiederholung, aus der Geläufigkeit entsteht. Ob und wie schnell das bei mir passiert, kann ich nicht messen. Deshalb erledige ich bestimmte Routineaufgaben bewusst ohne KI und achte darauf, wo mir Übung fehlt.

Die CHI-2025-Studie von Microsoft Research und Carnegie Mellon befragte dazu 319 Wissensarbeiter. Höheres Vertrauen in generative KI hing in den Selbstauskünften mit weniger eingesetztem kritischem Denken zusammen. Das ist ein Zusammenhang in einer Befragung, kein Nachweis dafür, dass Fähigkeiten bereits abgebaut wurden. Meine Sorge geht einen Schritt weiter als das Ergebnis der Studie: Wer Routinearbeit abgibt und nur noch die Ausnahmen behandelt, könnte genau die Übung verlieren, die er für die Ausnahmen braucht.

Für mich ist das ein schleichendes Risiko, das ich aktiv managen kann. Mehr treibt mich um, wie die Rechnung für Berufsanfänger aussieht. Ich habe mein Handwerk gelernt, indem ich oft genug auf die Nase gefallen bin: Speicherlecks selbst gejagt, Race Conditions selbst gebaut und selbst verstanden. Wer in der Lernphase überwiegend generierten Code prüft, bekommt möglicherweise weniger Gelegenheit, diese Substanz aufzubauen – das ist eine Vermutung, keine Messung, und die zitierte Befragung sagt dazu nichts. Konkret würde dann die Erfahrung fehlen, die gutes Prüfen erst möglich macht: einschätzen zu können, ob ein Timeout, eine Sperre oder eine Fehlerbehandlung zum eigenen System passt, weil man solche Entscheidungen selbst getroffen und ihre Folgen getragen hat.

Plausibel ist nicht richtig

Die Szene vom Anfang hat einen Namen: Automation Bias. Eine systematische Übersicht von Goddard, Roudsari und Wyatt beschreibt ihn als Neigung, automatisierten Empfehlungen zu folgen und widersprechende Hinweise zu übersehen – die Forschung dazu ist älter als die aktuellen Sprachmodelle. Bei meiner Migration verstärkten die saubere Formatierung, die Kommentare und der mitgelieferte Rollback-Pfad genau diesen Vertrauenseindruck: Ich hätte beinahe freigegeben, was ich nicht geprüft hatte.

Ob Review und Vier-Augen-Prinzip gegen solche plausiblen Ausgaben systematisch schlechter greifen als gegen erkennbar schlampigen Code, kann ich nicht belegen.

Passend dazu haben Perry und Kollegen in einer kontrollierten Studie gezeigt, dass Teilnehmende mit KI-Assistent häufiger unsicheren Code schrieben und zugleich überzeugter waren, sicheren geschrieben zu haben. Die Studie untersucht keine Code-Reviews. Für meine Review-Praxis ist die Kombination deshalb ein Warnsignal, kein Wirksamkeitsbeleg.

„Das hat die KI so gemacht“ ist keine Antwort

Im Review reicht mir „Das hat mir die KI so vorgeschlagen“ nicht als Begründung. Der Satz erklärt die Herkunft, aber nicht die Entscheidung. Warum ist der Timeout hier auf dreißig Sekunden gesetzt? Warum ist das für unser System richtig? Wenn darauf keine Antwort folgt, ist die Entscheidung im Review nicht begründet – denn die Session, die den Wert gewählt hat, ist längst beendet und hat 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 können aus bewussten Abkürzungen entstehen: Wir bauen jetzt die schnelle Lösung und räumen später auf. Man kannte die bewusst eingegangenen Abkürzungen und ihre Folgen. Daneben sehe ich eine mögliche zweite Variante: 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.

Wenn ein Team einen generierten Mechanismus beim Einbau nur im Groben nachvollzieht, kann es bei der nächsten Änderung nötig sein, Annahmen und Entscheidungsgründe zu rekonstruieren, bevor der Mechanismus sicher geändert werden kann. Dann kann technische Schuld entstanden sein, ohne dass sie jemand bewusst aufgenommen hätte – kein Vermerk, keine Entscheidung, kein „später räumen wir auf“. Solche Schulden können unbemerkt entstehen, weil keine bewusste Abkürzung dokumentiert wurde. 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 Modell fragen, können Entwürfe ähnlicher werden

Die letzte Sorge ist eine offene Hypothese. Ein Gedankenexperiment macht sie greifbar: Vier Gruppen bekommen dieselbe offen gehaltene Entwurfsaufgabe, und alle vier stellen ihre erste Frage demselben Modell. Wie unterschiedlich fallen die Ergebnisse aus? Wenn alle mit einer sehr ähnlichen Erstantwort starten, kann diese Antwort den weiteren Entwurf prägen. Der Effekt ist nicht gemessen und hängt unter anderem von Prompt, Kontext, Sampling und Modell ab. Die erwähnte Microsoft-Studie untersucht ihn nicht.

Man kann mit den Achseln zucken und sagen: Konvergenz auf bewährte Muster ist doch gut. Teilweise stimmt das – ich bin der Letzte, der eine ausgefallene Lösung schon deshalb gut findet, weil sie ausgefallen ist. Aber Architektur-Vielfalt ist kein Selbstzweck, sondern ein Suchverfahren. Unterschiedliche Entwürfe machen alternative Annahmen und Zielkonflikte sichtbar. Meine Sorge lautet deshalb: Wenn viele Entwurfsentscheidungen durch denselben Filter laufen, verengt sich der Raum der ernsthaft geprüften Alternativen. Messen kann ich das nicht.

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 dieser 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, prüfe ich, ob mir Übung fehlt oder nur eine selten genutzte API nicht präsent ist.
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. Kritische Stellen sind zum Beispiel möglicher Datenverlust, Rechteprüfungen, Nebenläufigkeit und öffentliche APIs. „Im Groben nachvollzogen“ zählt nicht.
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. Die zusätzliche Prüfung kostet mich Zeit, macht die Freigabe aber nachvollziehbarer. Und ich merke: Sie kostet Kraft. Im Alltag ist es einfacher, sie auszulassen.

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 reicht, und an schlechten Tagen reicht sie erstaunlich wenig weit. 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.

Weiterführende Quellen

Wie fandest du diesen Beitrag?