Claudes 50 Funktionen implodierten. Hier ist der Grund.

Der Entwickler Shiv Bhosale startete ein ehrgeiziges siebenmonatiges Projekt und baute K10s, ein GPU-aware Kubernetes-Dashboard, vollständig mit Claude. Diese intensive „vibe coding“-Anstrengung führte zu 50 verschiedenen Funktionen, von denen jede scheinbar sauber innerhalb einer einzigen Entwicklungssitzung landete. Die schnelle Generierung einzelner Komponenten erzeugte ein berauschendes Gefühl des Fortschritts und deutete auf eine Zukunft hin, in der komplexe Anwendungen mit beispielloser Geschwindigkeit entstehen könnten.

Dieser Ansatz kultivierte die verführerische Anziehungskraft der 10x velocity, bei der sich Entwickler befähigt fühlten, neue Funktionen mit bemerkenswerter Leichtigkeit zu prototypisieren und zu implementieren. Claudes effiziente, sitzungsbasierte Ausgabe verstärkte die Wahrnehmung, dass jede Funktion ein eigenständiger Erfolg war und nur minimalen Integrationsaufwand erforderte. Dies erzeugte ein falsches Gefühl architektonischer Solidität und verdeckte zugrunde liegende Probleme mit der schieren Geschwindigkeit der Generierung.

Die Illusion zerbrach jedoch katastrophal, als Bhosale schließlich versuchte, die 50 Funktionen zu einer kohärenten Anwendung zu kombinieren. Das gesamte System implodierte und offenbarte grundlegende architektonische Inkonsistenzen: Beim Wechsel der Ansichten wurden veraltete Daten angezeigt, ehemals gefüllte Tabellen erschienen unerklärlicherweise leer, und kritische Tastenfunktionen führten je nach aktivem Bildschirm drei verschiedene, unvorhersehbare Aktionen aus. Dieser vollständige Zusammenbruch, verursacht durch einen Mangel an architektonischer Weitsicht seitens der KI, zwang Bhosale, sieben Monate Arbeit aufzugeben, die gesamte Codebasis zu archivieren und das Projekt von Grund auf neu zu starten.

Der grundlegende Fehler der KI zeigte sich schnell: Sie ist hervorragend darin, isolierte Funktionen zu generieren, aber keine kohärenten Architekturen. Jede Eingabeaufforderung fungiert als isolierte Anweisung, die völlig ahnungslos ist, was die 49 anderen Funktionen betrifft, die den Zustand innerhalb von Shiv Bhosales K10s-Projekt teilen. Claude lieferte einzelne Komponenten, aber entscheidend ist, dass es kein Verständnis dafür hatte, wie diese Teile als einheitliches System interagieren sollten.

Dieser fragmentierte Ansatz führte unweigerlich zu einer brüchigen, nicht wartbaren Codebasis. Als Bhosale versuchte, alles zusammen zu verwenden, implodierte die gesamte Struktur. Beim Wechsel der Ansichten wurden veraltete Daten angezeigt, ehemals gefüllte Tabellen erschienen leer, und eine einzige Taste führte je nach Bildschirm drei verschiedene Aktionen aus. Die einzelnen Funktionen, sauber in Isolation, funktionierten einfach nicht zusammen.

Bhosales Lösung war klar: Der Entwickler muss die Rolle des Architekten zurückerobern. Er entwarf die Systemarchitektur manuell und dokumentierte sie gründlich in einer `Claude MD`-Datei. Erst dann nutzte er Claude für die „langweiligen Aufgaben“ – die Implementierung spezifischer Funktionalitäten streng innerhalb des vordefinierten, handgeschriebenen strukturellen Bauplans. Diese Verschiebung verwandelte KI von einem autonomen Erbauer in ein leistungsstarkes, geführtes Implementierungswerkzeug.

Der Standardansatz der KI ist das Anti-Pattern des god object, bei dem die gesamte Logik in eine einzige, massive Datenstruktur gestopft wird, um den kürzesten Weg zu einer funktionierenden Funktion zu finden. Shiv Bhosales K10s-Codebasis veranschaulichte dies drastisch, mit einer einzigen Struktur, die sich über erstaunliche 1.690 Zeilen erstreckte. Dieses monolithische Objekt enthielt eine 500-zeilige `Update()`-Methode und 110 switch cases, ein klares Zeugnis seines unüberschaubaren Umfangs.

