Technische Schulden bei KI-gestützter Entwicklung vermeiden

Ein KI-Assistent macht eine Codebasis nicht automatisch schlechter – er macht sie schneller größer. Genau darin liegt das Risiko: Ohne Review-Disziplin und regelmäßiges Aufräumen wächst technische Schuld unbemerkt mit, weil jede einzelne Änderung für sich genommen plausibel aussieht. Das Muster, das ich in Projekten immer wieder sehe: Ein Team nutzt einen Coding-Assistenten für schnelle Änderungen, das Tempo steigt spürbar – und nach einigen Monaten dauert jede neue Funktion länger als vorher, weil niemand mehr genau weiß, welche der drei ähnlichen Hilfsfunktionen gerade die aktuelle ist.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die interne Tools, MVPs oder Web-Apps mit KI-Unterstützung entwickeln oder entwickeln lassen – nicht nur an Entwickler:innen. Denn die Entscheidung, wie viel Prüfaufwand ein Team sich leistet, ist am Ende eine Ressourcen- und Priorisierungsfrage, keine rein technische.

Begriffe und Abgrenzung

Technische Schulden ist eine Metapher: Jede schnelle, nicht ganz saubere Lösung ist wie ein Kredit – sie beschleunigt heute, kostet aber morgen Zinsen in Form von höherem Wartungsaufwand. Schulden sind nicht per se schlecht; problematisch wird es, wenn sie unbewusst entstehen und nie zurückgezahlt werden.

Wichtig ist die Abgrenzung zu zwei benachbarten Begriffen:

• Ein Bug ist ein konkreter Fehler mit falschem Verhalten. Technische Schuld dagegen funktioniert oft korrekt – sie macht nur jede nächste Änderung teurer und riskanter.
• Refactoring ist die gezielte Rückzahlung: Code wird umstrukturiert, ohne das äußere Verhalten zu verändern. Refactoring ist die Gegenmaßnahme zu technischer Schuld, nicht dasselbe wie sie.

AI Coding verändert an dieser Grundlogik nichts – es verändert nur das Tempo, mit dem Schulden entstehen können, weil ein Assistent in Sekunden liefert, wofür ein Mensch vorher Minuten oder Stunden brauchte. Was AI Coding im Detail ist und wofür es sich eignet, behandelt der Cluster-Artikel zu AI Coding im Unternehmen; hier geht es um die Folgen für die Codebasis über Zeit.

Wie entstehen Schulden durch AI Coding?

Der zentrale Mechanismus ist einfach: Ein Coding-Assistent beantwortet jede Anfrage weitgehend isoliert. Er kennt zwar den sichtbaren Kontext einer Datei oder eines Projekts, hat aber kein verlässliches Gedächtnis dafür, dass drei Dateien weiter bereits eine passende Hilfsfunktion existiert. Das Ergebnis: Er schreibt lieber neu, statt zuverlässig wiederzuverwenden.

Die Zahlen dazu sind inzwischen belastbar. GitClear hat 211 Millionen veränderte Codezeilen aus Repositories unter anderem von Google, Microsoft, Meta und weiteren Unternehmen im Zeitraum Januar 2020 bis Dezember 2024 ausgewertet. Der Anteil kopierter, dupliziert eingefügter Codezeilen stieg von 8,3 % (2021) auf 12,3 % (2024) – mit einer rund vierfachen Zunahme duplizierter Code-Blöcke allein im Jahr 2024. Im selben Zeitraum sank der Anteil an Refactoring-Commits – also Änderungen, die bestehenden Code aufräumen statt neuen hinzuzufügen – von 25 % auf unter 10 %. Beide Kurven laufen in dieselbe Richtung: mehr Code wird geschrieben, weniger wird aufgeräumt.

Drei konkrete Muster, wie das in der Praxis passiert:

