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. Wir tauschen dabei unbewusst zukünftige Kompetenz gegen tagesaktuelle Geschwindigkeit ein, was den Kern des gestörten Lernverhaltens im KI-Zeitalter beschreibt.

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. Das verdeutlicht das Problem von Schätzungen, die ohne Einbeziehung des Teams entstehen. Solche Vorgaben und das eigene Entwickler-Ego sabotieren die Planung, was die Critical Chain Methode durch Pufferung zu lösen versucht.

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. Dieses blinde Durchwinken ist der Hauptgrund, warum Agentic Coding eine Falle ist, wenn die kognitive Aufsicht schwindet. Dass blindes Vertrauen in automatische Prozesse auch in der Sicherheit fatale Konsequenzen hat, zeigt der GitHub-Breach über eine vergiftete VS Code Extension, bei dem 11 Minuten Auto-Update ausreichten, um 3.800 interne Repositories zu kompromittieren.

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.