Comprehension Debt: Die versteckten Kosten, die niemand misst

Die Kopplung, die zerbrach

Solange es Software gibt, waren Code schreiben und Code verstehen dieselbe Tätigkeit. Man tippte eine Funktion, man verstand was sie tat. Man baute ein Modul, man konnte es erklären. Schreiben war Verstehen.

AI hat diese Kopplung gebrochen.

Man kann jetzt eine 200-Zeilen-Funktion in 30 Sekunden akzeptieren, sie überfliegen, die Tests bestehen sehen und ausliefern. Der Code funktioniert. Aber die Lücke zwischen “Code der funktioniert” und “Code den ich verstehe” wächst mit jedem akzeptierten Vorschlag. Diese Lücke hat einen Namen: Comprehension Debt.

Technical Debt lebt im Code. Comprehension Debt lebt in den Köpfen der Entwickler. Es ist die wachsende Distanz zwischen dem, was die Codebasis tut, und dem, was das Team tatsächlich versteht.

Und im Gegensatz zu Technical Debt trackt es niemand.

Das Zinseszins-Problem

Die Mathematik ist einfach und unerbittlich.

Vor AI liefert ein Team 5 Features pro Monat. Das Verständnis wächst mit ungefähr derselben Rate: 5 verstandene Features pro Monat. Das System ist im Gleichgewicht. Was das Team baut, weiß das Team.

Mit AI-unterstützter Entwicklung liefert dasselbe Team 12 Features pro Monat. Aber das Verständnis wächst weiterhin mit 5 pro Monat. Das menschliche Gehirn ist nicht schneller im Verstehen von Code geworden, nur weil AI schneller im Generieren geworden ist.

Das hinterlässt eine Lücke von 7 Features pro Monat, die das Team geliefert hat, aber nicht tiefgreifend versteht.

Über 6 Monate sind das 42 Features, die Ihr Team nicht zuverlässig erklären, debuggen oder erweitern kann, ohne sich erneut auf AI zu stützen. Über ein Jahr 84. Die Codebasis wächst. Das Verständnis des Teams hält nicht Schritt. Und die Lücke verstärkt sich, denn jedes neue Feature, das Code berührt den man nicht versteht, macht das nächste Feature schwieriger zu durchdenken.

Das ist nicht theoretisch. Das ist die tägliche Realität von Teams, die mit AI-Geschwindigkeit arbeiten, ohne Verifikationssysteme zu haben.

Die Evidenz

Die Daten bestätigen, was die Mathematik vorhersagt.

Reviews für AI-lastige Pull Requests dauern 26% länger als Reviews für menschlich geschriebenen Code. Der Grund ist nicht, dass AI-Code länger ist, sondern dass AI-Code unvertraute Muster verwendet, die die kognitive Last für Reviewer erhöhen. Wenn man den Code nicht selbst geschrieben hat und die AI ihn aus Mustern ihrer Trainingsdaten zusammengesetzt hat, erfordert jede Funktion mehr Aufwand zur Validierung.

Reviewer berichten von verringertem Vertrauen bei der Validierung von Logik, die sie nicht geschrieben haben. Das ist Comprehension Debt, die in Echtzeit sichtbar wird: Die Person, die den Code reviewt, kann ihn nicht vollständig verifizieren, weil sie den von der AI gewählten Ansatz nicht vollständig versteht.

Gleichzeitig befinden sich 76% der Entwickler in dem, was Qodo die “rote Zone” nennt, mit häufigen Halluzinationen kombiniert mit geringem Vertrauen in den Code, den sie ausliefern. Nur 3,8% der Entwickler haben sowohl niedrige Halluzinationsraten als auch hohes Vertrauen erreicht. Das ist kein Rundungsfehler. Das ist ein Markt, in dem 96 von 100 Entwicklern Comprehension Debt schneller anhäufen als sie es abbauen können.

Warum Reviews Sie nicht retten können

Code-Review ist die traditionelle Verteidigung gegen Code, den man nicht versteht. Jemand anderes liest ihn, findet die Fehler, und alle lernen.

Aber Code-Review setzt voraus, dass der Reviewer den Code verstehen kann. Wenn AI Funktionen mit Mustern generiert, die der Reviewer nie gesehen hat, zusammengesetzt aus Trainingsdaten die Millionen von Repositories umfassen, steht der Reviewer vor derselben Verständnislücke wie der Autor. Sie reviewen Code, den keiner von ihnen vollständig versteht.

Der 26%ige Anstieg der Review-Zeit bedeutet nicht, dass Entwickler gründlicher sind. Es bedeutet, dass sie kämpfen. Und kämpfende Reviews führen zu einem vorhersehbaren Ergebnis: Reviewer stempeln irgendwann Code ab, den sie nicht vollständig validieren können, weil die Alternative wäre, jeden AI-gestützten PR auf unbestimmte Zeit zu blockieren.

Reviews lösen Comprehension Debt nicht. Sie legen es offen und brechen dann unter seinem Gewicht zusammen.

Die Lösung

Simon Willison bietet einen täuschend einfachen Test: “Kann ich jede Zeile jemand anderem erklären?”

Wenn die Antwort nein ist, haben Sie Comprehension Debt. Es spielt keine Rolle, dass die Tests bestehen. Es spielt keine Rolle, dass das Feature funktioniert. Wenn Sie den Code nicht erklären können, können Sie den Code nicht warten. Sie sind einen unerwarteten Bug davon entfernt, auf Logik zu starren, die Sie nicht verstehen, unter Zeitdruck, und wünschen sich, Sie hätten sich die Zeit genommen, sie zu lernen, als sie noch frisch war.

Paranoid Verification erzwingt Verständnis durch Design. Man kann Code nicht aus mehreren Blickwinkeln verifizieren, ob Verhalten, Struktur, Sicherheit oder Performance, ohne zu verstehen, was der Code tut und warum er es so tut. Verifikation erfordert Verständnis. Das ist kein Nebeneffekt. Das ist der Sinn.

Jeder Verifikations-Prompt, der fragt “erkläre warum dieser Ansatz gewählt wurde” oder “identifiziere welche Annahmen dieser Code macht”, baut Comprehension Debt in Echtzeit ab. Der Entwickler, der verifiziert, ist der Entwickler, der versteht. Der Entwickler, der versteht, ist derjenige, der den Code in sechs Monaten debuggen, erweitern und warten kann, wenn die AI-Sitzung, die ihn generiert hat, längst vorbei ist.

Die Wahl ist klar: Zahlen Sie die Verständniskosten jetzt, während der Verifikation, wenn der Kontext frisch und die Kosten niedrig sind. Oder zahlen Sie sie später, während eines Incidents, wenn der Kontext weg und die Kosten katastrophal sind.

Machen Sie die Diagnose, um herauszufinden, wo Ihre Comprehension Debt steht und ob Ihr aktueller Workflow sie verschlimmert.

Sources: CodeRabbit AI Code Quality Report 2025 · Mathieu Kessler, “The Hidden Cost of AI Code” (DEV) · Allstacks, “AI’s Impact on Developer Productivity” · Qodo State of AI Code Quality 2025