Cognitive Debt ist die neue technische Schuld: Was CTOs beim CTO Craft Dinner wirklich diskutieren

Dieser Beitrag basiert auf dem Artikel „CTOs Agree: Cognitive Debt Is the New Technical Debt” von Ivan Brezak Brkan auf ShiftMag, der die Diskussionen eines CTO Craft Dinners in Toronto zusammenfasst. Den englischen Originaltext findest du unter shiftmag.dev.

Das Format dieser Dinner ist bewusst ohne Slides und Sponsorenvorträge. Engineering-Leader aus über einem Dutzend Unternehmen sprechen unter Chatham House Rules offen darüber, was in ihren Organisationen tatsächlich passiert. Die Quintessenz des Abends war innerhalb von fünf Minuten klar: Niemand hat es gelöst.

Key Takeaways (TL;DR)

• Die Freigabe-Phase ist vorbei: CFOs erwarten messbaren ROI innerhalb von 12 Monaten. Tokenverbrauch ist die neue unkontrollierbare Investitionsgröße.
• Cognitive Debt ersetzt technische Schulden: Teams liefern mehr Features als je zuvor, aber das Verständnis des eigenen Codes wächst nicht mit.
• Code Review ist der neue Engpass: Die Fähigkeit, Code zu generieren, übertrifft die Fähigkeit, ihn zu reviewen. Menschliches Urteilsvermögen ist die knappe Ressource.
• Interviews verschieben sich: Statt Coding testen progressive Teams jetzt Code Review, weil das die tatsächliche Tätigkeit widerspiegelt.
• Karrierepfade hinken hinterher: 90 Prozent der Entwickler wollen KI nutzen, aber Beförderungskriterien und Kompetenzmodelle sind nicht angepasst.
• Vendor-Lock-in wird zum Single Point of Failure: Nicht nur Engineering, auch Marketing und Finance bauen auf spezifische Modell-APIs, ohne die Abhängigkeit zu verstehen.

Das Ende der Freigabe-Phase

Vor zwei Jahren lautete das Mandat in den meisten Unternehmen: In KI investieren, keine Fragen stellen. Diese Phase ist vorbei. Was sie ersetzt hat, ist ein härteres Gespräch, das die meisten Teilnehmer bereits mit ihren CFOs geführt hatten.

Die Frage hat sich verschoben. Nicht mehr „Nutzt ihr KI?” sondern „Was bekommt ihr dafür?”

Das Problem sitzt tiefer als fehlende Metriken. Engineering-Kapazität war früher gleichbedeutend mit Headcount. Das konnte Finance modellieren. Heute bedeutet Kapazität Tokens. Und niemand kontrolliert, wie viele Tokens ein einzelner Entwickler an einem Tag verbraucht.

Ein Teilnehmer formulierte es so: Der CFO hat keine Kontrolle mehr über die tatsächliche Investition, sobald der Vertrag unterschrieben ist. Und wenn man die Investition nicht beziffern kann, was bedeutet dann der prognostizierte Return?

Das Muster, das mehrere Teilnehmer beschrieben, ist vertraut: Organisationen kauften die Tools, unterschrieben die Verträge, und stellten dann fest, dass kein Finanzmodell existiert, um das zu steuern, was danach kommt. Der Vergleich, der am Tisch immer wieder fiel: frühe Cloud-Adoption. FinOps, bevor FinOps existierte. Kosten sind Fantasie, Nutzung ist undefiniert, und die Metriken, um beides zu messen, sind noch nicht erfunden.

Das deckt sich exakt mit der Gartner-Prognose, die wir bereits analysiert haben. Dort wird der Kipppunkt auf 2028 datiert: Tokenkosten pro Entwickler übersteigen den globalen Durchschnittslohn. Sechs Prozent der Unternehmen sind bereits dort. Die CTOs an diesem Tisch haben diese Dynamik aus erster Hand erlebt.

Die pragmatische Antwort: den Wildwuchs stoppen und standardisieren. Nicht weniger KI nutzen, sondern dieselben Tools klüger einsetzen.

Was Interviews jetzt prüfen

Die Einstellungsdiskussion legte eine Spaltung offen, die in der Branche selten explizit gemacht wird: Der KI-Engineer, der Produkt liefert, und der Engineer, der Systemdesign verantwortet, sind zwei verschiedene Rollen. Sprache ist egal geworden. Python, Go, Rust, Node. Aber Systemdesign hat sich nicht verändert. Jemand muss über Verfügbarkeit, Budgets und architektonische Entscheidungen nachdenken, die KI nicht treffen kann.

