Verständnisschulden sind die eigentliche KI-Steuer

Eine Senior-Entwicklerin bei einem unserer Kunden hat im vergangenen Monat eine Stunde gebraucht, um einen subtilen Off-by-One-Fehler in einem Abgleichpfad für Zahlungen zu beheben, den sie im November selbst geschrieben hatte — 400 Zeilen, grüne Tests, fünf Monate in Produktion. Eine Stunde, weil sie sich nicht mehr daran erinnerte, warum die Funktion so aufgebaut war, wie sie aufgebaut war. Ihr eigenes git blame las sich wie fremder Code. Sie hatte die Funktion mit Claude Code an einem Nachmittag geschrieben.

Das ist die billigste denkbare Illustration dessen, was die Anthropic-Studie zur Kompetenzbildung (opens in new tab) gemessen hat: 52 Entwicklerinnen und Entwickler lernten die asynchrone Bibliothek Trio, beide Gruppen brauchten etwa gleich lang, doch im Verständnistest erreichte die KI-gestützte Gruppe 50 % gegenüber 67 % bei der Kontrollgruppe — ein Abstand von 17 Prozentpunkten, am größten beim Debugging (opens in new tab). Unser bestehender Beitrag zur Review-Disziplin und zur Kennzahl von 23,5 % Incidents pro Pull Request aus dem Cortex 2026 Benchmark (opens in new tab) deckt eine andere Haftung ab: Die Incident-Rate lässt sich schon in der ersten Woche messen; Verständnisschulden lassen sich erst im zweiten Jahr messen — wenn jemand kündigt, wenn um 03:00 Uhr ein Incident zuschlägt oder wenn eine Aufsichtsbehörde Fragen zu einem Subsystem stellt, das niemand im aktuellen Team geschrieben hat. Für Mittelstandskunden mit Software, die 10 bis 20 Jahre läuft, ist die zweite Kategorie die teure.

Verständnisschulden sind eine Haftung auf Menschen, nicht auf Artefakten

Die klarste Formulierung stammt von Addy Osmani (opens in new tab): Verständnisschulden sind „die wachsende Lücke zwischen der Menge an Code, die in Ihrem System existiert, und der Menge, die irgendein Mensch tatsächlich versteht." Technische Schulden leben im Code und zeigen sich über Reibung, die man greppen kann; Verständnisschulden leben in den Köpfen derjenigen, die den Code warten, und zeigen sich erst unter Stress — ein Reviewer winkt einen Pull Request durch, weil der Code in Ordnung aussieht, eine Bereitschaft verbringt um 02:30 Uhr vierzig Minuten damit, zu rekonstruieren, warum eine Funktion einen ValidationError verschluckt. Davon taucht nichts im Repository auf.

Die arXiv-Studie „Comprehension Debt in GenAI-Assisted Software Engineering Projects" (opens in new tab) — 207 Studierende, 621 reflektierende Tagebücher über acht Wochen — bringt es klar auf den Punkt: Verständnisschulden „liegen in der kollektiven Kognition von Entwicklungsteams und nicht in der Codebasis selbst." Man kann sie nicht wegrefaktorieren. Was verfallen ist, ist das mentale Modell des Teams, und mentale Modelle reagieren nicht auf ein Jira-Epic.

Die vier Akkumulationsmuster, vom Hörsaal in Ihr Team übersetzt

Die Muster aus dem arXiv-Paper wurden bei Studierenden beobachtet, lassen sich aber sauber auf professionelle Teams übertragen — und sind dort schwerer zu erkennen, weil Senior-Engineers die Routine haben, sie zu kaschieren.

Blackbox-Akzeptanz. Ein Senior akzeptiert ein von Claude geschriebenes Migrationsskript, weil die Tests grün sind, ohne zu rekonstruieren, warum es die Tabellen in genau dieser Reihenfolge sperrt. „Verstehen" wird stillschweigend umdefiniert zu „kann die Ausgabe vorhersagen" — ein deutlich schwächerer Maßstab als „kann unter Druck debuggen".

Kontext-Fehlpassungs-Schulden. Das Modell schreibt plausiblen Code, der von einer anderen Architektur, anderen Invarianten ausgeht. Der Code funktioniert; er passt nicht. Über Monate sammeln sich Module an, die gegen eine imaginierte Version Ihres Systems geschrieben wurden, und in dieser Lücke leben die subtilen Bugs.

Abhängigkeitsbedingte Atrophie. Dauerhafte KI-Nutzung reduziert messbar den eigenständigen Verständnisaufwand. Im Anthropic-RCT erreichten Teilnehmende, die die KI für konzeptuelle Rückfragen nutzten, über 65 %; jene, die die Codegenerierung delegierten, lagen unter 40 % (opens in new tab). Gleiches Werkzeug, fast eine ganze Schulnote Unterschied.