1. Lokale statt globale Lösungen. Ein Assistent löst die gestellte Aufgabe im vorliegenden Datei-Kontext – sauber für sich, aber ohne Blick auf ähnliche Lösungen anderswo im Projekt. Über viele kleine Änderungen hinweg entstehen so mehrere leicht unterschiedliche Varianten derselben Logik.
2. Ungeprüfte Abhängigkeiten. Modelle schlagen gelegentlich Pakete vor, die es nicht oder nicht mehr gibt, oder die veraltet und damit sicherheitstechnisch nicht mehr aktuell sind. Das BSI beschreibt dieses Risiko explizit als „fehlende Sicherheit von generiertem Code” (Risiko R6): Erzeugter Code kann bekannte oder unbekannte Sicherheitslücken enthalten oder veraltete Bibliotheken nutzen. Wird ein halluzinierter Paketname ungeprüft installiert, kann er – falls ihn Angreifende zwischenzeitlich unter genau diesem Namen veröffentlicht haben – Schadcode ins Projekt bringen.
3. Fehlende Dokumentation der Entscheidung. Ein Mensch, der eine Lösung selbst entwirft, merkt sich meist implizit, warum er sich für einen Ansatz entschieden hat. Bei generiertem Code fehlt dieser Kontext oft komplett, wenn er nicht aktiv im Review festgehalten wird – spätere Änderungen laufen dann auf Vermutungen statt auf Wissen.

Wichtig für die Einordnung: Nichts davon ist AI Coding grundsätzlich anzulasten. Es ist die Kombination aus höherem Tempo und unveränderter (oder sogar reduzierter) Review-Disziplin, die das Problem erzeugt. Ein Team, das seine Prüfprozesse an das neue Tempo anpasst, sieht diesen Effekt deutlich schwächer.

Welche Signale sind sichtbar?

Technische Schuld ist selten von einem Tag auf den anderen sichtbar – sie zeigt sich in Trends. Vier Signale lassen sich auch ohne aufwendiges Tooling beobachten:

• Steigende Duplizierung. Ähnliche oder identische Codeblöcke tauchen an mehreren Stellen auf. Viele IDEs und Linter zeigen das mit einfachen Duplicate-Code-Checks an.
• Sinkender Refactoring-Anteil. Wenn in den letzten Commits fast nur noch neue Funktionen hinzukommen und kaum noch etwas umstrukturiert wird, verschiebt sich das Verhältnis in eine ungesunde Richtung – siehe die GitClear-Zahlen oben.
• Kurzlebiger Code. Funktionen oder Module, die kurz nach dem Schreiben wieder verworfen oder komplett umgeschrieben werden, deuten darauf hin, dass Anfragen an den Assistenten zu wenig Kontext über die bestehende Architektur bekommen.
• „Das hat keiner gebaut, das war die KI.” Ein weiches, aber verlässliches Warnsignal: Wenn im Review niemand erklären kann, warum eine bestimmte Bibliothek oder ein bestimmter Ansatz gewählt wurde, fehlt die Verantwortungsübernahme, die für Wartbarkeit nötig ist.

Ergänzend gilt laut Stack-Overflow-Erhebung 2025 unter Entwickler:innen: Die KI-Nutzung ist inzwischen hoch – 84 % nutzen KI-Tools oder planen es, gegenüber 76 % im Vorjahr –, während das Vertrauen in die Genauigkeit der Ausgaben gleichzeitig gesunken ist: 46 % der Befragten trauten der Genauigkeit von KI-Ausgaben 2025 nicht, gegenüber 31 % im Jahr davor. 45 % gaben an, dass das Debuggen KI-generierten Codes zeitaufwendiger ist als erwartet. Diese Kombination aus hoher Nutzung und sinkendem Vertrauen ist selbst ein Signal: Teams merken den Mehraufwand, ohne ihn immer systematisch zu erfassen.

Welche Architekturregeln helfen?

Vier Regeln wirken in der Praxis am zuverlässigsten, weil sie an der Ursache ansetzen – ungeprüfte Wiederholung – statt nur Symptome zu behandeln:

1. Klare Modulgrenzen mit definierten Schnittstellen. Je klarer abgegrenzt ein Modul ist, desto leichter kann ein Assistent (und ein Mensch) erkennen, wo eine bestehende Funktion liegt, statt eine neue zu schreiben. Ein monolithischer Ordner ohne innere Struktur lädt zu Duplikaten geradezu ein.