Ein Teilnehmer beschrieb den neuen Software-Engineer als Produktführer. Jemand, der darüber nachdenkt, was das Produkt ist, nicht nur wie es funktioniert. Aber es braucht weiterhin technische Menschen, die über das Design nachdenken. Das sind zwei verschiedene Dinge.

Bei den Interviews neigte der Konsens dazu, die technischen Grundlagen beizubehalten, mit einer entscheidenden Anpassung. Ein Team hatte seinen gesamten Interviewprozess auf Code Review umgestellt. Nicht weil Coding unwichtig geworden wäre, sondern weil Code Review die tatsächliche Tätigkeit im Alltag geworden ist. Implementierung ist jetzt KI-gestützt. Wie genau, darf jeder selbst entscheiden. Was zählt, ist die Fähigkeit, das Ergebnis zu bewerten.

Das ist die logische Konsequenz einer Entwicklung, die Ben Edgars von OpenAI in seinem Bug-Bash-Vortrag auf den Punkt gebracht hat: Code ist billig geworden. Korrektheit nicht. Wenn ein Team Code schneller generieren kann als es reviewen kann, ist der Engpass das menschliche Urteilsvermögen, nicht der Output.

Teamreaktionen und Rekalibrierungsmomente

Keines der Teams am Tisch war einheitlich begeistert oder einheitlich resistent. Die Realität war unübersichtlicher.

Ein Leader beschrieb späte Adoptierer, die nach sanftem Druck eingestiegen waren und dann einen Rekalibrierungsmoment erlebten: Die Erkenntnis, dass ganze Arbeitskategorien, die früher Tage dauerten, jetzt Stunden brauchen. Und dass man danach den eigenen Arbeitsrhythmus grundlegend überdenken muss.

Ein anderer beschrieb einen Engineer, der KI hochproduktiv einsetzt, gleichzeitig aber zutiefst skeptisch gegenüber KI-generiertem Output ist. „Das wurde von KI geschrieben.” — „Okay, aber ist es gut?” — „Ja, es ist gut. Aber es wurde von KI geschrieben.”

Die Sorge, dass KI die Menschen vom Denken abhält, kam mehrfach auf. Das Gegenargument war keine Abweisung, sondern ein Reframing: Das ist ein Management-Problem, kein Technologie-Problem. Die Tools machen es leicht, faul zu sein. Die Aufgabe einer Führungskraft ist es, dafür zu sorgen, dass sich Faulheit nicht lohnt.

Ein Teilnehmer brachte den Unterschied so auf den Punkt: Man kann etwas Schnelles, Langes und nicht besonders Gutes produzieren. Oder man kann KI nutzen, um zu iterieren und das Ergebnis auf etwas Kurzes und Präzises herunterzuarbeiten. Wir können jetzt alle lange Briefe schreiben. Ob wir das sollten, ist eine andere Frage.

Eine anonyme Umfrage bei einem der vertretenen Unternehmen zeigte, dass 90 Prozent der Entwickler KI nutzen wollen. Was den Leader nicht überraschte, war die Begeisterung. Was ihn überraschte, waren die Folgefragen: Was bedeutet das für Beförderungskriterien? Für die Kompetenzmatrix? Wie wird individuelle Leistung bewertet, wenn jeder Code generieren kann?

Die Adoption war der Enablement vorausgelaufen. Die Teams nutzen KI schnell, aber die Karrierepfade und Bewertungsstrukturen sind nicht mitgewachsen.

Cognitive Debt: Das Feature-Schulden-Problem

KI macht es billig, Code zu schreiben. Das ist nicht dasselbe, wie es billig zu machen, ihn auszuliefern oder zu warten. Ein Teilnehmer formulierte es klar: Cognitive Debt ist die neue technische Schuld.

Die Teilnehmer hatten dasselbe Muster beobachtet: Teams fügen Features in einem Tempo hinzu, das vor zwei Jahren unmöglich gewesen wäre. Jetzt tragen sie die Wartungslast, die damit einhergeht. Legacy-Code, der ohnehin schwer zu verstehen war, ist jetzt noch schwerer zu verstehen, weil die Menschen, die ihn geschrieben haben, nicht sorgfältig waren. Sie waren schnell. Und interne Tools, die nie für den Dauerbetrieb gedacht waren, sind jetzt dauerhaft, weil jemand sie mit drei Prompts ausgeliefert hat.

