Vibe-Coding: Was wir aus 298 Sprints gelernt haben 🛠️
„Vibe-Coding“ – eine KI den Code schreiben lassen, während man selbst den Prozess steuert – klingt nach dem Traum jedes Entwicklers. Da KnotenCore komplett auf diese Weise gebaut wurde, hatten wir genug Zeit zu erleben, wie das in der Praxis wirklich aussieht. Hier ist ein realistischer Blick auf die Grenzen, die Fehler und das, was wir gelernt haben.
1. Prototypen sind einfach, Wartung ist schwer
Einen Prototyp zum Laufen zu bringen, geht überraschend schnell. Man beschreibt eine einfache Stack Machine und die KI generiert in wenigen Prompts eine funktionierende Schleife. Es fühlt sich mühelos an.
Der Haken dabei: Weil man den Code nicht Zeile für Zeile selbst geschrieben hat, kennt man ihn nicht in- und auswendig. Wächst das Projekt, verliert man leicht den Überblick darüber, wie die verschiedenen Teile zusammenspielen. Wenn man nicht aufpasst, hat man schnell einen Haufen Code vor sich, den man selbst nicht mehr erklären oder warten kann. Wir mussten lernen, rigorose Architekturdokumente (wie unsere llm.md) als "Karte" zu pflegen, damit Mensch und Maschine nicht die Orientierung verlieren.
2. Man kann echte Fehler nicht einfach „wegpromptern“
Wenn ein Fehler in einem JIT-Compiler oder einer VM-Laufzeit auftritt, hilft ein einfaches „behebe den Fehler“ selten weiter. Wenn die KI die Ursache nicht versteht, schlägt sie oft Patches vor, die den Fehler nur verstecken oder an anderer Stelle etwas beschädigen.
Als wir beispielsweise auf Registerfehler bei unseren Rechenoperationen stießen (Sprints 282 und 291), mussten wir sich den erzeugten x86_64-Assemblercode genau ansehen, die Register isolieren und der KI den logischen Fehler exakt aufzeigen. Man muss das System unter der Haube trotzdem verstehen; die KI dient am Ende nur als verdammt schnelle Tastatur.
3. Tests sind das Sicherheitsnetz
Auf diese Weise ohne eine strenge Test-Suite zu arbeiten, ist fast unmöglich. Da die KI in Sekundenschnelle ganze Abschnitte einer Datei umschreiben kann, baut man sich extrem leicht unbeabsichtigte Fehler ein.
Unsere Test-Suite (mittlerweile 234 Tests) war der einzige Grund, warum wir überhaupt vorankommen konnten. Wenn eine Änderung den VM-Zustand, das kryptografische Ledger oder die Sandbox-Logik beschädigte, schlugen die Tests sofort an. Das gab uns eine klare Grenze: Solange die Tests nicht grün sind, war der Prompt nicht erfolgreich. Wir sind in Sprint 295 sogar so weit gegangen, eine fremde KI komplett "blind" auf die Doku loszulassen, um zu testen, ob unsere Spezifikationen überhaupt wasserdicht sind.
4. Eine andere Art von Arbeit
Vibe-Coding ist keine Abkürzung, um sich das Denken zu sparen. Man verbringt weniger Zeit mit dem Auswendiglernen von Syntax, aber viel mehr Zeit mit dem Lesen von Code, dem Schreiben von Tests und dem Nachdenken über die Architektur. Es ist eine Zusammenarbeit, bei der man als Mensch kritisch bleiben, die richtigen Fragen stellen und wissen muss, wann man zu einer generierten Lösung „Nein“ sagt.