Ich bin über die Analyse zu Claude Code gestolpert — und mein erster Gedanke war nicht: „Was für ein KI-Problem.“ Mein erster Gedanke war eher: Genau so sieht es aus, wenn menschliche Schwächen plötzlich in Maschinen-Geschwindigkeit skaliert werden.

In der Analyse tauchen ein paar Beispiele auf, die genau das sehr gut greifbar machen: eine einzelne Funktion mit 3.167 Zeilen, 486 Verzweigungspunkten und 12 Ebenen Verschachtelung. Dazu extrem große Dateien wie QueryEngine.ts mit 46.000 Zeilen, Tool.ts mit 29.000 und commands.ts mit 25.000 Zeilen. Und dann noch ein dokumentierter Fehler, der laut Kommentar rund 250.000 API-Calls pro Tag verschwendete — obwohl das Problem bereits bekannt war.

Das klingt erstmal nach einem KI-Problem.

Für mich ist es aber vor allem ein Menschenproblem.

KI erfindet diese Fehler nicht. Sie beschleunigt sie.

Die KI hat die riesige Methode nicht „erfunden“, weil sie böse, faul oder dumm wäre.

Sie hat vermutlich einfach das getan, was man ihr erlaubt hat:
Dinge zusammenziehen.
Schnell lösen.
Nicht zu lange aufhalten.
Weiter zum nächsten Problem.

Und genau da wird es menschlich.

Denn diese Versuchung gab es in Softwareprojekten schon immer. Hauptsache, es läuft erstmal. Hauptsache, der Bug ist weg. Hauptsache, das Ticket ist zu. Nur musste man solchen Ballast früher noch mühsam selbst produzieren.

Heute macht das die KI in Sekunden.

Die eigentliche Gefahr ist also nicht nur, dass KI Fehler macht. Die eigentliche Gefahr ist, dass sie unsere alten schlechten Gewohnheiten massiv beschleunigt.

Große Dateien sind nicht nur hässlich. Sie machen KI teurer.

Was mich an solchen Beispielen am meisten interessiert, ist gar nicht der Stil.

Mich interessiert die Folgerechnung.

Denn eine 3.167-Zeilen-Methode ist nicht nur unschön. Sie ist für die weitere Arbeit ein Problem. Vor allem mit KI.

Je größer Methoden, Dateien und Zuständigkeiten werden, desto mehr irrelevanten Kontext muss die KI bei jeder kleinen Änderung wieder mitlesen. Dann steckt im Kontext nicht nur das aktuelle Problem, sondern auch alter Ballast: Sonderfälle, historische Umwege, halbfertige Entscheidungen, provisorische Fixes und Code, der mit dem eigentlichen Task gerade gar nichts zu tun hat.

Genau das ist für mich Context Pollution.

Viel Kontext.
Aber wenig Relevanz.

Und genau dann beginnt etwas, das ich in den letzten Monaten selbst immer wieder beobachtet habe: Die KI wirkt plötzlich vergesslich. Nicht weil sie „nichts kann“. Sondern weil sie sich durch zu viel irrelevantes Material wühlt.

Dann recherchiert sie bekannte Details erneut.
Dann entdeckt sie Probleme noch einmal neu.
Dann schlägt sie Dinge vor, die eigentlich längst geklärt waren.
Dann wird aus Geschwindigkeit Reibung.

Und diese Reibung kostet.

Nicht nur Nerven.
Sondern auch Tokens, Zeit und Fokus.

Fehlende Dokumentation macht die Sache doppelt teuer

Ein zweites Muster sehe ich genauso oft:

Die KI baut etwas um. Es funktioniert. Alle gehen weiter.

Aber warum es genau so gebaut wurde, steht nirgends.

Keine saubere Beschreibung.
Keine dokumentierte Entscheidung.
Keine kurze Notiz, welche Annahmen gelten.
Keine klare Abgrenzung, wo die Lösung aufhört.

Das spart im ersten Moment ein paar Minuten.

Später kostet es deutlich mehr.

Denn bei der nächsten Änderung muss wieder gelesen werden. Wieder interpretiert werden. Wieder geraten werden. Wieder recherchiert werden. Und wenn die KI in genau diesen Bereich zurückkehrt, fehlt ihr derselbe Zusammenhang erneut.

Dann bezahlt man dieselbe Abkürzung mehrfach.

Die Beispiele aus der Claude-Code-Analyse passen genau in dieses Muster. Dort war laut Analyse ein Problem sogar bereits im Code kommentiert — inklusive der Größenordnung des verschwendeten Verbrauchs — und blieb trotzdem im Produkt. Das ist für mich weniger ein Zeichen von „schlechter KI“ als von fehlender Disziplin im Umgang mit dem, was die KI produziert.

Schnell und billig gewinnt oft gegen klein und klar

Ein Detail aus der Analyse fand ich dabei fast symbolischer als die langen Dateien: Nutzerfrust wurde dort demnach mit einer Regex auf Worte wie Schimpfwörter geprüft. Das ist auf den ersten Blick fast lustig. Auf den zweiten Blick zeigt es aber sehr gut die eigentliche Logik dahinter: nicht unbedingt sauber, nicht unbedingt robust, sondern erstmal schnell, billig und direkt.

Und genau so schreibt KI eben oft, wenn man sie nicht aktiv führt.

Nicht automatisch klein.
Nicht automatisch wartbar.
Nicht automatisch dokumentiert.
Nicht automatisch mit klaren Grenzen.

Sondern häufig so, wie wir Menschen unter Druck selbst auch bauen würden:
erstmal pragmatisch,
erstmal funktional,
erstmal schnell.

Der Unterschied ist nur:
Die KI kann davon viel mehr in viel kürzerer Zeit produzieren.

Genau das habe ich selbst in den letzten Monaten gesehen

Deshalb hat mich die Analyse auch nicht schockiert, sondern eher bestätigt.

Ich habe in den letzten Monaten immer wieder gesehen, wie stark KI beim Entwickeln helfen kann. Wirklich stark. Teilweise absurd stark.

Aber ich habe genauso gesehen, wie schnell das kippt, wenn man sie nicht sauber einhegt.

Dann werden Methoden zu groß.
Dateien zu dick.
Entscheidungen zu schlecht dokumentiert.
Kontextfenster mit Zeug gefüllt, das für das aktuelle Problem gar nicht wichtig ist.

Und plötzlich ist die KI nicht mehr einfach nur ein Beschleuniger.

Dann wird sie zu einem Verstärker von technischem Ballast.

Die Entwicklung fühlt sich zuerst schneller an.
Und wird dann Schritt für Schritt teurer.

Fazit

Das aktuell größte Problem von KI generierten Code ist für mich deshalb kein rein technisches.

Es ist ein sehr menschliches.

KI macht nicht automatisch schlechte Software.

Aber sie macht es sehr leicht, kurzfristige Bequemlichkeit in großen Mengen in Code zu verwandeln.

Und wenn wir ihr nicht sehr klar sagen, dass sie klein, klar, getrennt und dokumentiert bauen soll, dann schreibt sie oft genau den Code, der heute schnell hilft — und morgen jede weitere Änderung teurer und zeitaufwendiger macht.

Nicht weil die KI das so will.

Sondern weil wir Menschen ihr genau dafür zu oft die Bahn freimachen.