Vibe Coding nach dem Hype: Der Moment, in dem ein Prototyp Verantwortung bekommt
Ein funktionierender KI-Prototyp ist kein fehlerhafter Anfang. Er wird erst dann riskant, wenn niemand entscheidet, nach welchen Regeln er in ein dauerhaftes Produkt übergeht.
Um 17:30 Uhr funktioniert die Demo. Der neue Ablauf zeigt die richtigen Daten, der Button reagiert, die Kollegin aus dem Fachbereich erkennt ihre Idee wieder. Mit Cursor, GitHub Copilot, Claude Code oder OpenAI Codex konnte ein Team in Stunden etwas sehen, das früher erst nach mehreren Schleifen sichtbar geworden wäre.
Am nächsten Morgen ändert sich die Frage. Jetzt soll derselbe Ablauf mit echten Rollen, unvollständigen Daten, einer langsamen Schnittstelle und einer Kollegin funktionieren, die den ursprünglichen Chat nicht kennt. Der Prototyp hat nicht versagt. Er hat nur seinen Status geändert: Aus einer Erkundung wird ein Stück Software, das jemand später verstehen und verändern muss.
Vibe Coding ist eine Arbeitsform, keine Produktionsfreigabe
Der Begriff wird oft als Vorwurf oder als Heilsversprechen benutzt. Beides verfehlt den Punkt. Vibe Coding ist gut darin, eine Möglichkeit schnell greifbar zu machen: ein Interface ausprobieren, eine Fachfrage sichtbar machen, einen Datenfluss skizzieren oder eine Hypothese gegen die Realität testen.
Es wird riskant, wenn ein Team diese Stärke mit einer Freigabe verwechselt. Die Tatsache, dass etwas funktioniert, sagt noch nicht, wie es bei fehlenden Berechtigungen, doppelten Daten, ungewöhnlichen Eingaben oder späteren Änderungen reagiert. Ein schneller Entwurf hat oft absichtlich keine vollständige Antwort darauf. Das ist in der Exploration völlig in Ordnung. Erst für Produktion wird es zu einer offene Schuld.
Der Übergang braucht einen eigenen Termin
Der schlechteste Übergang passiert nebenbei: Ein Prototyp wird beliebt, bekommt echte Nutzer und bleibt im selben Branch, weil „es doch schon läuft“. Besser ist ein kurzer, bewusster Übergabetermin. Nicht als Ritual, sondern als Statuswechsel.
In diesem Gespräch beantwortet das Team fünf Fragen:
- Welches Problem hat der Prototyp tatsächlich validiert? Nicht alles, was gebaut wurde, muss bleiben.
- Wer besitzt den Code nach der Demo? Ein Name oder ein Team, das Änderungsfragen beantwortet.
- Welche Daten und Rechte berührt er? Besonders dort müssen Annahmen explizit werden.
- Was muss unabhängig getestet werden? Erfolgspfad, Fehlerpfad und mindestens eine unangenehme Randbedingung.
- Wie kommen wir zurück? Ein Feature-Flag, ein Rollback oder eine klare Rückbaumöglichkeit.
Wenn eine dieser Fragen offen bleibt, ist das keine Absage an die Idee. Es ist ein Hinweis, dass sie noch im Experimentiermodus lebt.
Vom Prompt zum Arbeitsauftrag
Ein Agent kann aus einer groben Idee erstaunlich viel machen. Für die Produktionsphase braucht er aber andere Leitplanken als im ersten Entwurf. Der Auftrag sollte nicht nur das sichtbare Ziel nennen, sondern auch die Änderungsgrenze: Welche Dateien gehören dazu? Welche Abhängigkeiten sollen tabu bleiben? Welche Tests müssen laufen? Welche Entscheidung darf nicht automatisch fallen?
Diese Beschränkung wirkt zunächst weniger kreativ. In der Praxis schafft sie Freiheit an der richtigen Stelle. Das Team kann den Agenten weiter für Tests, Dokumentation, kleine Reparaturen und klar abgegrenzte UI-Arbeit nutzen, ohne dass jede Anfrage unbemerkt zur Architekturentscheidung wird.
Was mit der Geschwindigkeit passiert
Der Übergang in einen geregelten Prozess kostet am Anfang Tempo. Es gibt weniger spektakuläre Demos und mehr Fragen zu Tests, Schnittstellen und Eigentum. Doch diese Zeit ist kein Gegenpreis zur Produktivität. Sie verhindert, dass der schnelle Prototyp später zum teuren Rätsel wird.
GitHub empfiehlt kleine, fokussierte Änderungen, Kontext für Reviews und einen Selbstcheck vor dem Pull Request. Genau daran kann ein Vibe-Coding-Projekt reifen: nicht indem man den experimentellen Charakter verleugnet, sondern indem man aus seiner besten Idee eine Serie kleiner, erklärbarer Änderungen macht.
Das Abschlusskriterium ist nicht „sieht fertig aus“
Vor einem Merge in einen dauerhaft betriebenen Bereich sollte ein Prototyp eine einfache Reifeprüfung bestehen:
- Ein Mensch kann seinen Zweck und die wichtigsten Annahmen in wenigen Sätzen erklären.
- Ein neuer Teamkollege findet die relevanten Regeln und Befehle im Repository.
- Tests decken nicht nur den Demo-Fall ab, sondern auch das erwartbare Scheitern.
- Berechtigungen, Datenzugriffe und externe Nebenwirkungen sind benannt.
- Es gibt einen Rückweg, wenn die Idee in der Praxis nicht trägt.
Das ist kein Versuch, Vibe Coding zu zähmen, bis nichts mehr davon übrig ist. Es ist der Weg, seine Stärke zu behalten: schneller lernen. Der Unterschied ist nur, dass ein Team vor dem nächsten Schritt bewusst entscheidet, wann es weiter lernt und wann es Verantwortung übernimmt.