Die Prozesse, die es dafür gab (Build-or-Buy-Entscheidungen, langfristige Wartbarkeitsbewertungen), existierten aus gutem Grund. Aber wenn man etwas an einem Nachmittag aufsetzen kann, ist es leicht, sie zu überspringen. Das Problem kommt später.

Das ist exakt das Muster, das in der Vibe-Coding-Falle beschrieben wird: Geschwindigkeit ohne Architekturkontrolle produziert Code, den niemand versteht, und technische Schulden, die niemand eingeplant hat. KI verschärft dieses Problem, weil die Geschwindigkeit die menschliche Fähigkeit zur Qualitätssicherung übersteigt.

Ein Teilnehmer formulierte die Gegenposition: Schreib, was du willst, aber das Schreiben allein bedeutet nicht, dass du es auslieferst. Code ist billig, aber das Launching nicht. Diese Unterscheidung in einem Team aufrechtzuerhalten ist schwieriger, als es klingt, wenn das Management jeden PR feiert.

Das Konzept eines dedizierten Technical-Health-Teams kam als strukturelle Antwort auf: Engineers, die Features liefern, und Engineers, die Features löschen oder refactoren, als gleichwertige Arbeit behandelt. Buy-in dafür von einem Geschäft zu bekommen, das auf Velocity optimiert, ist die eigentliche Herausforderung.

Sollen Product Manager PRs liefern?

Die hitzigste Diskussion des Abends: Wenn KI es jedem ermöglicht, Code zu schreiben, sollen Product Manager PRs schicken?

Der Raum war gespalten. Nicht in der Frage, ob es technisch möglich ist (alle stimmten zu), sondern ob es das Richtige ist, darauf zu optimieren.

Ein Teilnehmer widersprach der Erzählung von Nicht-Engineers, die an Produktion liefern, als Erfolg: Wenn man Engineers faktisch zu Code-Review-Wächtern macht, die das Unternehmen vor PRs schützen, die sie nicht geschrieben haben, während der PM den Credit fürs Ausliefern bekommt, sollte man bei den Engineers nach dem mentalen Gesundheitszustand fragen.

Die pragmatischere Position: Nicht-Engineers auf kleinere, risikoärmere Aufgaben einzulassen, verkürzt den Feedback-Loop für alle. Designer, die eine Komponente nach Spec schreiben können, ohne auf einen Engineer zu warten. Product Manager, die einen Copy-Bug fixen können, ohne ein Jira-Ticket zu öffnen. Das hat Wert, solange die Leitplanken stimmen.

Die härtere strukturelle Frage blieb ohne klare Antwort: Wenn jeder liefern kann, wessen Job ist es, alles zusammenzuhalten? Mehrere Teilnehmer sagten, die einzige realistische Antwort sei radikale Teamautonomie: kleine Gruppen von drei bis fünf Personen, die ihre eigenen Entscheidungen verantworten. Die Aufgabe des Managements verschiebt sich von Gatekeeping zu Alignment.

Code Review als Engpass und die Vertrauensfrage

Ein Teilnehmer hatte das Problem aus der CI/CD-Perspektive durchdacht. Die Schwierigkeit liegt nicht darin, dass Teams keinen Code generieren können. Sie liegt darin, dass sie ihn nicht schnell genug reviewen können. Menschliches Review ist jetzt der Engpass. Die Lösung sind nicht mehr Reviewer. Es ist klügere Triage.

Sein Team experimentierte mit Confidence Scoring für PRs: KI bewertet das Risiko einer Änderung und zeigt nur die Teile, die tatsächlich menschliche Augen brauchen. Ein 15.000-Zeilen-PR mit drei Zeilen, die ein Mensch prüfen muss, ist kein 15.000-Zeilen-Review-Problem. Es ist ein Drei-Zeilen-Problem, wenn man dem Rest vertrauen kann.

Der tiefere Punkt betrifft Abstraktionsebenen. Wir lesen keinen Assemblercode. Wir vertrauen Compilern. Die Frage ist, ob man genug Validierungsinfrastruktur (Feature Flags, Observability, Acceptance Tests, Mutation Testing) aufbauen kann, um ein vergleichbares Vertrauensverhältnis mit KI-generiertem Code zu ermöglichen.

