Vibe Coding: nicht der Prompt, die Grenzen

Die Frage ist nicht, ob ein Coding-Agent guten Code schreibt. Er schreibt guten Code. Die Frage ist, ob er den Code schreibt, der in Ihr Projekt gehört. Das ist nicht dasselbe, und der Unterschied entscheidet sich nicht im Prompt. Er entscheidet sich in den Grenzen, die Sie vorher gezogen haben.

Was ist Vibe Coding, und wo hört es auf zu funktionieren?

Vibe Coding heißt, das Ergebnis zu prüfen, ohne den Weg zu verstehen. Sie beschreiben, was herauskommen soll, sehen sich an, ob es läuft, und machen weiter. Das ist eine legitime Arbeitsweise, und ich benutze sie selbst. Für einen Prototyp, der eine Frage beantworten soll und danach weggeworfen wird, ist sie sogar die richtige Wahl.

Sie bricht in dem Moment, in dem jemand das Ergebnis pflegen muss. Nicht, weil der Code schlecht wäre. Sondern weil niemand mehr weiß, warum er so aussieht, wie er aussieht. Der Fehler ist selten das Vibe Coding an sich. Der Fehler ist Vibe Coding an einer Stelle, an der der Code bleiben soll.

Warum geht die KI nicht von selbst den sauberen Weg?

Weil „sauber“ keine Eigenschaft des Codes ist. Es ist eine Eigenschaft der Beziehung zwischen dem Code und Ihrem Projekt, und diese Beziehung kennt das Modell nicht. Es sieht, was Sie ihm zeigen, und schließt aus dem, was es sonst gesehen hat. Drei Muster sind mir dabei immer wieder begegnet.

Es baut nach, statt zu suchen. Eine Hilfsfunktion, die es braucht, schreibt es hin. Dass es die Funktion im Projekt längst gibt, erfährt es nur, wenn es nachsieht, und Nachsehen kostet Schritte. Das Ergebnis läuft, es ist sogar ordentlich geschrieben, und es ist trotzdem die dritte Variante derselben Sache.

Es optimiert auf den grünen Haken. „Fertig“ heißt: Tests laufen, Typecheck sauber. Ob der Weg dorthin der ist, den Sie in sechs Monaten noch verstehen wollen, steht in keiner dieser Prüfungen. Ein Agent, der nach Erledigung strebt, findet den kürzesten Weg dorthin, und der kürzeste Weg ist selten der, der sich am besten altert.

Wenn eine Regel im Weg steht, entfernt es die Regel. Das hat mich am meisten gekostet, bis ich es verstanden hatte. Es ist kein böser Wille, es ist wieder nur die kürzeste Lösung. Ein eslint-disable beseitigt eine Fehlermeldung zuverlässiger als eine Umstrukturierung, und formal ist der Lauf danach grün. Wer nur auf das Ergebnis schaut, merkt es nicht.

Was hilft?

Grenzen statt Anweisungen. Eine Anweisung ist ein Vorschlag, den das Modell gegen andere Ziele abwägt. Eine Grenze ist etwas, an dem es scheitert. Ich nehme inzwischen einen festen Satz Regeln in jedes neue Projekt mit, und vier Einsichten daraus haben den größten Unterschied gemacht.

Eine Regel, die nicht maschinell geprüft wird, existiert nicht. Eine Konvention in einem Dokument, das niemand ausführt, ist eine Bitte. Erst wenn ein Lauf rot wird, ist es eine Regel. Das gilt für Menschen genauso, nur fällt es bei Menschen langsamer auf. Bei einem Agenten, der zwanzig Änderungen pro Stunde macht, fällt es sofort auf.

Der sicherste Weg ist der, bei dem der falsche nicht existiert. Statt zu schreiben, dass niemand direkt auf die Datenbank zugreifen soll, bauen Sie die Anwendung so, dass es keinen Weg dorthin gibt. Kein Zugang, keine Verletzung. Was nicht da ist, kann nicht falsch benutzt werden, und Sie müssen es auch nicht mehr erklären. Das ist der Punkt, an dem Architektur mehr wert ist als jede Regeldatei.

Kontext ist ein Budget, kein Ablageort. Alles, was in jede Sitzung mitgeladen wird, konkurriert mit der eigentlichen Aufgabe um Aufmerksamkeit. Meine dauerhaft geltenden Regeln sind deshalb kurz, wenige Zeilen pro Bereich, im Wesentlichen Verbote und ein Verweis. Die Begründungen und Details liegen in getrennten Dokumenten und werden gelesen, wenn sie gebraucht werden. Wer alles immer mitschickt, verschiebt das Problem nur.

Verbote sind präziser als Empfehlungen. „Bevorzugen Sie X“ lässt Spielraum, und Spielraum wird genutzt. „Y nie, immer X“ lässt keinen. Ich habe meine Regeln nach und nach von der ersten Form in die zweite umgeschrieben, und die Trefferquote stieg spürbar. Es klingt unfreundlicher, als es ist. Ein Agent nimmt es Ihnen nicht übel.

Was kostet das?

Vorarbeit, die sich im ersten Projekt nicht rechnet. Wer einmalig etwas baut, das danach wegkann, sollte diese Zeit nicht investieren. Ab dem zweiten Projekt trägt es, weil Sie dieselbe Basis mitnehmen und nur noch anpassen.

Und der Aufwand ist nicht einmalig. Regeln veralten, weil sich Bibliotheken ändern und weil Sie dazulernen. Eine Regel, die nicht mehr stimmt, ist schlimmer als keine: Sie erzeugt Widerstand an einer Stelle, an der es keinen geben sollte, und irgendwann schalten Sie sie selbst ab. Dann sind Sie wieder am Anfang.

Wo die Sache aufhört zu tragen

Grenzen ersetzen kein Urteil. Sie verhindern die Fehler, die Sie schon kennen, nicht die, die Sie noch nicht gemacht haben. Kein Regelsatz erkennt, dass ein Datenmodell falsch geschnitten ist oder dass die Anforderung, die Sie gerade sauber umsetzen lassen, die falsche Anforderung war. Das bleibt Ihre Arbeit.

Was Sie gewinnen, ist die Aufmerksamkeit dafür. Sie verbrauchen sie nicht mehr an Hilfsfunktionen, die es schon gab, und an abgeschalteten Prüfungen, die Ihnen erst drei Wochen später auffallen. Genau darum geht es bei Agentic Engineering: nicht darum, dem Modell mehr zuzutrauen, sondern darum, den Rahmen so zu setzen, dass sein Können an der richtigen Stelle ankommt.