Technische Schulden waren schon immer der Preis dafür, jetzt den schnelleren Weg zu nehmen und später dafür zu zahlen. KI-gestütztes Coding ändert an dieser Definition nichts. Es ändert nur das Tempo.
Wenn ein Tool in Sekunden eine plausible Implementierung ausspuckt, ist die Versuchung groß, sie einfach zu übernehmen und weiterzumachen. Der Code läuft, die Tests sind grün, das Feature geht raus. Was Sie in diesem Moment nicht sehen: ob das Modell eine vorhandene Abstraktion wiederverwendet oder eine neue erfunden hat, ob es sich an Ihre Muster gehalten oder ein fremdes eingeschleppt hat, ob es Ihr konkretes Problem gelöst hat oder eine generische Variante davon, die halbwegs passt.
Wir arbeiten mit Teams, die seit ein, zwei Jahren stark auf KI setzen, und das Bild ist immer dasselbe. Sie haben keinen schlechteren Code geliefert. Sie haben mehr Code geliefert, davon einen größeren Anteil leicht neben den Mustern, und die Wartungskosten kamen ganz leise daher: als Codebasis, die sich schwerer ändern lässt, als es Alter und Umfang erwarten ließen.
Warum KI-Schulden anders aussehen
Menschengemachte technische Schulden machen sich meist selbst bemerkbar. Der TODO-Kommentar, der bewusste Hack, das „das machen wir später sauber“. So etwas können Sie greppen. KI-generierte Schulden sind leiser, weil sie sauber formatiert und plausibel sind und weil der Autor sie oft gar nicht bewusst geschrieben, sondern nur abgenickt hat.
Drei Formen treten am häufigsten auf.
| Art der Schuld | Wie sie aussieht | Warum KI sie begünstigt |
|---|---|---|
| Duplizierung | Dieselbe Logik an mehreren Stellen neu implementiert | Das Modell generiert neu, statt Vorhandenes zu finden und wiederzuverwenden |
| Muster-Drift | Neue Abstraktionen und Idiome, die nicht zur Codebasis passen | Das Modell bringt seine eigenen Konventionen mit, nicht Ihre |
| Plausibel, aber falsch | Code, der den Happy Path bedient und Randfälle still und leise vermurkst | Das Modell optimiert auf Ergebnisse, die richtig aussehen |
Keine davon fällt in einem grünen Testlauf auf. Alle drei verteuern die nächste Änderung.
Speziell das Problem mit der Duplizierung
Von den dreien türmt sich Duplizierung am schnellsten auf, denn sie wächst genau mit dem Maß, in dem Sie das Tool nutzen. Jedes Mal, wenn ein Modell vorhandene Logik neu generiert, statt sie wiederzuverwenden, handeln Sie sich eine zweite, dritte, vierte Kopie ein, und die müssen Sie künftig alle finden und gemeinsam anpassen, sobald sich das Verhalten ändert.
Ansetzen müssen Sie vorne. Ein Reviewer, oder ein Tool, der fragt „Gibt es das in der Codebasis nicht längst?“, fängt Duplizierung genau dort ab, wo sie entsteht, und dann ist das Entfernen billig. Fällt sie erst ein halbes Jahr später auf, wird ein Ausgrabungsprojekt daraus.
Machen Sie die Schulden sichtbar, bevor Sie sie steuern
Schulden, die Sie nicht sehen, können Sie nicht steuern, und der grüne Build verdeckt sie. Die Teams, die hier vorne bleiben, machen KI-generierte Schulden überhaupt erst sichtbar und entscheiden dann bewusst, wie sie damit umgehen.
Ein paar Praktiken, die sich bewähren:
- Behandeln Sie Duplizierung als Kennzahl, nicht als Bauchgefühl. Steigt die Duplizierung nach der KI-Einführung, ist das ein Frühwarnsignal dafür, dass das Review neu generierten Code durchwinkt.
- Markieren Sie neue Abhängigkeiten und Muster im Review. Eine Änderung, die eine Abstraktion einführt, die es in der Codebasis bisher nicht gab, sollte eine bewusste Entscheidung sein, kein Nebenprodukt davon, dass jemand einen Vorschlag angenommen hat.
- Achten Sie darauf, wie schwer Änderungen fallen, nicht nur darauf, wie viele es sind. Wenn neue Features schnell rausgehen, das Anpassen bestehender aber immer zäher wird, dann ist genau diese Schere die Schuld, die sich zeigt.
Das hängt eng damit zusammen, wie wir über KI-Code-Review denken: Die Freigabe im Review ist die Stelle, an der der Großteil dieser Schulden entweder abgefangen oder durchgelassen wird, und bei steigendem Volumen ist sie die Kontrolle, die entscheidet, welches von beidem geschieht.
Bewerten Sie sie, statt sie nur zu beklagen
Nicht jede Schuld ist es wert, getilgt zu werden. Jede Unsauberkeit als dringend zu behandeln, ist selbst eine Form von Verschwendung. Die Kunst besteht darin, Schulden nach den Kosten zu bewerten, die sie der künftigen Arbeit aufbürden, und gezielt die teure Sorte zu tilgen.
| Wo die Schuld sitzt | Laufende Kosten | Maßnahme |
|---|---|---|
| Stabiler, selten angefasster Code | Niedrig, womöglich zahlen Sie die Zinsen nie | Liegen lassen, vermerken |
| Aktiv weiterentwickelter Code | Hoch, Sie zahlen in jedem Sprint | Bewusst tilgen |
| Hochrisiko-Pfade: Auth, Zahlungen, Daten | Gravierend, ein Fehler wird teuer | Sofort tilgen, die Schuld gar nicht erst eingehen |
Schulden in Code, den Sie nie wieder anfassen, bleiben theoretisch. Schulden in dem Code, den Sie jede Woche ändern, sind eine Steuer auf jede künftige Änderung. Stecken Sie Ihr Aufräum-Budget dorthin, wo die Zinsen tatsächlich fällig werden.
Vorbeugen ist besser als reparieren
Am günstigsten kommen Sie mit den Schulden weg, die Sie gar nicht erst eingehen. Vorbeugen setzt vor dem Review an, nämlich dabei, wie die Änderung überhaupt entsteht.
- Bitten Sie Ihre Leute, erst nach Vorhandenem zu schauen, bevor sie neu generieren, und eine neue Abstraktion genauso zu begründen, wie sie eine neue Abhängigkeit begründen würden.
- Halten Sie die Muster der Codebasis dokumentiert und griffbereit, damit sich sowohl das Modell als auch der Autor daran orientieren können.
- Behandeln Sie „die Tests sind grün“ als notwendige, nicht als hinreichende Bedingung, besonders dann, wenn auch die Tests von der KI stammen und vielleicht nur bestätigen, dass der Code tut, was er nun einmal tut.
Ein Team, das Schulden schon beim Schreiben verhindert, muss sie später viel seltener wieder ausgraben. Der Hebel ist riesig und kostet fast nichts, sobald es zur Gewohnheit geworden ist.
Unsere Sicht
KI-gestütztes Coding erfindet keine neue Kategorie technischer Schulden. Es beschleunigt die altbekannten (Duplizierung, Muster-Drift, plausibel-aber-falscher Code) und verpackt sie in saubere Formatierung, die sie schwerer erkennbar macht, bis die Wartungsrechnung ins Haus flattert.
Die Teams, die vorne bleiben, tun drei Dinge. Sie machen die Schulden sichtbar, damit ein grüner Build keine wachsenden Wartungskosten verdeckt. Sie bewerten sie danach, wo sie sitzen: Sie tilgen die Schulden in Code, den sie aktiv ändern, und in den Hochrisiko-Pfaden, und lassen die theoretischen Schulden in Ruhe. Und sie beugen mehr vor, als sie reparieren, indem sie Wiederverwendung und Musterkonformität wieder in den Moment verlagern, in dem der Code entsteht.
Schnellere Code-Generierung ist nur dann ein Gewinn, wenn die Codebasis änderbar bleibt. Teams, die das vergessen, liefern ein Jahr lang schnell und wundern sich dann, warum auf einmal alles länger dauert als früher.
Quellen
- DORA,
Accelerate State of DevOps, zu Wartbarkeit und Delivery-Performance, abgerufen am 2026-06-10 - Google Engineering Practices,
Code Review Developer Guide, abgerufen am 2026-06-10 - Martin Fowler,
Technical Debt Quadrant, abgerufen am 2026-06-10
Häufige Fragen
- Warum entstehen durch KI-gestütztes Coding technische Schulden, obwohl der Code sauber wirkt und die Tests grün sind?
- KI-Modelle optimieren auf Ausgaben, die richtig aussehen, nicht auf Ausgaben, die zur eigenen Codebasis passen. Das Ergebnis ist sauber formatierter Code, der still und leise Duplizierungen, Muster-Drift oder schlecht behandelte Randfälle einschleppt — nichts davon fällt in einem grünen Testlauf auf. Genau weil die üblichen Hinweise wie TODO-Kommentare oder bewusste Hacks fehlen, dauert es länger, bis die Schulden auffallen.
- Wann lohnt es sich, KI-generierte technische Schulden aktiv zu tilgen, und wann nicht?
- Schulden in stabilem, selten angefasstem Code bleiben theoretisch — die Zinsen werden womöglich nie fällig, also liegen lassen und vermerken. Schulden in aktiv weiterentwickeltem Code sind dagegen eine Steuer auf jeden Sprint und sollten bewusst abgebaut werden. In Hochrisiko-Bereichen wie Authentifizierung, Zahlungsabwicklung oder Datenhaltung sollten solche Schulden gar nicht erst eingegangen werden.
- Wie erkennt ein Engineering-Team, dass KI-generierte technische Schulden bereits die Produktivität bremsen?
- Das Warnsignal ist die Schere zwischen Liefergeschwindigkeit und Änderungsaufwand: Neue Features gehen schnell raus, aber das Anpassen bestehender Funktionen wird zunehmend zäher. Steigende Duplizierung nach der KI-Einführung ist ein weiterer Frühindikator dafür, dass im Review neu generierter Code durchgewunken wird, statt auf bereits vorhandene Lösungen zu verweisen.
- Welche Maßnahmen beugen KI-generierten technischen Schulden am wirksamsten vor?
- Der wirksamste Hebel sitzt vor dem Review, direkt beim Schreiben des Codes. Entwicklerinnen und Entwickler sollten erst prüfen, ob Logik bereits existiert, bevor sie neu generiert wird, und neue Abstraktionen genauso begründen müssen wie neue Abhängigkeiten. Dokumentierte, griffbereite Codebase-Muster helfen sowohl dem Modell als auch dem Autor, sich daran zu orientieren — der Aufwand amortisiert sich schnell, sobald es zur Gewohnheit geworden ist.