Niemand am Tisch behauptete, das gelöst zu haben. Mehrere sagten, dass sie so hart wie möglich in diese Richtung arbeiten.

Ein praktischer Rat, der aus der Diskussion hervorging: Jetzt in Evals investieren, nicht später. Die Kosten für das Bauen von KI-Features sind nicht der schwierige Teil. Die Kosten für die Verifizierung sind es. Wer heute eine solide Eval-Suite aufbaut, kann Anbieter wechseln, Modell-Deprecations überstehen oder auf Open Source migrieren, ohne bei null anzufangen. Das deckt sich mit dem, was das Enterprise-KI-Experiment mit Faktor 93 gezeigt hat: Die Qualität kam nicht aus der KI, sondern aus dem Harness. Wer Verifikation als nachträglichen Schritt behandelt, hat kein Qualitätsproblem. Er hat ein Architekturproblem.

Vendor-Lock-in als unternehmensweites Risiko

Was passiert, wenn Anthropic oder OpenAI die Preise erhöht, einen Ausfall hat oder disruptiert wird?

Eine Teilnehmerin formulierte es direkt: Ihr gesamtes Unternehmen hat einen Single Point of Failure auf Anthropic. Engineering versteht Single Points of Failure. Die Leute in Marketing und Finance, die auf Claude aufbauen, verstehen das nicht. Wenn plötzlich keine Inference mehr verfügbar ist, rufen sie Engineering an.

Das Gegenargument: Wettbewerb wird die Preise in Schach halten. Open-Source-Modelle sind nicht mehr Jahre hinter den kommerziellen Modellen. Man kann seine Preise nicht verdoppeln, wenn Kunden Alternativen haben. Aber das Lock-in-Risiko liegt nicht wirklich beim Modell selbst. Es liegt bei allem, was darum herum gebaut wurde: Skills, Tooling, interne Workflows. Das zu migrieren ist deutlich schwerer als einen Modell-Endpoint zu tauschen.

Der praktische Rat: Jetzt interne UI-Wrapper über generische Modell-APIs bauen, bevor die Teams an spezifische Produktoberflächen gebunden sind. Das ist billig umzusetzen, und es bedeutet, dass das Modell darunter ausgetauscht werden kann, ohne die Oberfläche neu zu bauen, von der die Teams abhängen.

Einordnung: Warum dieses Dinner mehr sagt als jede Keynote

Die Diskussionen an diesem Tisch bestätigen ein Muster, das sich durch die gesamte aktuelle Debatte zieht. Die Branche hat ein Geschwindigkeitsproblem gelöst und dabei drei neue Probleme geschaffen: unkontrollierte Kosten, fehlende Governance-Strukturen und eine wachsende Lücke zwischen Output und Verständnis.

Cognitive Debt ist der präziseste Begriff, der dafür bisher gefallen ist. Technische Schulden waren immer messbar: Code-Duplikation, fehlende Tests, veraltete Dependencies. Cognitive Debt ist schwerer zu quantifizieren, weil sie im Kopf der Menschen sitzt. Es ist die Differenz zwischen dem, was ein Team produziert, und dem, was es versteht.

Das Paradox der Aufsicht beschreibt denselben Effekt auf individueller Ebene: Die Kontrolle von KI erfordert exzellente Programmierkenntnisse. Genau diese Kenntnisse verkümmern, wenn die KI die meiste Arbeit macht. Cognitive Debt ist die organisatorische Version dieses Paradoxons. Das Team liefert mehr, versteht weniger, und die Fähigkeit zur Korrektur sinkt mit jedem Feature, das ohne vollständiges Verständnis ausgeliefert wird.

Die Teilnehmer hatten keine fertigen Antworten. Das ist ehrlicher als jede Keynote, die behauptet, das Problem sei gelöst. Die Richtung war klar: standardisieren statt freigeben, Verifikation vor Geschwindigkeit setzen, und akzeptieren, dass die schwierigste Arbeit an der KI-Adoption nicht technisch, sondern organisatorisch ist.

Wie geht dein Team aktuell mit Cognitive Debt um, und habt ihr einen Prozess, der die Lücke zwischen Output und Verständnis sichtbar macht?