Die 'Ich weiß nicht, Claude hat das geschrieben' Pandemie

Ein Kollege bittet dich, einen Pull Request zu überprüfen. Es ist ein großer PR: dutzende Dateien, über 1.000 neue Zeilen Code.

Du nimmst dir die Zeit und tauchst in den Code ein. Du hinterlässt ein paar Kommentare, aber nach 15 Minuten stellst du fest, dass zu viele Dinge keinen Sinn ergeben. Du kontaktierst den Entwickler für einen kurzen Call.

Du stellst eine Frage – keine kleine Syntax-Frage, sondern eine fundamentale Frage zur Software-Architektur – und erhältst eine Antwort, bei der du schreien möchtest:

„Ich weiß es nicht, Claude hat das geschrieben.“

Nein. DU hast das geschrieben. DU hast den PR geöffnet. DU bist dafür verantwortlich. Claude ist nur ein Werkzeug, nicht der Entscheidungsträger.

Diese Situation entwickelt sich zunehmend zu einem flächendeckenden Problem in Entwicklerteams.

Kognitive Kapitulation statt Auslagerung

Addy Osmani, Director of Engineering bei Google, bezeichnete dieses Phänomen kürzlich als “kognitive Kapitulation” (cognitive surrender).

Kognitive Auslagerung (cognitive offloading) bedeutet, eine Aufgabe an die KI zu delegieren, aber weiterhin die Verantwortung für die Antwort zu tragen. Kognitive Kapitulation tritt ein, wenn der Output der KI stillschweigend zu deinem Output wird und du das Gefühl hast, nichts mehr überprüfen zu müssen. Für Softwareentwickler verschiebt sich die Grenze zwischen diesen beiden Extremen fast täglich – und die meisten überschreiten sie, ohne es zu merken.

Wie wir an diesen Punkt kommen

Du hast eine große Aufgabe vor dir. Du startest eine Planungs-Session mit Claude. Die KI analysiert die Codebasis, stellt Verständnisfragen und liefert einen Plan. Du überfliegst den Plan, korrigierst ein paar Kleinigkeiten und schickst ihn in die Ausführung.

Du prüfst den Code, er sieht auf den ersten Blick gut aus. Kleinere Fehler behebst du mit ein paar Folge-Prompts und öffnest den PR.

Die nächste Aufgabe ist größer und uneindeutiger. In einer Welt vor der KI hättest du die Aufgabe in kleinere Teilbereiche zerlegt. Aber du stehst unter Zeitdruck. Claude liefert einen plausibel klingenden Plan und du gehst direkt zur Ausführung über. Das Ergebnis funktioniert. Du überfliegst den Code, erstellst den PR und wendest dich dem nächsten Ticket zu.

Du hast den Teil übersprungen, in dem du tatsächlich verstanden hast, was dort passiert.

Im besten Fall stellt dir der Reviewer Fragen, die du nicht vollständig beantworten kannst. Hoffentlich leitest du diese Kommentare nicht einfach blind an Claude weiter, sondern versuchst, den Sachverhalt selbst zu verstehen.

Im schlimmsten Fall ist es ein massiver PR, alle stehen unter Zeitdruck, er wird durchgewinkt und gemerged. Niemand hat den Code verstanden – weder der Autor noch der Reviewer. Die KI ihren eigenen Code überprüfen zu lassen, ist, als würde ein Schüler seine eigene Prüfung korrigieren: Er besteht immer.

Anstatt selbst zu lenken, lässt du Claude dein Auto von der Klippe fahren.

Warum es schwer ist, zu widerstehen

Es passiert schnell: Du bist in einer langen Planungs-Session mit Claude. Die Aufgabe ist komplex, aber die Lösung scheint nur ein paar Prompts entfernt zu sein. Mittendrin merkst du, dass du den Überblick verloren hast. Zu viele bewegliche Teile, zu viele architektonische Entscheidungen, die Claude selbstständig getroffen hat. Am Ende musst du den gesamten Kontext zurücksetzen.

Das Problem entsteht meist aus einer Kombination von zwei Faktoren:

1. Du startest mit einer vagen Idee der Zielsetzung.
2. Dir fehlt das notwendige Domänen- oder Systemwissen im betreffenden Bereich.

Wenn der Plan unpräzise ist und dir das Wissen fehlt, um Entscheidungen selbst zu treffen, delegierst du diese Entscheidungen unweigerlich an die KI. Die Grenze zwischen Werkzeugnutzung und Kontrollverlust ist fließend. Es erfordert bewusste Anstrengung, nicht in die Automatisierungsfalle zu tappen.

Die Alternative: Verantwortung behalten

Bei einer Aufgabe zur Integration von Event-Tracking (z.B. Segment) in einer unbekannten Codebasis sieht der korrekte Workflow so aus:

Du planst mit Claude, lässt dir Vorschläge machen und klärst Fragen. Wenn der Plan sinnvoll ist, startest du die Ausführung.

Bevor du die Dateien committest, überprüfst du jede einzelne Änderung in der IDE. Wenn du eine Zeile nicht verstehst, lässt du sie dir von Claude erklären. Wenn die Erklärung keinen Sinn ergibt, änderst du den Code und überprüfst ihn erneut.

Erst wenn du jede Dateiänderung im Detail nachvollziehen kannst, hast du die Gesamtlösung verstanden.

Wenn der PR nun Kommentare von Senior-Entwicklern erhält, kannst du diese verstehen, in einem Call fundiert diskutieren und musst dich nicht hinter der KI verstecken.

Welche Fähigkeiten wir verlieren dürfen – und welche nicht

In der Geschichte der Zivilisationen gehen Fähigkeiten regelmäßig verloren. Die alten Ägypter vergaßen, wie man Pyramiden baut. Die Römer vergaßen, wie man Aquädukte konstruiert. Die Amerikaner verloren nach dem Ende des Space-Shuttle-Programms zeitweise die Fähigkeit, Menschen in den Weltraum zu bringen. Die Entropie ist nicht auf unserer Seite.

Auch wir geben durch Technologie ständig Fähigkeiten auf. Niemand navigiert mehr ohne Google Maps. In der Softwareentwicklung müssen wir bewusst entscheiden, welche Fähigkeiten wir bereit sind abzugeben.

Fähigkeiten, die delegiert werden können:

• Das rein manuelle Tippen von Code
• Das Auswendiglernen von Sprach-Syntax
• CSS-Boilerplate

Fähigkeiten, die wir unter keinen Umständen verlieren dürfen:

• Das Verständnis für den Aufbau von Softwaresystemen
• Die Analyse von Trade-offs und architektonischen Entscheidungen
• Die Fähigkeit, Code zu lesen und seine Logik zu validieren
• Das Lesen und Verstehen von Architektur- und Design-Dokumenten

Das Ziel ist, Claude in die gewünschte Richtung zu steuern, anstatt sich von der KI steuern zu lassen. Das ist die unabdingbare Erwartungshaltung an jeden professionellen Softwareentwickler.

(Dieser Artikel basiert auf den Überlegungen von Anton Zaides aus seinem Newsletter)