Vibe Coding ist nicht das Problem — Vibe Spec'ing ist es

Vibe Coding ist gerade der Begriff, an dem sich die Geister scheiden: Man prompted sich durch ein Projekt — frag die KI etwas, übernimm das Ergebnis, frag das nächste — und am Ende steht Software, die niemand mehr ganz versteht. Für manche ist das die Zukunft, für andere der Untergang sauberer Entwicklung. Beide übersehen denselben Punkt: Vibe Coding ist nicht die Ursache schlechter Software. Die fehlende Spezifikation dahinter ist es.

Dieser Beitrag ordnet ein, warum der Reflex „weniger KI” am Problem vorbeigeht — und wo das eigentliche Risiko liegt.

Was Vibe Coding eigentlich ist

Der Begriff beschreibt einen Arbeitsstil, kein Werkzeug. Statt vorab zu entscheiden, was gebaut werden soll, lässt man sich vom Modell durch die Umsetzung tragen: ein Prompt, ein Ergebnis, der nächste Prompt. Die Richtung ergibt sich unterwegs — nach Gefühl, nach „Vibe”.

Und das ist nicht per se falsch. Für einen Prototyp, eine Wegwerf-Demo, ein Wochenend-Experiment ist Vibe Coding hervorragend: schnell, billig, gut genug. Sogar die ersten Wochen eines MVPs lassen sich so überbrücken. Das Problem ist nicht der Stil. Das Problem ist, ihn dort weiterzuführen, wo er nicht mehr trägt.

Warum es in Produktion kippt

Sobald ein System produktiv läuft, Last bekommt, mit echten Daten arbeitet, in Drittsysteme integriert ist und über Jahre weiterentwickelt werden soll, rächt sich das Fehlen einer bewussten Spezifikation. Wir sehen das regelmäßig bei Kunden, die mit ihrem schnell zusammengeprompteten System zu uns kommen — die typischen Muster haben wir in Wie KI die moderne Softwareentwicklung verändert beschrieben: Datenmodelle, die bei 10.000 Nutzern kippen; drei verschiedene Auth-Patterns im selben System; Integrationen, die nur auf dem Happy Path funktionieren; Tests, die genau die Annahmen prüfen, die der Code selbst trifft.

Oberflächlich sieht das wie fertige Software aus. Bis es das erste Mal richtig benutzt wird.

Wie sich eine organisch gewachsene Landschaft, die niemand mehr ganz versteht, wieder auf ein tragfähiges Fundament bringen lässt — mit einer definierten Zielarchitektur statt Prompt-für-Prompt-Entscheidungen —, zeigt unsere .NET-Legacy-Modernisierung bei Omniga.

Das eigentliche Problem heißt Vibe Spec’ing

Hier liegt die Verwechslung. Die Kritik richtet sich gegen das Coden — gegen die KI, die den Code produziert. Aber die KI hat ihren Job getan: Sie hat gebaut, was im Prompt stand. Das Versäumnis liegt eine Ebene höher. Niemand hat entschieden, wie das Datenmodell in zwei Jahren aussehen soll, was bei einem Timeout zum Zahlungsdienstleister passiert, welche Berechtigungs-Granularität die Domäne verlangt. Es gab keine Spezifikation — nur Vibes.

Genau das ist Vibe Spec’ing: nicht das fehlerhafte Schreiben von Code, sondern das Auslassen der Entscheidungen, die vor dem Code fallen müssten. Die KI füllt diese Lücken zwangsläufig — mit dem statistischen Durchschnitt ihrer Trainingsdaten, nicht mit den Eigenheiten Ihres Geschäfts. Schlechte Software entsteht nicht, weil eine KI tippt. Sie entsteht, weil niemand spezifiziert hat, was zu tippen ist.

Woran man vibe-gespec’te Systeme erkennt

Ein paar Signale, die fast immer auf fehlende Spezifikation statt auf fehlende KI-Qualität zurückgehen:

• Inkonsistente Architektur — mal Repository-Pattern, mal direkter DB-Zugriff, weil jeder Prompt für sich entschieden hat.
• Eckfälle, die niemand benannt hat — Storno nach Versand, Abbruch im Workflow, doppelte Submits. Steht nicht im Output, weil es nicht im Prompt stand.
• Nicht-funktionale Anforderungen als Nachgedanke — Last, Sicherheit, DSGVO werden erst zum Thema, wenn es weh tut.
• Tests ohne Außenblick — sie bestätigen den Code, statt die Anforderung zu prüfen.

Die Lösung ist nicht weniger KI, sondern mehr Spezifikation

Wer auf die vibe-gecodeten Systeme mit „dann eben keine KI mehr” reagiert, wirft ein hervorragendes Werkzeug weg, um ein Methodenproblem zu lösen. KI ist fester Bestandteil professioneller Softwareentwicklung — sie liefert schneller und iteriert häufiger. Was sie nicht übernimmt, ist die Verantwortung für Architektur, Sicherheit und Produktivbetrieb. Diese Verantwortung trägt ein Software-Architekt, und sie äußert sich vor allem in einer guten Spezifikation.

Der konstruktive Gegenentwurf zu Vibe Spec’ing ist deshalb Spec-driven Development: erst die Entscheidungen treffen, die zählen, dann die KI sauber daran bauen lassen. Dieselbe Geschwindigkeit — aber mit einem Fundament, das auch in Monat neun noch trägt.

Fazit

Vibe Coding ist ein nützlicher Modus für das Wegwerfbare und ein gefährlicher für das Bleibende. Der Unterschied liegt nicht im Werkzeug und nicht im Tippen, sondern in der Frage, ob jemand die tragenden Entscheidungen bewusst getroffen hat. Nicht das Coden nach Gefühl ruiniert Systeme — das Spezifizieren nach Gefühl tut es.

---

Sie haben ein schnell entstandenes System, das jetzt produktiv tragen soll? Wir ordnen in einem kostenlosen Erstgespräch ein, wo es trägt und wo nachspezifiziert werden muss — und bauen individuelle Softwareentwicklung von Anfang an spezifikationsgetrieben.