2. Die „Erst suchen, dann schreiben”-Regel. Bevor eine KI-generierte Funktion übernommen wird, gehört eine kurze, aktiv durchgeführte Suche nach vorhandener Logik zum Standardvorgehen – nicht als Vorschlag, sondern als Teil des Review-Prozesses. Das lässt sich auch als feste Frage in Pull-Request-Vorlagen verankern: „Gibt es das schon?”

3. Pflichtprüfung jeder neuen Abhängigkeit. Jedes neu vorgeschlagene Paket wird vor der Übernahme auf Existenz, Aktualität und Herkunft geprüft – manuell oder automatisiert über Paketregister und Sicherheits-Scanner. Das adressiert direkt das oben beschriebene Risiko R6 des BSI.

4. Eingeschränkte Rechte für ausführende Assistenten. Wenn ein Assistent Code nicht nur vorschlägt, sondern direkt ausführt (etwa in agentenbasierten Workflows), gilt laut BSI-Gegenmaßnahme M17 das Minimalprinzip: Zugriffs- und Ausführungsrechte auf das Notwendige beschränken und kritische Aktionen an eine explizite Bestätigung koppeln. Das begrenzt nicht nur Sicherheitsrisiken, sondern verhindert auch, dass unbemerkt Strukturänderungen an mehreren Stellen gleichzeitig passieren.

Diese Regeln lassen sich in bestehende Review-Prozesse einbetten; sie erfordern kein neues Tool-Set, sondern vor allem eine bewusste Entscheidung, sie durchzusetzen. Wie ein vollständiger Prüfprozess für KI-generierten Code aussieht, behandelt der Cluster-Artikel zum KI-Code-Review im Detail.

Wie plant man Refactoring?

Der häufigste Fehler ist, Refactoring als „wenn Zeit übrig ist” zu behandeln. Bei steigendem Tempo durch AI Coding ist genau das der Moment, in dem nie Zeit übrig ist. Drei Bausteine für ein realistisches Vorgehen:

Fester Zeitanteil statt Ausnahme. Sinnvoll ist, einen festen Anteil der Entwicklungszeit für Refactoring einzuplanen und ihn wie jede andere Aufgabe in die Sprint- oder Iterationsplanung aufzunehmen – nicht als Kür, sondern als Pflichtposten. Wie hoch dieser Anteil sein sollte, hängt vom Tempo der Neuentwicklung und der beobachteten Duplizierungsrate ab; eine pauschale Zahl für alle Teams gibt es nicht.

Priorisierung nach Änderungshäufigkeit. Nicht jedes Modul verdient gleich viel Aufräumaufwand. Am wirksamsten ist Refactoring dort, wo Code am häufigsten geändert wird – hier zahlt sich Wiederverwendbarkeit am schnellsten aus. Module, die seit Monaten unverändert und stabil laufen, haben dagegen geringere Priorität, selbst wenn sie nicht elegant sind.

Refactoring-Trigger statt Kalenderdatum. Statt starr „einmal im Quartal” zu refaktorieren, hilft ein ereignisbasierter Trigger: Wenn die Duplizierungsrate in einem Modul eine beobachtete Schwelle überschreitet oder ein Modul dreimal in Folge Bugs durch inkonsistente Varianten derselben Logik verursacht, wird Refactoring priorisiert eingeplant. Das verbindet die Metriken aus dem nächsten Abschnitt direkt mit der Planung.

Welche Metriken sind sinnvoll?

Für ein KMU ohne eigenes Platform-Engineering-Team sind wenige, regelmäßig beobachtete Kennzahlen sinnvoller als ein umfangreiches Metrik-Dashboard, das niemand pflegt:

Metrik	Was sie zeigt	Praktikable Erhebung
Anteil dupliziertem/kopiertem Code	Wie stark ähnliche Logik mehrfach existiert	Duplicate-Code-Check im Linter oder in der IDE, stichprobenartig oder automatisiert pro Release
Anteil Refactoring an allen Änderungen	Ob aufgeräumt wird oder nur wächst	Commits grob nach „neue Funktion” vs. „Umstrukturierung ohne Verhaltensänderung” klassifizieren
Ungeprüfte/unbekannte Abhängigkeiten	Sicherheits- und Wartungsrisiko durch Pakete	Abgleich neuer Paketnamen gegen offizielle Register vor jedem Merge
Zeit bis erstes erfolgreiches Review	Wie viel Nacharbeit KI-Vorschläge tatsächlich brauchen	Zeitstempel zwischen erstem Vorschlag und freigegebenem Review erfassen

