Der KI-Code, den niemand versteht, häuft sich. Die Rechnung kommt 2028.

Ich habe letzte Woche ein Feature ausgeliefert, das mich vierzig Minuten gekostet hat. Die KI hat das meiste geschrieben. Tests bestanden. Code Review sah sauber aus. Kunde war zufrieden.

Dann habe ich versucht, einem Kollegen zu erklären, was der Code eigentlich macht. Ich konnte es nicht. Nicht vollständig. Ich verstand die Absicht, ich verstand die Ein- und Ausgaben, aber die Implementierungsdetails in der Mitte? Die hatte ich auf Vertrauensbasis akzeptiert.

Das ist okay für ein Feature. Aber multiplizier das mit jedem Entwickler, jedem Team, jedem Unternehmen, das gerade dasselbe tut, und du siehst ein Problem, über das niemand im Quartalsmeeting spricht.

Die Zahlen, die dich nervös machen sollten

41% des gesamten neuen kommerziellen Codes wird jetzt von KI generiert. Diese Zahl stammt aus mehreren Branchenberichten, und sie steigt rasant.

GitClear hat 211 Millionen geänderte Codezeilen von 2020 bis 2024 analysiert. Was sie fanden, sollte jeden beunruhigen, der Software beruflich ausliefert. Code Churn stieg um 39%. Das bedeutet, Code wird geschrieben und innerhalb von zwei Wochen mit fast doppelter Rate neu geschrieben als vor den KI-Tools. Code-Duplikationsblöcke stiegen um das 8-fache. Refactoring-Aktivität sank um 60%.

Lies den letzten Punkt nochmal. Entwickler schreiben mehr Code, duplizieren mehr Code und räumen weniger auf. Das ist kein Produktivitätsgewinn. Das ist ein Chaos, das sich im Dunkeln aufbaut.

Die Stack Overflow Umfrage 2026 ergab, dass 76% der Entwickler, die KI-Tools nutzen, Code generieren, den sie nicht vollständig verstehen. Und 66% sagen, sie verbringen mehr Zeit damit, "fast richtige" KI-Ausgaben zu reparieren als erwartet. Ich habe darüber geschrieben, wie KI-Coding-Tools meine eigenen Fähigkeiten verkümmern lassen, und ich bin jemand, der die Grundlagen über Jahre aufgebaut hat. Die Entwickler, die gerade ihre Karriere starten, haben dieses Fundament nicht.

Forrester prognostiziert, dass 75% der Tech-Führungskräfte bis Ende 2026 mit moderaten bis schweren technischen Schulden konfrontiert sein werden. Nicht vielleicht. Werden.

Warum KI-Code anders verrottet als menschlicher Code

Traditionelle technische Schulden kommen mit einer Papierspur. Jemand hat den Code geschrieben. Jemand erinnert sich warum. Jemand kann den Kompromiss erklären, den er um 2 Uhr morgens gemacht hat, um eine Deadline zu schaffen. Es sind Schulden, aber Schulden mit einem Autor.

KI-generierter Code ist Schulden ohne Urheberschaft.

Es gibt kein institutionelles Gedächtnis. Niemand saß in einem Meeting und entschied "wir schneiden hier die Ecke ab wegen X." Die KI hat einfach etwas produziert, das funktioniert hat, der Entwickler hat es akzeptiert, und alle sind weitergezogen. Wenn es sechs Monate später bricht, weiß niemand, warum es so geschrieben wurde. Weil es nicht "so geschrieben" wurde. Es wurde generiert.

Und dann ist da noch die andere Sache. KI behandelt jeden Prompt als separate Aufgabe. Sie schaut sich deine Codebasis nicht an und denkt "oh, da gibt es schon eine Utility-Funktion, die das macht." Sie schreibt eine neue. Jedes Mal. Deshalb ist die Duplikation um das 8-fache gestiegen. Die KI ist nicht faul. Sie hat keinen Kontext.

