Technische Schulden durch KI: Zwei verschiedene Probleme

Technische Schulden durch KI sind nicht das Durcheinander, das Sie denken. Sie sind nicht einfach nur doppelte Funktionen und inkonsistente Namensvergabe, die ein Linter kennzeichnen kann. Die Hälfte davon sieht im Pull Request vollkommen in Ordnung aus, besteht die Review, wird deployed und zeigt sich erst sechs Wochen später, wenn niemand auf dem Team mehr erklären kann, warum eine Änderung an einer Stelle drei Dinge an ganz anderen Stellen zerstört hat. Diese zweite Hälfte wird von den meisten Teams überhaupt nicht gemessen.

Technische Schulden durch KI sind zwei verschiedene Probleme, nicht eins

Fragen Sie fünf Engineering Manager nach ihrer Definition von technischen Schulden durch KI, und Sie bekommen fünf unterschiedliche Antworten. Diese Antworten lassen sich aber in zwei sehr unterschiedliche Kategorien gruppieren.

Die erste ist Code-Schuld: Verdoppelungen, inkonsistente Muster, Code der technisch korrekt ist, aber eine Oberfläche schafft, die niemand wirklich brauchte. Diese Kategorie hat Linting-Tools erfunden.

Die zweite ist kognitive Schuld: die Lücke zwischen der Geschwindigkeit, mit der Code generiert wird, und der Geschwindigkeit, mit der das Team wirklich ein gemeinsames mentales Modell davon aufbaut, was dieser Code tut. Sonar's 2026 Developer Survey zeigt, dass 88% der Entwickler mindestens einen negativen Effekt von KI auf technische Schulden berichten, und 53% sagen, dass KI Code generiert, der korrekt aussieht aber versteckte Fehler enthält. Das ist Code-Schuld. Was der Survey nicht ganz erfasst, ist die zweite Art. LeadDev's Bericht zum Konzept der kognitiven Schuld ist die beste Behandlung dieses Themas, die wir bisher gesehen haben.

Drei von fünf Teams verwechseln die beiden. Hier ist das, was die anderen zwei unterschiedlich machen: Sie tracken Code-Schuld mit Tools, und sie tracken kognitive Schuld mit Gesprächen.

Der Code-Schuld-Teil: Code, der richtig aussieht und es nicht ist

Code-Schuld ist die bekannte Art. KI-generierter Code neigt dazu, Logik zu verdoppeln, die bereits drei Dateien weiter oben existiert, weil der Assistent nicht weiß, dass diese Logik existiert, wenn sie nicht im Context-Fenster ist. Sonar's Survey setzt eine Zahl drauf: 40% der Entwickler sagen, dass KI die Schuld durch unnötigen oder doppelten Code erhöht hat.

Die gefährliche Variante ist nicht der Code, der falsch aussieht. Es ist der Code, der richtig aussieht. Eine Funktion besteht ihre Tests, verarbeitet den Happy Path sauber und liest sich wie etwas, das ein Senior Engineer geschrieben hätte. Außer dass sie ein Edge-Case stumm übersieht, das die ursprüngliche Implementierung behandelt hat. Review findet Tippfehler. Review ist viel schlechter darin, eine plausible aussehende Funktion zu finden, die subtil unvollständig ist.

// KI-generiert: besteht Tests, sieht sauber aus
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Was das Original drei Dateien weiter weg handhabte:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

Nichts hier wirft einen Error. Nichts schlägt in der CI fehl. Die Lücke zeigt sich erst, wenn ein soft-gelöschter User drei Wochen später in einem Report wieder auftaucht, und wer auf Bereitschaftsdienst ist muss grep, blame und rumfragen um rauszufinden, welche Version richtig ist und warum. Diese grep-und-frag-Schleife ist die echte Kosten, und sie lässt sich in Stunden messen, nicht in einem vagen Gefühl, dass etwas komisch ist.

Docs-as-Code Tools, die neben dem Repo sitzen statt in einem separaten Wiki, reduzieren wie oft diese Schleife passiert, weil der Grund hinter einer Funktion einen Klick entfernt von der Funktion selbst lebt, statt in jemandem's Gedächtnis.

Der kognitive Schuld-Teil: Wenn das Team den Überblick verliert

Dr. Margaret-Anne Storey, Informatik-Professorin an der Universität von Victoria, prägte den Begriff "kognitive Schuld" im Oktober 2025, nachdem sie ihre Studierenden schnell deployen sah und dann Mühe hatten, auf ihr eigenes Nutzer-Feedback zu reagieren. Ihre Diagnose: Die Studierenden hatten nicht den Überblick über den Code verloren, sie hatten den Überblick über das, was sie bauten und warum, verloren, und wer auf dem Team was wusste. Und das.