Verifikations-Umgehung. Wenn die Entwicklerin das Fachwissen über das Modell erwirbt, ist sie systematisch unterausgestattet, um zu verifizieren, was es produziert hat — der Mechanismus hinter dem Großteil der Sicherheitsausfallquote von 45 % aus den Veracode-Daten von 2025.

Das eine mildernde Muster im Paper: Studierende, die GenAI als Verständnis-Gerüst genutzt haben — Erklärungen anforderten, generierten Code neu schrieben, gegen die Dokumentation prüften — behielten das Verständnis. Das Werkzeug ist nicht das Problem. Die Interaktionsweise ist es.

Warum Mittelstandssysteme diese Rechnung zuerst bezahlen

Hyperscaler können Verständnisschulden gegen eine viel größere Umsatzbasis abfedern. Die Engineering-Ökonomie im Mittelstand ist auf jeder relevanten Achse umgekehrt.

Systemlebensdauern sind lang. Branchendaten zu Legacy-Systemen in Unternehmen (opens in new tab) verorten operative Lebensdauern von 20 Jahren innerhalb des Normalbereichs, wobei 41 % der deutschen und italienischen Industriebetriebe immer noch eigenentwickelte ERP-Systeme betreiben, die vor 2005 gebaut wurden (opens in new tab). Code, den Sie heute ausliefern, wird 2040 immer noch in Produktion sein — und der Kontext der Autorin ist schon heute um 17 Punkte dünner, als er gewesen wäre.

Teams sind klein. Ein Mittelstands-Team hat oft fünf bis fünfzehn Personen. Eine Untersuchung zu Open-Source-Projekten zeigt, dass 16 % einen vollständigen Weggang ihrer Schlüsselentwickler erlebten und nur 41 % ihre Entwicklungsgeschwindigkeit danach wieder aufnehmen konnten (opens in new tab). Geht eine Senior-Entwicklerin, ist die Lücke ihr Wissen plus die Verständnisschulden, die ihre LLM-gestützte Arbeit über zwei Jahre angehäuft hat und die niemand sonst je in den Kopf geladen hat.

Fluktuation ist niedrig — meistens gut, gelegentlich eine Falle. Mittelstandsunternehmen haben im Schnitt 3 % jährliche Fluktuation (opens in new tab). Das Anti-Pattern „fragen wir einfach Jane" wirkt sicher — bis Jane 2029 in Elternzeit geht und ihre Nachfolge eine 600-Zeilen-Datei öffnet, die Jane 2026 mit Cursor ausgeliefert hat, ohne Kommentare und ohne lebendige Erinnerung daran, warum auch nur eine der Fallunterscheidungen dort steht.

QA-Tiefe ist begrenzt. Nur wenige Mittelstandskunden haben das Personal für die Disziplinen Property-Testing und Mutation-Testing, die wir in unserem Review-Beitrag empfehlen. Der Fehlermodus „Verifikations-Umgehung" rutscht eher in die Produktion und überlebt dort. Das Mittelstandsprofil ist genau das Profil, das am stärksten ausgesetzt ist: langlebige Systeme, kleine Teams, niedrige Fluktuation, die die Abrechnung verzögert, dünne QA. Das Produktivitäts-Dashboard wird zwei Jahre lang hervorragend aussehen. Das Wartungsbudget wird Ihnen im dritten Jahr die Wahrheit sagen.

Was wir in unserer eigenen Praxis geändert haben

Wir liefern jede Woche KI-gestützten Code über ZahlFlow, BookMe, Commersio, FlexiLearn, Ordrino und iCAS aus. Die folgenden Disziplinen haben in der Einführung alle wehgetan.

Lesezeit ist eine Kennzahl erster Klasse. Wir erfassen pro Entwickler und pro Sprint die Stunden, die in das Lesen von Code fließen, den die Person in den letzten 30 Tagen nicht selbst geschrieben hat. Zielwert: mindestens 15 %, berichtet in den Retros neben den gemergten Pull Requests. Einzelmaßnahme mit dem höchsten Hebel auf dieser Liste.

„Diff erklären" als Merge-Gate für KI-berührte Pull Requests. Vor dem Merge schreibt die Autorin eine Erklärung von zwei bis vier Sätzen, was sich geändert hat und warum, in eigenen Worten. Kann sie das nicht, wird der Pull Request nicht gemergt. Mehrere Engineers haben nach einem Monat leise die Copilot-artigen Inline-Vervollständigungen zugunsten von Claude-Code-Dialogen aufgegeben — der Dialogmodus lehrt, der Vervollständigungsmodus tut es nicht, exakt deckungsgleich mit dem Befund der Anthropic-Studie.