Eigene Metrik-Auswahl Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten – kein branchenweiter Standard, sondern eine praktikable Untermenge für KMU-Teams ohne eigenes Metrik-Tooling.

Wichtig ist weniger die absolute Höhe einer einzelnen Zahl als der Trend über mehrere Monate. Eine Duplizierungsrate von 10 % ist an sich keine Katastrophe; eine Duplizierungsrate, die von Quartal zu Quartal steigt, während der Refactoring-Anteil gleichzeitig sinkt, ist das eigentliche Warnsignal – genau das Muster, das GitClear branchenweit beobachtet hat.

Risikomatrix: Schulden-Treiber und Gegenmaßnahmen

Eine kompakte Übersicht der häufigsten Treiber technischer Schuld bei AI Coding, ihrer Erkennbarkeit und der passenden Gegenmaßnahme:

Treiber	Sichtbares Signal	Gegenmaßnahme	Aufwand
Duplizierte Logik statt Wiederverwendung	Steigende Duplizierungsrate, ähnliche Funktionen an mehreren Stellen	„Erst suchen, dann schreiben”-Regel im Review verankern	Niedrig
Halluzinierte oder veraltete Abhängigkeiten	Neue Pakete im Diff, die im Review niemand kennt	Pflichtprüfung jeder Abhängigkeit vor Merge (BSI-Risiko R6)	Niedrig bis mittel
Fehlender Architekturkontext bei Anfragen	Kurzlebiger Code, häufige Rewrites kurz nach Erstellung	Klare Modulgrenzen und Schnittstellen dokumentieren	Mittel
Zu weitreichende Rechte ausführender Assistenten	Änderungen an mehreren Stellen ohne erkennbaren Anlass	Rechte auf das Notwendige beschränken, kritische Aktionen bestätigen lassen (BSI-Maßnahme M17)	Mittel
Kein fester Refactoring-Anteil	Sinkender Anteil an Umstrukturierungs-Commits über Monate	Refactoring als festen Posten in jede Iterationsplanung aufnehmen	Mittel bis hoch (organisatorisch)
Fehlende Nachvollziehbarkeit von Entscheidungen	Niemand im Review kann Ansatz oder Bibliothekswahl begründen	Kurzbegründung als Pflichtfeld im Pull Request	Niedrig

Eigene Risikomatrix Philogic Labs. Der Aufwand bezieht sich auf die Einführung der Gegenmaßnahme in einem bestehenden KMU-Team, nicht auf die laufenden Kosten.

Umsetzung: So gehst du vor

Ein realistischer Einstieg für ein Team, das AI Coding bereits nutzt und die Kontrolle zurückgewinnen will, lässt sich in drei Schritten beschreiben:

Schritt 1 – Bestandsaufnahme. Einmalig die aktuelle Duplizierungsrate und den Refactoring-Anteil der letzten Monate ermitteln, entweder über vorhandene Linter-Reports oder eine grobe manuelle Sichtung der letzten 100 bis 200 Commits. Das dauert in der Regel wenige Stunden und liefert die Baseline, gegen die spätere Trends verglichen werden.

Schritt 2 – Regeln verankern. Die vier Architekturregeln aus dem entsprechenden Abschnitt in bestehende Review-Vorlagen und Pull-Request-Checklisten übernehmen. Das ist bewusst kein neues Tool, sondern eine Änderung an Prozessen, die ohnehin schon existieren – deshalb ist der Umsetzungsaufwand meist gering.

Schritt 3 – Refactoring-Anteil festlegen und beobachten. Einen festen Zeitanteil pro Sprint für Refactoring reservieren und die Metriken aus dem entsprechenden Abschnitt alle ein bis zwei Monate erneut prüfen. Steigt die Duplizierungsrate trotzdem weiter, ist das ein Signal, den Anteil zu erhöhen oder Prioritäten in der Priorisierung nach Änderungshäufigkeit zu verschieben.