Diese Rahmung borgt sich von Peter Naur's altem Argument, dass Software nicht wirklich der Code ist, sie ist die geteilte Theorie im Kopf der Menschen, die sie gebaut haben. Wenn Code schneller generiert wird als das Team diese Theorie aufbauen kann, wird die Theorie nie gebildet. Man kann eine saubere, vollständig getestete Codebasis haben und trotzdem erhebliche kognitive Schuld, wenn die Menschen, die es deployed haben, es nicht vollständig erklären können, oder wenn nur eine Person es kann.

Das ist der Teil, den Standard KI-Schuld-Metriken komplett vermissen, weil Dashboards den Code tracken, nicht das Verständnis. Die Frage, die es wert ist, in der nächsten Retrospektive zu stellen, ist stumpf: Hängen Sie ein Architektur-Diagramm auf und fragen Sie wer auf dem Team jeden Box erklären kann. Wenn die Antwort ist "eine Person, und sie sind diese Woche im Urlaub," dann haben Sie kognitive Schuld, egal was der Linter sagt.

Ein lebendiges internes Wiki fixiert kognitive Schuld nicht von selbst. Es gibt dem Team einen Ort wo man das "Warum" aufschreiben kann, bevor es nur noch in einer Person's Kopf lebt, was ein Anfang ist.

Warum Code Review mit der Genrationsgeschwindigkeit nicht mithalten kann

Hier liegt das mechanische Problem unter beiden Schuld-Arten: KI lässt einen einzelnen Ingenieur eine Woche Code vor dem Mittag generieren, aber Review-Kapazität hat sich überhaupt nicht skaliert. Der Engpass ist von Schreiben zu Lesen bewegt worden, und Lesen ist der Teil, den niemand beschleunigt hat.

Hier ist der Tool-Vergleich tatsächlich von Bedeutung, und es lohnt sich, spezifisch statt vage zu sein. Copilot und Cursor sind schnell darin, Code innerhalb der Datei zu generieren, die Sie ohnehin offen haben, weshalb sie so gut darin sind, mehr Code zu produzieren als ein Team reviewen kann. Cody und Continue.dev lehnen sich mehr auf Retrieval über das gesamte Repo an, bevor sie generieren, was hilft die Doppelungs-Problem oben zu vermeiden, aber weder ersetzt den menschlichen Schritt zu entscheiden, ob neuer Code passt wie das System sein soll. Keiner von ihnen sagt dir ob die Person, die das PR merged, wirklich versteht was sich geändert hat, das ist eine andere Frage als ob das Diff syntaktisch in Ordnung ist.

Ask-your-codebase Tools existieren genau wegen dieser Lücke: Der schnellste Weg, KI-generierten Code gut zu reviewen, ist zu fragen, in normaler Sprache, "wo sonst existiert dieses Pattern" oder "was handhabt bereits diesen Fall," bevor Sie den Merge genehmigen. Diese Frage zu beantworten dauerte einen Senior Engineer früher zwanzig Minuten grep und blame. Das sollte nicht so sein.

Es gibt auch einen Repo-Größen-Effekt, der es wert ist, genannt zu werden. Bei einem 5000-Zeilen-Service kann ein Reviewer die meisten des Systems im Kopf halten, deshalb fällt eine plausibel aussehende Funktion auf, weil sie nicht zum mentalen Modell des Reviewers passt. Bei einem 80000-Zeilen-Monorepo, das von sechs Teams angefasst wird, hat kein einzelner Reviewer dieses mentale Modell mehr, deshalb segelt plausibel aussehender Code einfach durch, weil niemand im Zimmer das Kontext hat zu sehen, dass es falsch ist. Je größer das Repo, desto mehr die Review-Engpässe hängen von Tools ab statt von einer Senior Engineer's Gedächtnis.

Juniors zahlen diese Schuld zuerst und am schnellsten

Anthropzic lief eine kontrollierte Studie im Januar 2026, ein randomisierter Test mit 52 Junior Entwicklern, und fand heraus, dass die, die KI-Assistenten benutzten, 17% schlechter bei Code-Verständnis-Tests waren, grob zwei Notenstufen. Infobip's interne Engineering Team, die ein Praktikantenprogramm seit 2022 über 225 Praktikanten laufen sieht, das gleiche Muster in echten Längsdaten: Pre-KI Kohorten wuchsen um durchschnittlich 2.50 Punkte in selbst-eingeschätzter technischer Geschicklichkeit über ein Praktikum; KI-Ära Kohorten wuchsen 1.56.