Bewusste KI-freie Wartungsrotationen. Jede Senior-Entwicklerin verbringt pro vierzehn Tagen einen Tag mit der Wartung älterer Module ohne KI-Unterstützung — nur Editor, Dokumentation und git blame. Die einzige Praxis, die wir gefunden haben, die das Verständnis für Code zuverlässig wiederherstellt, der vor sechs Monaten ausgeliefert wurde.

Code-Leseclubs für KI-lastige Module. Einmal im Monat lesen vier Entwicklerinnen in einer einstündigen Sitzung gemeinsam jedes Modul, in dem im letzten Quartal mehr als 40 % der Zeilen KI-geschrieben waren. Das Modul wird in vier weitere Köpfe geladen, und vorhandene Verständnisschulden zeigen sich, wenn jemand fragt „Warum ist dieser Catch-Block hier?" und niemand es beantworten kann.

Verständnisschulden in der Engineering-Bilanz. Ein quartalsweiser Bericht parallel zum Inventar der technischen Schulden: Anteil des KI-gestützten Codes, Module mit Bus-Faktor < 2, durchschnittliches Alter der letzten Berührung durch Autoren für kritische Pfade, Stichprobenquote der Explain-Back-Erklärungen. Outputs: ein Budgetposten für Lesezeit, Rotation und Pair-Programming — das erste Modell, das wir haben, das die Haftung sichtbar macht, bevor ein Incident es tut.

Was wir ausprobiert und verworfen haben

KI für „wichtige" Module verbieten. Entwickler haben das Label umgangen, und die Labels wurden veraltet. Der gefährliche Fall ist nicht KI auf kritischen Modulen, sondern ungeprüfte KI auf irgendeinem Modul.

Entwickler zwingen, KI-generierten Code von Hand abzutippen. Das Ergebnis war der ursprüngliche KI-Code mit Tastaturverzögerungen. Abtippen baut kein Verständnis auf; Erklären tut es.

KI-Nutzung direkt messen. Den Anteil akzeptierter KI-Zeichen zu tracken ist manipulierbar, verrauscht und fühlt sich an wie Überwachung. Wir tracken jetzt Verständnis-Outputs — Lesezeit, Qualität der Explain-Back-Stichproben, Reaktionszeit bei Incidents auf eigenem Code — nicht KI-Inputs.

Zu glauben, „KI-native" Junior-Entwickler würden sich das Verständnis im Job aneignen. Tun sie nicht. Juniors, die mit einem Assistenten an der Seite gelernt haben, haben dünnere Debugging-Instinkte. Die Mentoring-Last auf den Seniors ist in einem KI-lastigen Team höher, nicht niedriger. Dafür muss budgetiert werden.

Die Rechnung kommt im zweiten Jahr

Das KI-Produktivitäts-Dashboard und das Verständnisschulden-Dashboard bewegen sich in den ersten 12 bis 18 Monaten in entgegengesetzte Richtungen. Der Durchsatz sieht großartig aus; Reviewer fühlen sich produktiv; die Führung hat die Zahlen, die ihr versprochen wurden. Die Rechnung kommt im zweiten Jahr — jemand wechselt, ein Incident verlangt, Code aus dem Vorjahr zu lesen, eine Aufsichtsbehörde fragt nach einer Architekturentscheidung, die eigentlich niemand im heutigen Team getroffen hat, weil ein LLM sie getroffen hat. Auf Mittelstandszeitskalen ist das Signal langsam.

Die Antwort liegt nicht darin, weniger KI-gestützten Code auszuliefern; der Anthropic-Bericht zu agentischen Coding-Trends 2026 (opens in new tab) macht die Produktivitätssicht klar, und wir stimmen ihr zu. Die Antwort liegt darin, dass das Engineering-Budget einen neuen Posten braucht. Code zu schreiben ist heute der billige Teil. Den Code zu verstehen — auf dem Niveau, auf dem Sie um 03:00 Uhr seine Fehlermodi durchgehen können — ist der teure Teil. Gehen Sie bei der Generierung so schnell, wie Sie wollen, und investieren Sie die Durchsatz-Dividende in Verständnis. Die Teams, die das tun, werden 2030 immer noch selbstbewusst ausliefern. Die Teams, die den vollen Produktivitätsgewinn einstreichen, werden es nicht.

Weiterführende Literatur

• Addy Osmani, Comprehension Debt — the hidden cost of AI generated code (opens in new tab)
• Comprehension Debt in GenAI-Assisted Software Engineering Projects (arXiv 2604.13277) (opens in new tab)
• Anthropic, How AI assistance impacts the formation of coding skills (opens in new tab)
• Cortex, Engineering in the Age of AI: 2026 Benchmark Report (opens in new tab)
• Anthropic, 2026 Agentic Coding Trends Report (opens in new tab)
• GitClear, AI Copilot Code Quality: 2025 Research (opens in new tab)