Wie ich bereits geschrieben habe: Claude ist großartig darin, Software zu bauen, aber auch großartig darin, sie kaputt zu machen. Der Code sieht richtig aus. Er besteht Tests. Er folgt Patterns. Aber es ist das, was Sonar "Code Smells" nennt: subtile Probleme, die keinen Alarm auslösen, sich aber über Zeit aufbauen. Über 90% der Probleme, die sie in KI-generiertem Code finden, fallen in diese Kategorie. Keine offensichtlichen Bugs. Stille Fäulnis.

Die 18-Monats-Wand

Ich sehe ein Muster bei Kundenprojekten, und die Forschung bestätigt es.

Monate 1 bis 3: Euphorie. Das Team liefert mit 2x oder 3x der vorherigen Geschwindigkeit. Alle fühlen sich wie Genies. Management ist begeistert. Das KI-Abo zahlt sich zehnfach aus.

Monate 4 bis 9: Plateau. Neue Features stoßen auf unerwartete Weise mit bestehendem KI-generiertem Code zusammen. Integration dauert länger. Debugging wird schwieriger, weil niemand den Code richtig versteht, den man vor drei Monaten ausgeliefert hat.

Monate 10 bis 15: Rückgang. Mehr Zeit wird mit Debugging als mit Bauen verbracht. Das Team fängt an, bestimmte Teile der Codebasis zu meiden, weil sie fragil sind und niemand sie anfassen will. "Ändere diese Datei nicht, sie funktioniert, aber wir wissen nicht genau warum."

Monate 16 bis 18: Die Wand. Auslieferung stockt. Neue Features erfordern erst das Umschreiben alter Features. Die Geschwindigkeitsgewinne aus den Monaten 1 bis 3 sind von den Wartungskosten aufgefressen worden. Im zweiten Jahr erreichen diese Kosten das 4-fache der traditionell geschriebenen Code-Wartung.

Die Kunden, die Ende 2024 und Anfang 2025 voll auf KI-Code-Generierung gesetzt haben? Einige von ihnen rufen mich jetzt an. Nicht um neue Features zu bauen. Sondern um herauszufinden, was der Code, den sie schon ausgeliefert haben, eigentlich macht.

Vibe Coding hat die Bombe gebaut. 2028 zündet sie.

Vibe Coding ist der Punkt, an dem das Problem von besorgniserregend zu wirklich gefährlich wird.

Für alle, die den Begriff nicht kennen: Vibe Coding ist, wenn du in natürlicher Sprache beschreibst, was du willst, und die KI ganze Anwendungen generieren lässt, mit minimalem menschlichem Review. Du promptest, du akzeptierst, du lieferst aus. Es fühlt sich produktiv an. Es fühlt sich nach Zukunft an. Es fühlt sich an wie wenn jetzt alle eine App bauen, weil KI es möglich gemacht hat.

Die Zahlen sind brutal. Testabdeckung bei Vibe-Coding-Projekten liegt im Durchschnitt bei 12%. Traditionelle Codebases? 68%. Das ist keine Lücke. Das ist ein Abgrund. 45% der Vibe-Coding-Projekte enthalten Sicherheitslücken. Die Architektur wurde nicht entworfen. Sie ist zufällig aus einer Serie von Prompts entstanden.

Ich habe über den Sicherheits-Alptraum geschrieben, den Vibe Coding verursacht. Aber der Sicherheitsaspekt ist fast zweitrangig gegenüber dem Wartungsaspekt. Sicherheitslücken werden zumindest gefunden und gepatcht. Technische Schulden sitzen einfach da und wachsen.

Eine Beam-Studie prognostiziert, dass 40% der hauptsächlich KI-codierten Projekte bis 2028 eingestellt oder grundlegend überarbeitet werden müssen. Nicht weil die KI offensichtlich schlechten Code geschrieben hat. Sondern weil das angehäufte Gewicht von Code, den niemand versteht, irgendwann unter seiner eigenen Komplexität zusammenbricht.

2024 war das erste Jahr, in dem die Einführung von wiederholtem Code die Refactoring-Aktivität übertraf, laut GitClear. Diese Trendlinie flacht nicht ab. Sie wird steiler.

Das Junior-Developer-Loch macht alles schlimmer

Hier verbindet sich das mit etwas, worüber ich kürzlich geschrieben habe. Junior Developer verschwinden. Einstiegs-Stellenangebote sind seit 2022 um 67% gesunken. Die Pipeline, die erfahrene Ingenieure hervorbringt, bricht zusammen.

