Kognitive Schuld: Wenn KI schneller schreibt, als wir verstehen können

Daily Standup. Ein Kollege sagt: «Mein Pull Request ist fertig, bereit für den Review.» Auf die Rückfrage «Wie hast du das Problem gelöst?» fällt die Antwort auffallend zögerlich aus. Das liegt nicht daran, dass dem Entwickler die Kompetenz fehlt, sondern daran, dass ein guter Teil des Codes von einem KI-Agenten erzeugt wurde. Der Entwickler hat nicht im Detail nachvollzogen, wie das Feature tatsächlich umgesetzt und das Problem gelöst wurde.

Für dieses Phänomen gibt es einen Fachbegriff: «Cognitive Debt», auf Deutsch kognitive Schuld. Gemeint ist die wachsende Lücke zwischen dem, wie ein Software-System tatsächlich implementiert ist, und dem, wie gut der Engineer, der es gebaut hat, diese Umsetzung noch versteht. Diese Lücke ist nicht neu. Es gab sie schon vor generativer KI, immer dann, wenn Wissen nicht dokumentiert wurde oder die Verantwortung für den Code nicht klar war. Neu im KI-Zeitalter ist das Tempo: Cognitive Debt entsteht heute schneller und in grösserer Menge.

Der Grund ist banal, aber wirkungsvoll: Code zu schreiben bedeutete für Entwickler historisch automatisch, ihn auch zu verstehen. Man musste jede Zeile selbst tippen, jede Fallunterscheidung selbst durchdenken, jeden Fehler selbst finden. Dieser Zwang zum Verständnis fällt weg, wenn ein Agent den Code produziert. Man bekommt das Ergebnis: schnell, oft syntaktisch einwandfrei und sogar mit passenden Tests. Nur der Denkprozess fehlt, der früher automatisch mitgeliefert wurde.

Das eingangs beschriebene Szenario ist kein Einzelfall. Es ist der Normalfall, wenn Code übernommen wird, ohne ihn zu hinterfragen. Und es trifft längst nicht nur Berufseinsteiger. Auch erfahrene Entwickler tappen in dieselbe Falle, nur eine Stufe später: Sie verstehen die Architektur noch, aber nicht mehr jede einzelne Entscheidung, die die KI in den letzten Wochen getroffen hat.

Eine wirksame Methode ist Spec-driven Development. Dabei wird die Spezifikation vor der Implementierung im Dialog mit der KI erarbeitet: Der Engineer gibt Rahmenbedingungen vor und klärt Unklarheiten, die KI stellt Rückfragen, und der Engineer hinterfragt die vorgeschlagene Lösung, bevor Code generiert wird. Das hilft, die wesentlichen Vorgaben und Entscheidungen zu verstehen. Manche Teams bei uns teilen die generierte Spezifikation im Team; die Kollegen prüfen sie oder diskutieren gemeinsam den Umsetzungsplan. Ein Allheilmittel ist das jedoch nicht: Man kann eine Spezifikation sorgfältig schreiben und verstehen und trotzdem am Ende die Implementierung nicht mehr im Detail durchdringen.

Entscheidend ist deshalb weniger das Werkzeug als der Dialog mit der KI selbst, und zwar während der gesamten Lösungsentwicklung, nicht nur am Anfang. Spec-driven Development ist ein Mittel der Wahl, um Anforderungen und Randfälle vorab zu klären und den Umsetzungsplan abzustimmen. Genauso wichtig ist es, während der Implementierung gezielt nachzufragen: Warum dieser Ansatz und kein anderer? Welche Alternativen wurden verworfen und warum? Was passiert bei diesem Grenzfall?

Hier kommt die Erfahrung im Team ins Spiel. Ein Senior Engineer erkennt, dass eine von der KI vorgeschlagene Lösung zwar funktional korrekt sein kann, aber häufig noch Verbesserungspotenzial hat: bei der Architektur, der Effizienz, den Best Practices oder der Einhaltung projektspezifischer Konventionen. Dann hinterfragt er sie gezielt. Das setzt voraus, dass er die Implementierung im Projekt-Kontext wirklich verstanden hat, zumindest in den wesentlichen Entscheidungen. Verzichtet man auf dieses Verständnis, beginnt eine Spirale: Irgendwann versteht auch der erfahrene Entwickler nicht mehr, wie die Software tatsächlich umgesetzt wurde. Die KI lässt sich dann nicht mehr sinnvoll steuern, ihre Ergebnisse werden nur noch abgenickt.

Genau deshalb sehe ich Lead- und Senior-Engineers in einer besonderen Rolle. Sie sollten ihre Teamkollegen aktiv dazu anregen, KI-generierten Code wirklich zu verstehen, notfalls durch explizites Nachfragen im Review oder im Pairing. Es reicht nicht, Ergebnisse durchzuwinken, weil sie plausibel aussehen, oder die Prüfung einfach an einen weiteren KI-Agenten weiterzureichen.

Ein Punkt, den ich in Gesprächen mit meinem Team immer wieder betone: Wer Code eincheckt, verantwortet ihn, unabhängig davon, wer ihn geschrieben hat. Ein Agent kann keine Verantwortung für einen Produktionsvorfall übernehmen, keine Design-Entscheidung im Review verteidigen und keine Haftung für eine falsche Architekturentscheidung tragen. Das bleibt beim Menschen.

Praktisch heisst das: Bevor ein Pull Request freigegeben wird, muss der Engineer erklären können, was der Code tut und warum diese Lösung gewählt wurde. Es genügt nicht, dass er die Tests besteht. Wir fragen in Reviews inzwischen bewusst öfter: «Wie hast du das umgesetzt?» Auffällig ist dabei: Reviews dauern mit KI-generiertem Code eher länger als kürzer, selbst wenn mehr Code in kürzerer Zeit entsteht. Wer das ignoriert und Reviews trotzdem im Tempo der Code-Erzeugung durchwinkt, verlagert das Problem nur nach hinten.

Deshalb setzen wir zunehmend auf gestufte Reviews:

• Mechanisches automatisieren: Formatierung, bekannte Sicherheitsmuster
• Menschliche Aufmerksamkeit gezielt einsetzen: Absicht, Architektur, fachliche Korrektheit

Bei wichtigen Entscheidungen, etwa einem Architektur-Vorschlag, lohnt sich zudem eine zweite menschliche Meinung: nicht nur KI-Vorschlag und ein Reviewer, sondern bewusst zwei Köpfe.

Wichtig ist uns dabei auch die Abgrenzung: Wir glauben nicht an pauschale Verbote wie «keine KI-generierten Tests» oder «kein Review durch KI-Agenten». Solche Regeln sind zu grob und meist schwer durchzusetzen. Sinnvoller sind differenzierte, praxisnahe Leitplanken. Denn nicht die Geschwindigkeit oder ein Maximum an verbrauchten Tokens ist das Ziel: Wer zehnmal schneller Code produziert, den im Team niemand mehr versteht, hat kein Problem gelöst. Er hat es nur verschoben.
 

Cognitive Debt ist kein Grund, generative KI aus der Entwicklung zu verbannen, dafür ist der Produktivitätsgewinn zu real. Wohl aber ein Grund, bewusster zu arbeiten: Spezifikationen vor der Implementierung, Rückfragen statt blindem Vertrauen und die klare Haltung, dass die Verantwortung für Code nie an ein Werkzeug delegiert werden kann. Wir tauschen uns dazu laufend im Team aus. Die Diskussion ist damit längst nicht abgeschlossen.