In meiner Arbeit sehe ich am häufigsten, dass Schritt 2 übersprungen wird, weil er nach zu wenig aussieht, um wirklich zu wirken. Tatsächlich ist er der wirksamste, weil er direkt an der Stelle ansetzt, an der Schuld entsteht – im Moment der Übernahme eines Vorschlags, nicht Monate später bei einem großen Aufräumprojekt.

Risiken & Grenzen

Ein ehrlicher Blick auf die Grenzen dieses Vorgehens gehört dazu:

• Regeln lösen keine fehlende Zeit. Wenn ein Team strukturell keine Kapazität für Review und Refactoring hat, helfen auch die besten Regeln nur begrenzt – dann ist die eigentliche Entscheidung eine Priorisierungs- oder Ressourcenfrage, keine technische.
• Nicht jede Duplizierung ist ein Problem. Manchmal ist bewusst duplizierter, einfacher Code wartungsfreundlicher als eine zu früh erzwungene Abstraktion. Die Kennzahlen in diesem Artikel sind Signale, keine automatischen Fehlurteile.
• Metriken können Fehlanreize setzen. Wer den Refactoring-Anteil als harte Zielgröße vorgibt, riskiert kosmetische Umbenennungen statt echter Verbesserung. Sinnvoll sind Kennzahlen als Gesprächsgrundlage im Team, nicht als isolierte Bonus-Kriterien.
• Die zitierten Studien sind Momentaufnahmen. Die GitClear-Auswertung endet 2024, die Stack-Overflow-Erhebung stammt aus 2025; beide beschreiben Trends aus überwiegend großen Unternehmen und öffentlichen Repositories. Wie stark sich das Muster in einem konkreten KMU-Projekt zeigt, hängt von Teamgröße, Tooling und Review-Kultur ab und lässt sich nur am eigenen Repository verlässlich prüfen.

Wenn eine Codebasis bereits spürbar schwerfällig geworden ist und unklar ist, wo genau die größten Schuld-Treiber liegen, ist eine externe Architektur- oder Code-Review-Sichtung oft der schnellere Weg als monatelanges internes Aufräumen ohne Priorisierung. Unser Beratungsangebot für genau solche Situationen findest du auf der Startseite; ein kostenloses Erstgespräch klärt in kurzer Zeit, ob eine gezielte Prüfung sinnvoll ist. Wer die nötige Review-Kompetenz stattdessen intern aufbauen will, findet dazu passende Formate in unseren Schulungen.

Checkliste: Technische Schulden bei KI-gestützter Entwicklung eindämmen

1. Wir kennen unsere aktuelle Duplizierungsrate und unseren Refactoring-Anteil zumindest grob als Baseline.
2. Vor der Übernahme eines KI-Vorschlags wird aktiv geprüft, ob eine passende Funktion bereits existiert.
3. Jede neue Abhängigkeit wird vor dem Merge auf Existenz, Aktualität und Herkunft geprüft.
4. Assistenten, die Code direkt ausführen, haben nur die minimal nötigen Rechte; kritische Aktionen erfordern eine Bestätigung.
5. Modulgrenzen und Schnittstellen sind dokumentiert und für neue Anfragen an den Assistenten auffindbar.
6. Refactoring hat einen festen Zeitanteil in der Sprint- oder Iterationsplanung – keine Ausnahme „wenn Zeit ist”.
7. Pull Requests enthalten eine Kurzbegründung, warum ein bestimmter Ansatz oder eine bestimmte Bibliothek gewählt wurde.
8. Die Metriken aus diesem Artikel werden alle ein bis zwei Monate erneut geprüft, nicht nur einmalig erhoben.
9. Bei steigender Duplizierung trotz Gegenmaßnahmen ist klar, wer die Priorisierung anpasst.
10. Uns ist bewusst, dass Regeln fehlende Kapazität nicht ersetzen – Review- und Refactoring-Zeit ist eingeplant, nicht nur gewünscht.

Weitere vertiefende Themen rund um KI-gestützte Softwareentwicklung – von AI Coding im Unternehmen bis zum konkreten Code-Review-Prozess – findest du im Cluster KI-Softwareentwicklung.