Der Mechanismus ist nicht KI-Nutzung selbst. Zwei Praktikanten in Infobip's neueste Kohorte benutzten KI bei der gleichen Häufigkeit, mit entgegengesetzten Resultatem. Eine fragte Follow-up Fragen und konnte vollständig erklären was die KI produziert hatte; ihr Wachstum war das höchste in der Kohorte. Der andere akzeptierte Output mit minimaler Review, behandelte es als Black Box, und wuchs um Null. Das Tool war identisch. Die Beziehung zu ihm war nicht.

Aufnahmen von Pairing Sessions und Architektur Walkthroughs zu machen, und sie später durchsuchbar zu machen, gibt Juniors etwas zum Zurückgreifen statt die gleiche Frage jedem zu wiederholen, der frei ist. Es ersetzt einen Mentor nicht, aber es senkt die Kosten zu zweimal zu fragen.

Überspringen Sie die "Ban KI für Juniors" Lösung

Jede Zusammenfassung zu diesem Thema landet am Ende bei der gleichen Empfehlung: Beschränken Sie KI-Zugang für Junior Engineers bis sie es sich "verdient" haben. Überspringen Sie diese. Sie passt nicht zu was Teams, die das Problem wirklich gemessen haben, gefunden haben, und sie handelt eine Art Versagensmodus gegen einen anderen; Juniors, die die Tools nicht benutzen können, die ihr Team deployed, fallen auf eine andere Art zurück, genauso real.

Was stattdessen für Infobip funktionierte war Sequenzierung, nicht Verbot: Versuchen Sie zuerst das Problem, checken Sie mit KI zweitens, damit die Gewohnheit des unabhängigen Denkens sich formt, bevor KI zur Standard-Bewegung wird. Sie haben AI-freie Checkpoints hinzugefügt, nicht als Strafe sondern als Kalibrierung, damit sowohl Praktikant als auch Mentor wissen, wo die Geschicklichkeit wirklich steht. Mentoren haben auch sich von PR-Review zu Process-Tracking verschoben: wer fragte was, wer steckte fest wo, wer erklärte ihre eigene Änderung ohne Hilfe.

Zufriedenheit-Werte stiegen die ganze Zeit während Geschicklichkeit-Wachstum fiel, das ist die echte Warnung in ihren Daten: wenn Sie nur tracken wie sich Menschen über die Tools fühlen, werden Sie das nicht kommen sehen. Zwanzig Prozent der Praktikanten in Infobip's neueste Kohorte wussten nicht mal was von einem Junior Engineer auf ihrem Level erwartet wird statt anderen überraschend Orte, was self-assessment praktisch sinnlos macht. Man kann eine Lücke nicht gegen einen Referenz-Punkt messen, den niemand aufgeschrieben hat.

Was wir diesen Sprint wirklich ändern würden

Fangen Sie mit der Frage oben an: wer kann jeden Teil des Systems erklären, laut, jetzt gerade. Diese einzelne Frage zeigt mehr kognitive Schuld in zehn Minuten als irgendein Dashboard je wird.

Für Code-Schuld, halten Sie statische Analyse in der Schleife. Sonar's 2026 Developer Survey zeigt 70% der Entwickler benutzen es bereits, und Teams, die sie laufen lassen, berichten bedeutsam bessere Resultat bei Überarbeitungskosten als Teams, die es überspringen. Das ist keine umstrittene Empfehlung, das ist einfach eins Teams überspringen, wenn sie sich bewegen, weil der KI-Output fertig aussah.

Die Arbeit, die KI aus Code-Schreiben entfernt, verschwindet nicht. Sonar nennt das den "großen Toil-Shift": es erscheint Downstream wieder, im Verwalten von Schuld und Korrigieren von KI-Output. Automatisieren Sie die wiederkehrenden Teile dieses Triages, kennzeichnen Sie Stale PRs, Route Review-Anfragen, folgen Sie up, setzt Senior-Zeit frei für den Teil, der wirklich einen Menschen braucht: zu entscheiden, ob das Team versteht was es gerade deployed.

Messen Sie Trajektorie, nicht Zufriedenheit. Ein Team, das sich über KI gut fühlt und die eigene Architektur in sechs Monaten nicht erklären kann, hat keine Zeit gespeichert. Es hat sie geliehen, zu einem Rate den niemand aufgeschrieben hat.