Vibe-Coding: Was wir aus 291 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.
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 uns 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 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 224 Tests) war der einzige Grund, warum wir überhaupt vorankommen konnten. Wenn eine Änderung den VM-Zustand 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.
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.
KnotenCore v1.7.1-patch • Offizielle Webseite: knotencore.de