Ein solch monolithisches Design macht die Wartung unmöglich und fördert eine starke Kopplung zwischen unterschiedlichen Funktionalitäten. Eine geringfügige Änderung in einem Bereich birgt das Risiko kaskadierender Fehler im gesamten fragilen System. Bhosales Erfahrung mit veralteten Daten, leeren Tabellen und inkonsistenten Schlüsselfunktionen über verschiedene Ansichten hinweg resultierte direkt aus diesem Architekturfehler, der die Anwendung von Natur aus instabil machte.

Dies zu korrigieren erfordert explizite Anweisungen an das LLM. Entwickler müssen Claude zwingen, Belange zu trennen und die Logik in verschiedene Ansichten, Komponenten und Datenstrukturen aufzuteilen. Diese architektonische Anleitung verhindert aktiv, dass die KI standardmäßig monolithische Strukturen verwendet, und fördert eine modularere und wartbarere Codebasis. Für weitere Einblicke in Bhosales Projekt und dessen Entwicklung, erkunden Sie das K10s GitHub-Repository: shvbsle (Shiv Bhosale) / k10s - GitHub.

Die wahrgenommene „Kostenlosigkeit“ von KI-generiertem Code erweist sich als gefährlich trügerisch und führt direkt zu ungezügeltem Scope Creep. Wenn Claude scheinbar 50 Funktionen in ebenso vielen isolierten Sitzungen herbeizaubern kann, wird der Impuls, ständig mehr hinzuzufügen, unwiderstehlich. Diese hohe Geschwindigkeit, obwohl anfangs berauschend, verschleiert eine wachsende technische Schuld und lockt Entwickler in ein sich ständig erweiterndes Projekt.

Jede neue Funktion, egal wie trivial ihre Erstellung ist, führt zu erheblichen versteckten Kosten: - Langzeit-Support - umfassende Dokumentation - Umgang mit unvorhergesehenen Randfällen - Erhöhung der kognitiven Belastung für den Benutzer Bhosales K10s, mit seinen 50 zusammengefassten Funktionen, veranschaulicht diese Falle deutlich; der Geschwindigkeits-Trick verschleierte die wahre Last der unstrukturierten Ausbreitung.

Um dieser heimtückischen Ausbreitung entgegenzuwirken, müssen Entwickler klare Grenzen setzen. Shiv Bhosale definierte explizit, für wen er *nicht* entwickelte, und legte damit negative Einschränkungen fest. Er kodifizierte diese expliziten Scope-Grenzen dann direkt in der `Claude MD`-Kontextdatei, um zu verhindern, dass die KI bestehende Funktionalitäten neu aufbaut oder den Projektumfang überzieht. Diese proaktive Beschränkung stellt sicher, dass die Geschwindigkeit der KI einem präzise definierten Zweck dient, anstatt eine unüberschaubare Funktionsausbreitung zu erzeugen.

Was ist 'Vibe Coding' mit KI?

Es ist ein Stil der schnellen Entwicklung, bei dem ein Programmierer ein LLM wie Claude verwendet, um Funktionen basierend auf übergeordneten Anweisungen oder 'Vibes' zu generieren, oft ohne einen strengen, vordefinierten Architekturplan.

Warum erstellt KI 'God Objects'?

KI wählt den kürzesten Weg zu einer funktionalen Lösung. Alle Zustände und Logik in ein einziges Objekt zu stopfen, ist oft der einfachste Weg, eine Anforderung für eine neue Funktion zu erfüllen, wobei die langfristige Wartbarkeit ignoriert wird.

Wie können Entwickler KI-Programmierfallen vermeiden?

Indem sie die Kernarchitektur manuell definieren, klare Scope-Grenzen setzen und die KI als Werkzeug zur Implementierung gut definierter, kleinerer Aufgaben nutzen, anstatt sie als autonomen Architekten einzusetzen.

Wer ist Shiv Bhosale und was ist K10s?

Shiv Bhosale ist der Entwickler, der diese Erfahrung geteilt hat. K10s ist sein Projekt, ein GPU-fähiges Kubernetes-Dashboard, das er erfolgreich neu aufgebaut hat, nachdem die ursprünglich KI-generierte Version aufgrund architektonischer Probleme gescheitert war.