Code ist eine Verbindlichkeit. KI macht das schlimmer.
Warum weniger Code fast immer die bessere Architektur ist — und KI das Problem verschärft.
Jede Zeile Code, die geschrieben wird, egal ob von einem Menschen oder einer KI, erzeugt Wartungsaufwand, Fehlerquellen und technische Schulden. Mehr Code ist kein Fortschritt. Weniger Code ist es meistens.
Das Prinzip „Code is a liability" kursiert seit Jahren in der Software-Industrie, aber es hat gerade eine neue Dringlichkeit bekommen. Mit KI-Agenten wie Claude Code oder Cursor ist die Produktionsgeschwindigkeit von Software explodiert, weil Aufgaben, die früher einen halben Tag gebraucht haben, jetzt in zwanzig Minuten stehen. Das klingt nach Fortschritt. Ist es auch, wenn jemand mitdenkt.
Das Problem zeigt sich im Detail. KI-Agenten lösen Bugs, indem sie Code hinzufügen. Ein Edge Case? Noch eine if-Abfrage. Eine Race Condition? Noch ein Wrapper. Der Fix funktioniert, aber niemand hat gefragt, ob das Problem woanders liegt, ob eine saubere Abstraktion drei dieser Patches überflüssig gemacht hätte oder ob das Feature überhaupt in diesem Layer sitzen sollte.
Daniel beschreibt in seinem LinkedIn-Post einen Effekt, den er täglich beobachtet: Je mehr Software von KI produziert wird, desto sicherer wird er in die Fähigkeiten, die man sich über Jahre mit Handarbeit und Intuition aufgebaut hat. Das liegt nicht daran, dass KI schlecht wäre. Es liegt daran, dass sie kein Systemgedächtnis hat. Sie kennt den Kompromiss von vor drei Jahren nicht, sie kennt die Architekturentscheidung nicht, die damals bewusst getroffen wurde, und sie kann nicht einschätzen, warum ein bestimmter Workaround existiert.
KI macht Entwickler schneller. Änderungen formulieren, übergeben, umsetzen lassen. Boilerplate generieren, wo früher //TODOs standen. Code Reviews beschleunigen. Das ist real. Aber wenn jemand sagt, er entwickle Software, ohne eine einzige Zeile Code zu lesen, dann fehlt eine Grundvoraussetzung, weil Lesen die eigentliche Kernkompetenz ist, die gerade unterschätzt wird.
Wer Code nicht liest, kann ihn nicht beurteilen. Wer ihn nicht beurteilen kann, wird ihn nicht löschen. Und wer ihn nicht löscht, häuft Schulden an (die irgendwann jemand bezahlen muss).
Die Demoszene hat das vor 30 Jahren vorgemacht: In 4 Kilobyte passt eine ganze Welt, wenn man versteht, welche Teile nie nötig waren. Die Frage ist also nicht nur, wann du zuletzt Code reduziert hast, sondern wann du zuletzt eine Architektur gewählt hast, die weniger davon brauchte.
Stimmen aus der Diskussion
Code entfernen sei Refactoring, sagt sie, aber die eigentliche Frage laute: Warum wurde er überhaupt geschrieben? npm installiert 1.400 Pakete, weil JavaScript keine Standardbibliothek hat. Microservices brauchen einen Service Mesh, weil die Verteilung Probleme erzeugt, die ein Monolith nie hatte. Das seien keine Code-Probleme, sondern Architektur-Entscheidungen. Gleichzeitig sieht sie KI differenzierter als viele in der Diskussion: Wer fundiert im Pair mit KI entwickle und das professionell begleite, produziere bessere Software in kürzerer Zeit. Aber das setze voraus, dass man vorher schon ein guter Entwickler war, weil KI keine Erfahrung ersetze, sondern sie multipliziere.
KI sei wie ein Praktikant mit zu viel Kaffee. Sehr motiviert, aber sie baut lieber vier neue if-Abfragen, statt die eigentliche Ursache zu finden. Seine Frage an die Community: Gibt es feste Momente im Prozess, in denen bewusst nach Löschkandidaten gesucht wird, oder passiert das nur nebenbei im Review?
Jemand löst heute mit AI-Slop alle offenen Tickets und kassiert den Bonus. In zwei Monaten fliegt dem Team alles um die Ohren. Code-Sloping ohne menschliche Evaluation werde die technischen Schulden so hoch treiben, dass irgendwann über Schadenersatz geredet werden müsse.
Takeaway
KI macht das Schreiben von Code billig. Das Lesen, Verstehen und Löschen von Code wird dadurch teurer und wichtiger. Wer heute den schnellsten Output feiert, bezahlt morgen die Rechnung, weil die beste Codebase die ist, in der jede Zeile ihren Platz rechtfertigen kann.