- KI-gestützte Entwicklung erhöht die Geschwindigkeit der Code-Produktion über das menschliche Verständnis hinaus, wodurch „kognitive Schulden (cognitive debt)“ entstehen
- Selbst wenn Code korrekt funktioniert und Tests besteht, sammelt sich ein Zustand an, in dem Entwickler die Struktur und die Gründe des Codes selbst nicht verstehen
- Grenzen der Prüfung durch Reviewer, Verlust impliziten Wissens in Organisationen und Lerndefizite bei Junior-Entwicklern beschleunigen diese Schulden
- Organisationen messen nur geschwindigkeitsorientierte Kennzahlen (DORA, Story Points usw.) und erfassen das Verständnisdefizit dadurch nicht
- Je größer die Lücke zwischen Produktivität und Verständnis wird, desto größer ist langfristig das Risiko von Wartungsfehlern, Wissensabbrüchen und stagnierendem Wachstum von Engineers
Verständnisverzug (The Comprehension Lag)
- Manuelles Programmieren führt Produktion und Aufnahme gleichzeitig aus, und die Reibung des Tippens fördert das Denken
- Beim Schreiben von Code entstehen ganz natürlich mentale Modelle und Intuition
- KI-gestützte Entwicklung trennt diesen Prozess, sodass die Ausgabegeschwindigkeit sprunghaft steigt, die Geschwindigkeit des Verständnisses aber an menschliche Grenzen gebunden bleibt
- Diese Lücke zwischen Output und Verständnis ist genau die kognitive Schuld; anders als technische Schulden ist sie in Geschwindigkeitsmetriken nicht sichtbar
- Das Problem zeigt sich später in Zuverlässigkeitsmetriken wie steigender MTTR und höherer Change Failure Rate
Was Organisationen tatsächlich messen (What Organizations Actually Measure)
- Organisationen messen nur sichtbare Ergebnisse (Anzahl von Features, Commits, Review-Geschwindigkeit usw.)
- Früher waren Output und Verständnis miteinander verbunden, daher nahm man an: Wenn ein Feature ausgeliefert wurde, war auch Verständnis vorhanden
- Im KI-Zeitalter ist jedoch die Auslieferung von Features schon mit rein oberflächlichem Verständnis möglich, weshalb diese Annahme nicht länger gilt
- Organisationsmetriken erfassen das Verständnisdefizit nicht, wodurch Leistungsbewertung und Vergütungssysteme verzerrt werden
Das Dilemma der Reviewer (The Reviewer’s Dilemma)
- Durch KI können Junior-Entwickler schneller Code erzeugen als Senior-Entwickler
- Senior-Reviewer haben nicht genug Zeit, große Code-Mengen gründlich zu prüfen, und opfern deshalb die Tiefe der Prüfung
- Dadurch zerbricht die Annahme „reviewter Code = verstandener Code“
- Da organisatorischer Druck Geschwindigkeit priorisiert, wird eine auf Durchsatz statt auf Prüfqualität ausgerichtete Kultur weiter verstärkt
Das Burnout-Muster (The Burnout Pattern)
- Engineers, die KI-Tools nutzen, erleben die Erschöpfung einer Kombination aus hohem Output und geringer Sicherheit
- Der Code funktioniert, aber die anhaltende Unsicherheit, das selbst gebaute System nicht vollständig zu verstehen, bleibt bestehen
- Ein geschwindigkeitsorientiertes Bewertungssystem macht Zeitinvestitionen für tiefes Verständnis zum Nachteil und beschleunigt die kognitiven Schulden
Der Zusammenbruch des organisatorischen Gedächtnisses (When Organizational Memory Fails)
- Organisationswissen besteht aus dokumentiertem explizitem Wissen und implizitem Wissen in den Köpfen der Entwickler
- KI-Entwicklung verkürzt den Prozess der Bildung impliziten Wissens (direkte Implementierungserfahrung), sodass kein Wissensaufbau stattfindet
- Das Ergebnis: Das System funktioniert, aber die Zahl der Menschen, die es verstehen, nimmt allmählich ab
- Wenn Probleme auftreten, entsteht ein Zustand, in dem niemand den Kontext des Systems erklären kann
Wie sich die Schulden aufstauen (How the Debt Compounds)
- Erstens werden ältere Codebasen immer riskanter — Code, der schon bei seiner Entstehung nur unvollständig verstanden wurde, wird vollständig undurchsichtig
- Zweitens steigt die Wiederherstellungszeit bei Incident Response sprunghaft — es entsteht die Situation, eine „Blackbox, die von einer Blackbox gebaut wurde“ zu debuggen
- Drittens droht das Ausbleiben zukünftiger Senior-Engineers — durch KI-Abhängigkeit verschwindet die Lernkurve, was langfristig zu Führungslücken führt
Die Sicht eines Directors (The Director’s View)
- Führungskräfte nehmen nur positive Signale wahr, etwa höhere Produktivität, kürzere Zeitpläne und effizienteren Personaleinsatz
- Da es keine Metriken gibt, die „Tiefe des Verständnisses“ oder „Erklärbarkeit“ messen, werden kognitive Schulden nicht berichtet
- Daher sind datenbasierte Entscheidungen rational, aber unvollständig, und das tatsächliche Risiko bleibt verborgen
Wo dieses Modell an seine Grenzen stößt (Where This Model Breaks)
- Das Konzept der kognitiven Schulden gilt nicht für alle Aufgaben in gleicher Weise
- Für einfache Wiederholungsaufgaben oder schnelle Experimente kann es geeignet sein
- Auch früher war das Niveau des Verständnisses von Person zu Person unterschiedlich; möglicherweise handelt es sich weniger um ein neues Phänomen als um eine Verschiebung der Verteilung
- Künftig könnten Verbesserungen bei Tools und Dokumentation die Verständnislücke verringern
Das Messproblem (The Measurement Problem)
- Organisationen optimieren nur das, was messbar ist
- Geschwindigkeit ist messbar, Verständnis jedoch nicht
- Solange Verständnis nicht in Bewertungssysteme einfließt, bleiben geschwindigkeitsorientierte Anreize bestehen
- Das ist kein Versagen einzelner Personen oder Manager, sondern das Ergebnis davon, dass Messsysteme aus einer früheren Zeit nicht mehr zur heutigen Realität passen
- Letztlich dürfte sich diese Lücke in steigenden Wartungskosten, verzögerter Incident Response und offengelegten Systemschwachstellen zeigen
- Den Abschluss bildet die Aussage: „Systeme werden nach dem optimiert, was gemessen wird. Aber das, was wir jetzt messen, bildet das Wichtige nicht mehr ab“
3 Kommentare
Ich denke in letzter Zeit ähnlich und habe gestern auch einen Blogbeitrag über kognitive Schulden geschrieben. Offenbar machen sich viele ähnliche Gedanken.
Wie sollte man Codeverständnis angehen? Sollte man es vielleicht messen, indem man sogar Quizfragen auf Grundlage der internen Codebasis erstellt?
Hacker-News-Kommentare
Die Erfahrungen der letzten Monate decken sich sehr mit dem, was im Artikel beschrieben wird.
Das Projekt, an dem ich arbeite, ist stetig gewachsen, aber die Zahl der Engineers ist sogar gesunken.
Wir verlassen uns stärker auf Tests und sind zu simulatorbasierter Entwicklung übergegangen. Auf dem realen System wird nur noch selten validiert, und wenn doch, dann an den komplexesten Teilen.
Seit etwa letztem Jahr merke ich, dass ich sogar bei Features, an denen ich monatelang gearbeitet habe, die Details schnell wieder vergesse. Das war noch bevor Coding-Agents ernsthaft eingeführt wurden.
Seit die Agents da sind, sind PR-Reviews viel impliziter geworden; der Kontext bleibt einem nicht im Kopf, sodass man sich bewusst konzentrieren muss. Teammitglieder berichten von denselben Erfahrungen.
Wir probieren gerade verschiedene Dinge aus, etwa die Pläne des Agents zusammen mit dem Code zu committen. Dadurch wird der Prozess systematischer und expliziter.
Allerdings schien unser Engineering-Manager diese zunehmende kognitive Belastung kaum wahrzunehmen.
Die Grundannahme des Textes, „Entwickler erinnern sich an den Code, den sie vor sechs Monaten geschrieben haben“, stimmt nicht.
Schon immer war es leichter, Code beim Schreiben zu verstehen als beim Lesen. Joel Spolsky sagte ebenfalls, dass „Code lesen schwieriger ist als Code schreiben“.
Das Problem von „Code, den niemand versteht“, gab es schon vor AI.
Zum Beispiel wurde wie im Fall der gelöschten Pinball-Codebasis von Microsoft bei altem ausgelagertem Code manches so komplex, dass es niemand mehr verstand und die Funktion am Ende aufgegeben wurde.
Der Fall der Oracle-RDBMS-Codebase ist ähnlich.
Die Formulierung „ein funktionierendes, aber fremdes System“ ist mir besonders hängen geblieben.
Das ähnelt dem Gefühl, das Entwickler beim Wechsel ins Management haben. Je weiter man sich vom Code entfernt, desto abstrakter und abgetrennter fühlt sich das Verständnis an.
Die Aussage „Engineers, die tief verstehen wollen, fallen bei Geschwindigkeitsmetriken zurück“ trifft am meisten.
Der Markt priorisiert Geschwindigkeit über Qualität, und am Ende entsteht eine Struktur, in der vorsichtige Engineers entlassen werden.
Vielleicht müssen wir jetzt in das Zeitalter von „LGTM, LLM“ übergehen.
Die Branche schlägt immer erst zu weit aus und findet später ihr Gleichgewicht. Das Problem ist die unmögliche Erwartung, 20-fache Produktivität zu verlangen und gleichzeitig 100 % Verantwortung einzufordern.
Am Ende muss man entweder auf Verständnis verzichten oder nur eine Produktivitätssteigerung von vielleicht 20 % akzeptieren.
Das erinnert mich an Richard Gabriels Philosophie Worse Is Better.
AI-Code entscheidet sich oft eher für Einfachheit als für Korrektheit, aber dieser pragmatische Ansatz — „Wenn es nur funktioniert, gewinnt es“ — könnte sich durchsetzen.
Sobald ein funktionierendes System existiert, kann es schrittweise verbessert werden.
Unser Team hat in den letzten sechs Monaten genau das erlebt, was im Artikel beschrieben wird.
Der Kernsatz, dass AI-gestützte Entwicklung den Aufbau impliziten Wissens unterbricht, trifft genau zu.
Allerdings könnte dieses Phänomen eine vorübergehende Übergangsphase sein.
Langfristig könnten LLMs auf Meta-Ebene Mehrwert schaffen, indem sie Code-Strukturen gut ordnen und Menschen nur dann zu tiefem Verständnis zwingen, wenn es wirklich nötig ist.
Wenn die Dokumentation fehlt, trifft das auch den Produktsupport hart.
Wenn Kunden nach dem Verhalten des Produkts fragen, ist es schwer zu antworten, wenn selbst Engineers ihren eigenen Code nicht gut kennen.
Bei hohem Update-Tempo ist es für andere Teams schwer, mitzuhalten.
Etwas Ähnliches gab es schon beim Aufkommen höherer Programmiersprachen, und am Ende war es in Ordnung.
Wäre es dann auch in Ordnung, wenn LLMs das Codeverständnis abstrahieren?
Der Unterschied ist, dass Compiler deterministisch sind, während LLMs probabilistisch arbeiten.