Vibe-Coding ohne Architektur: Warum 1.690 Zeilen Code im Müll gelandet sind
Dieser Beitrag analysiert den Devlog “I’m going back to writing code by hand” von shvbsle. Den Originalbeitrag findest du unter blog.k10s.dev.
Der Text ist einer der ehrlichsten Erfahrungsberichte zum Thema Vibe-Coding, die ich bisher gelesen habe. Die dokumentierten Fehler sind lehrreich für jeden, der ernsthaft mit KI-Agenten Software entwickelt.
Was k10s war und warum es gescheitert ist
k10s war ein GPU-fokussiertes Dashboard für Kubernetes. Vergleichbar mit k9s, aber speziell für Teams, die NVIDIA-Cluster betreiben. GPU-Auslastung, DCGM-Metriken, Nodes im Leerlauf für 32 Dollar pro Stunde. Ein sinnvolles Tool für eine klar definierte Zielgruppe.
Der Entwickler nutzte ausschließlich Claude als Coding-Agent. 234 Commits über 30 Wochenenden. Die ersten Wochen waren produktiv. Pods-Ansicht, Namespace-Filterung, Log-Streaming, Vim-Keybindings. Alles funktionierte sauber in einzelnen Sessions.
Die Probleme begannen, als das Projekt über den Kontext der KI hinauswuchs. Nach dem Einbau des GPU-Fleet-Views zerbrach die gesamte Navigation. Tabellen blieben leer. Live-Updates stoppten. Daten aus einer Ansicht bluteten in andere Ansichten durch.
Das God-Object als Standard-Output der KI
Der Entwickler las seinen eigenen Code zum ersten Mal nach sieben Monaten wirklich durch. Er fand eine einzige Datei mit 1.690 Zeilen. Ein Struct verwaltete UI-Widgets, den Kubernetes-Client, View-Status, Navigation, Caching und Mouse-Handling gleichzeitig. Die Update-Funktion enthielt 500 Zeilen mit 110 Switch-Case-Verzweigungen.
Das ist kein Zufall. KI gravitiert zu genau dieser Struktur. Ein einzelnes Objekt erfüllt den aktuellen Prompt mit minimalem Aufwand. Es braucht keine Abstraktionen, keine Interfaces, keine Trennung von Verantwortlichkeiten. Das funktioniert bei Feature Nummer drei. Bei Feature Nummer dreißig kollabiert es.
Neun manuelle Null-Zuweisungen waren über die gesamte Datei verstreut, um Datenreste alter Ansichten zu löschen. Wurde eine vergessen, erschienen Geisterdaten in der UI. Die Taste S hatte drei verschiedene Funktionen je nach aktiver Ansicht. Über 20 Stellen prüften die Ressourcen-ID per String-Vergleich statt über Typen.
Die fünf konkreten Fehler
Feature-Blindheit der KI
Jeder Prompt erzeugte ein funktionierendes Feature. Claude lieferte den Fleet-View in einem Durchgang. Das Problem ist die fehlende Perspektive auf das Gesamtsystem. Die KI sieht nur den aktuellen Code-Pfad. Sie sieht nicht die 49 anderen Features, die denselben Status teilen. Architektureller Verfall über Zeit ist für sie unsichtbar.
Scope-Explosion durch Geschwindigkeit
Der Entwickler wollte ein GPU-Tool. Weil die KI so schnell lieferte, baute er stattdessen eine vollständige k9s-Kopie. Pods, Deployments, Services, Command-Palette, Mouse-Support, Contexts, Namespaces. Jedes Feature fühlte sich billig an. Aber jedes Feature war eine weitere Verzweigung im God-Object.
Die Komplexität wuchs unsichtbar, während die Geschwindigkeitsmetrik Erfolg suggerierte. Die Architektur konnte diese Last irgendwann nicht mehr tragen.
Positionale Daten statt typisierter Structs
KI wählt den kürzesten Weg zur sichtbaren Tabelle. In k10s wurden alle Ressourcen sofort in flache String-Arrays umgewandelt. Spaltenidentität war rein positional. Index 3 war Alloc. Index 0 war Name. Wurde eine Spalte in der Konfiguration verschoben, stimmte der gesamte Code nicht mehr.
Der Compiler kann bei reinen String-Arrays nicht helfen. Typisierte Structs erfordern mehr Aufwand im Prompt. Genau deshalb vermeidet die KI sie.
Unkontrollierte State-Mutationen
UI-Status wurde direkt aus Goroutinen heraus verändert. Keine Locks. Keine Mutexe. Das führte zu Datenrennen, die in einem Prozent der Fälle die Anzeige korrumpierten. Der Entwickler hielt sich selbst für verrückt, bevor er die Ursache fand.
Sauberes Message-Passing erfordert mehr Typen und mehr Infrastruktur. Die KI optimiert auf den kürzesten funktionierenden Pfad, nicht auf Korrektheit unter Nebenläufigkeit.
Keine menschliche Code-Review über sieben Monate
Der vielleicht wichtigste Punkt. Der Entwickler hat sieben Monate lang Diffs angeschaut, den Build geprüft und den Happy Path getestet. Er hat den generierten Code nie wirklich gelesen. Das ist die eigentliche Falle des Vibe-Codings. Die Geschwindigkeit fühlt sich so gut an, dass man aufhört, kritisch hinzusehen.
Was wir daraus lernen
Architektur ist eine menschliche Aufgabe. Wir müssen die Struktur festlegen, bevor die erste Zeile generiert wird. Konkrete Interfaces, Message-Typen und Ownership-Regeln gehören in eine CLAUDE.md oder AGENTS.md. Diese Dateien sind Leitplanken für jede einzelne Interaktion.
Klare Regeln für den KI-Agenten helfen nachweislich. Jede Ansicht ein separates Struct. Ansichten greifen nie auf den Status anderer Ansichten zu. Daten fließen als typisierte Structs bis zum Rendering. Hintergrund-Tasks senden Nachrichten an den Haupt-Loop statt direkt zu mutieren.
Der Entwickler schreibt k10s jetzt in Rust neu. Alle Architektur-Entscheidungen trifft er schriftlich, bevor der erste Prompt an die KI geht. Ich halte das für den richtigen Ansatz.
Vibe-Coding ist gut für Prototypen und Exploration. Für produktive Software brauchen wir menschliche Kontrolle über die Struktur. Die KI implementiert. Wir entwerfen.