Kombiniere das jetzt mit dem technischen Schulden-Problem. Wer reviewt KI-generierten Code? Wer erkennt die subtilen Probleme? Wer debuggt die Systeme, die niemand vollständig versteht? Senior Engineers. Und wir produzieren jedes Jahr weniger von ihnen, weil wir die Junior-Stellen gestrichen haben, die die Pipeline speisen.

Googles DORA-Report fand etwas Faszinierendes. KI-Tools beschleunigten Code Reviews. Super. Aber sie verringerten auch die Delivery-Stabilität um 7,2%. Schnellere Reviews, weniger stabile Ergebnisse. Die Geschwindigkeit ist real. Der Qualitäts-Kompromiss auch.

Die Ironie ist erstickend. Wir haben die Einstiegspositionen automatisiert, die Menschen beigebracht haben, Code sorgfältig zu lesen, Systeme tiefgreifend zu verstehen, Probleme früh zu erkennen. Und jetzt generieren wir mehr Code als je zuvor, der genau diese Art von sorgfältigem menschlichen Review braucht.

Was ich tatsächlich dagegen tue (und was nicht)

Ich werde dir keine "10 Schritte gegen KI-technische Schulden" Checkliste geben. Ich habe keine zehn Schritte. Ich finde das genauso raus wie alle anderen.

Was ich tue: Ich lese jede Zeile, die die KI generiert, bevor ich sie committe. Jede Zeile. Es dauert länger. Es kostet mich einen Teil des Geschwindigkeitsvorteils. Aber ich weiß, was meine Codebasis tut. Wenn um 23 Uhr etwas kaputtgeht, kann ich es finden.

Ich nutze Spec-Driven Development, um der KI architektonischen Kontext zu geben, bevor sie etwas schreibt. Statt "bau mir ein Login-System" sage ich "hier ist die Auth-Architektur, hier ist die Verbindung zum bestehenden Session-Management, hier sind die Constraints." Das Ergebnis ist dramatisch besser, wenn die KI weiß, worin sie arbeitet.

Aber hier ist der ehrliche Teil: Ich liefere trotzdem manchmal Code aus, den ich nicht vollständig verstehe. Wenn die Deadline eng ist und die Tests bestehen und die Funktionalität funktioniert, akzeptiere ich die KI-Implementierung und mache weiter. Ich weiß, dass es den Haufen vergrößert. Ich tue es trotzdem. Die Anreizstruktur belohnt schnelles Ausliefern, nicht sauberes Ausliefern. Ich stehe nicht darüber.

Niemand hat eine saubere Antwort

Die Branche generiert Code schneller, als Menschen ihn prüfen können. Das wird sich nicht ändern. KI-Tools werden besser, nicht weniger. Der Code häuft sich an.

Vielleicht ist 2028 nicht das Jahr, in dem die Rechnung fällig wird. Vielleicht ist es 2029. Vielleicht schaffen es manche Teams, sorgfältig genug zu sein, um es ganz zu vermeiden. Vielleicht wird KI gut genug darin, ihren eigenen Output zu verstehen, sodass sie die Wartung selbst übernehmen kann.

Aber gerade, in 2026, sehe ich Folgendes: Unternehmen liefern schneller als je zuvor, verstehen weniger von dem was sie liefern als je zuvor, und stellen weniger Leute ein, die diese Lücke schließen könnten, als je zuvor. Das ist Zinseszins, der gegen dich arbeitet.

Das ist keine Weltuntergangsprognose. Es ist einfach Mathematik. Technische Schulden wachsen exponentiell. KI beschleunigt die Rate, mit der sie sich ansammeln. Je weniger Menschen den Code verstehen, desto schwieriger wird es, die Schulden abzubauen.

Wenn dein Unternehmen auf Software angewiesen ist, die länger als zwei Jahre halten soll, fang an, unbequeme Fragen zu stellen: Wie viel deiner Codebasis versteht dein Team wirklich? Die Antwort könnte dich überraschen.

Willst du herausfinden, wie es unter der Haube deiner Codebasis wirklich aussieht? Lass uns das gemeinsam klären.