Verständnisschulden sind die eigentliche KI-Steuer

Stellen Sie sich eine Entwicklerin vor, die einen Abgleichpfad für Zahlungen öffnet, den sie vor fünf Monaten selbst geschrieben hat: vierhundert Zeilen, grüne Tests, in Produktion. Sie braucht eine Stunde für einen subtilen Off-by-One-Fehler, weil sie sich nicht mehr daran erinnert, warum die Funktion so aufgebaut ist, wie sie aufgebaut ist. Ihr eigenes git blame liest sich wie fremder Code. Sie hatte die Funktion mit einem KI-Assistenten 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.

Die Disziplinen, die sich auszahlen

Wir liefern jede Woche KI-gestützten Code über ZahlFlow, BookMe, Commersio, FlexiLearn, Ordrino und iCAS aus, und die folgenden Disziplinen haben in der Einführung alle wehgetan. Jede einzelne tauscht Durchsatz gegen Verständnis — genau der Tausch, den das Problem verlangt.

Machen Sie Lesezeit zu einer Kennzahl erster Klasse. Erfassen Sie die Stunden, die jede Entwicklerin mit dem Lesen von Code verbringt, den sie nicht selbst geschrieben hat, und berichten Sie sie in den Retros neben den gemergten Pull Requests. Es ist die Einzelmaßnahme mit dem höchsten Hebel auf dieser Liste — und die, die Teams zuerst streichen.

„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. Das ist auch ein Grund, hier einen dialogorientierten Assistenten der Copilot-artigen Inline-Vervollständigung vorzuziehen: Der Dialogmodus zwingt die Entwicklerin, das Problem zu formulieren — und genau dieses Formulieren fehlte in der Anthropic-Studie.

Bewusste KI-freie Wartungsrotationen. Geben Sie jeder Senior-Entwicklerin einen wiederkehrenden Tag für die Wartung älterer Module ohne KI-Unterstützung — nur Editor, Dokumentation und git blame. Nichts stellt das Verständnis für Code, der vor sechs Monaten ausgeliefert wurde, so direkt wieder her.

Code-Leseclubs für KI-lastige Module. Nehmen Sie einmal im Monat ein Modul, bei dem sich das Team stark auf einen Assistenten gestützt hat, und lassen Sie vier Entwicklerinnen es eine Stunde lang gemeinsam lesen. 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. Daraus wird ein Budgetposten für Lesezeit, Rotation und Pair-Programming — und die Haftung wird sichtbar, bevor ein Incident sie sichtbar macht.

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. Messen Sie stattdessen Verständnis-Outputs — Lesezeit, Qualität der Explain-Back-Stichproben, wie schnell jemand eigenen Code debuggen kann — 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)