Vibe-Coding oder Spec-Driven Development: woran du den Unterschied erkennst

Was Vibe-Coding ist und wofür es gedacht war

Vibe-CodingSoftware per Zuruf an eine KI bauen und das Ergebnis übernehmen, ohne den erzeugten Code zu lesen oder zu prüfen. ist Programmieren per Zuruf: Du beschreibst einer KI, was entstehen soll, übernimmst das Ergebnis und gibst Fehlermeldungen einfach an sie zurück. Den Begriff hat der KI-Forscher Andrej Karpathy im Februar 2025 mit dem Zusatz geprägt, man vergesse dabei, dass es den Code überhaupt gibt.

Gedacht war das für Wegwerfprojekte am Wochenende. Ein Jahr später nannte Karpathy den Beitrag einen spontanen Einfall, der zufällig zur richtigen Zeit den passenden Namen geliefert habe. Der Name blieb, die Arbeitsweise hat die Wochenendprojekte längst verlassen.

Als Entwurf ist daran nichts falsch. Ein Klickdummy, der nach einer Stunde steht, beantwortet manche Frage schneller als jede Besprechung. Schwierig wird es, wenn der Entwurf ungeprüft live geht. Dann steht niemand für einen Code gerade, den nie jemand gelesen hat.

Woran du eine ungeprüft generierte Website erkennst

Einen Blick in den Quellcode brauchst du dafür nicht. Die typischen Fehler zeigen sich an der Oberfläche, sobald du die Seite anders bedienst als mit der Maus: per Tastatur, vergrößert oder auf einem kleinen Bildschirm.

Der Trend ist messbar. Die WebAIM Million 2026 (öffnet in neuem Tab) prüft jedes Jahr die Startseiten der eine Million meistbesuchten Websites automatisch. 95,9 Prozent haben erkennbare Fehler nach den WCAGDer internationale Standard für barrierefreie Websites, gestuft in die Konformitätsstufen A, AA und AAA., im Schnitt 56 pro Seite. Nach sechs Jahren leichter Besserung steigen beide Werte wieder. Das WebAIM-Team nennt als wahrscheinliche Ursache unter anderem KI-gestützte Programmierung, ausdrücklich mit dem Stichwort „vibe coding". Den Zusammenhang vermutet der Bericht, belegen kann er ihn mit diesen Daten nicht. Die vier Muster darunter prüfst du an jeder Seite selbst.

Menschen machen diese Fehler seit Jahren. Ein Generator erzeugt sie schneller, als jemand hinschauen kann, und ohne Abnahme fallen sie auch später niemandem auf. Wo eine Website unter das BFSGDeutsches Gesetz, das seit Juni 2025 von vielen Anbietern barrierefreie digitale Angebote verlangt. fällt, wird aus dem Schönheitsfehler ein rechtliches Risiko.

Billig rein, teuer raus: das Roach-Motel-Muster

Roach Motel heißt im UX-Design ein Dark Pattern, bei dem der Einstieg leicht ist und der Ausstieg schwer, wie bei einem Abo, das sich mit einem Klick abschließen und nur per Brief kündigen lässt. Eine ungeprüft generierte Website folgt demselben Prinzip, auch wenn das niemand so geplant hat.

Der Einstieg kostet wenig. Teuer wird die erste größere Änderung: ein neuer Bereich, ein Buchungsformular, die Anpassung an die Barrierefreiheitspflicht. Wer den Auftrag übernimmt, findet Code ohne Beschreibung und ohne Tests. Bevor sich dort etwas ändern lässt, heißt es rückwärts lesen, was die Seite eigentlich tun soll. Ab einer gewissen Größe ist ein Neubau billiger.

Die Mechanik kennst du vom Vendor Lock-in: Die Abhängigkeit entsteht hier durch fehlende Dokumentation. Sie trifft sogar den ursprünglichen Anbieter, denn auch der hat den Code nie gelesen. Ein günstiger Festpreis ist für sich kein Warnsignal. Entscheidend ist, was darin steckt: eine Prüfung, eine Dokumentation und eine Person, die dir die Seite erklären kann.

Was Spec-Driven Development anders macht

Beim Spec-Driven DevelopmentEntwicklung nach einer schriftlichen Anforderung mit Abnahmekriterien, gegen die das Ergebnis geprüft wird, auch wenn eine KI den Code schreibt. steht vor dem ersten Code eine Spezifikation: was gebaut wird, für wen und woran man erkennt, dass es fertig ist. Den Code darf eine KI schreiben. Geprüft wird er gegen diese Abnahmekriterien, von einem Menschen oder von einem automatischen Test.

Der Begriff ist jung, und die Werkzeuge dafür sind umstritten. Birgitta Böckeler, Distinguished Engineer bei Thoughtworks, hat drei davon getestet (öffnet in neuem Tab) und unterscheidet drei Stufen: Die Spezifikation gilt für eine einzelne Aufgabe, sie wird als lebendes Dokument mit dem Projekt weitergepflegt, oder sie ersetzt den Code als Hauptquelle ganz.

Ihre Kritik fällt deutlich aus. Die Werkzeuge erzeugten so viele Markdown-Dateien, dass sie lieber gleich den Code geprüft hätte. Aus einem kleinen Fehler machte eines vier User Stories mit 16 Abnahmekriterien. Und der Agent hielt sich trotz aller Vorgaben oft nicht daran: eine trügerische Kontrolle, wie sie es nennt. Eine Spezifikation ersetzt also keine Prüfung. Sie macht Prüfung erst möglich.

So entsteht diese Website

janraap.de ist im September 2026 von Nuxt auf Grav umgezogen: 76 Seiten portiert, 42 Weiterleitungsregeln. Ein großer Teil der Umsetzung läuft über KI-Agenten. Gearbeitet wird nach der zweiten Stufe, mit lebender Projektdokumentation und automatischen Prüfungen vor jeder Abnahme.

Das ist Aufwand, und er fällt am Anfang an. Jede spätere Änderung wird dadurch billiger, weil die Prüfung schon steht und die Regeln nachlesbar sind. Wie der Umzug selbst ablief und warum die Mehrsprachigkeit auf Nuxt Eigenbau war, steht in der Fallstudie Eigene Website auf Nuxt 4.

Wo auch eine Spezifikation nicht trägt

Wie sich eine Suche anfühlt, klärt kein Papier. Der TypeScript-Trainer Matt Pocock hält ausführliche Spezifikationen deshalb oft für die falsche Investition, solange niemand etwas Lauffähiges gesehen hat.

In seinem Video zum Thema (öffnet in neuem Tab) plädiert er für Prototypen: Wegwerfcode, der genau eine Frage beantwortet. Die kosten heute kaum noch etwas. Sein Kernsatz: Der Sprung von Besprechung und Spezifikation zu produktionsreifem Code ist groß, der von einem funktionierenden Prototyp dorthin klein.

Mit Klick wird ein Video von YouTube geladen. Es gelten die Datenschutzbestimmungen von Google.

Mit dem Spec-Driven-Ansatz verträgt sich das gut. Ein Prototyp ist Vibe-Coding mit Ablaufdatum: Er beantwortet eine Frage, danach wird er weggeworfen oder gegen die Spezifikation sauber neu gebaut. Wie beides zusammengeht, Spezifikation für das Was, Prototyp für das Wie und lebende Dokumentation als Gedächtnis, ist Thema eines eigenen Artikels.

Prüffragen an deinen Anbieter

Ob eine Website gebaut oder nur generiert wurde, zeigt sich im Erstgespräch. Eine gute Antwort nennt ein Dokument, ein Werkzeug oder eine Person.

• Gegen welche Kriterien wird die Seite abgenommen, und bekomme ich sie vorher zu sehen?
• Wie wird Barrierefreiheit geprüft, mit welchem Werkzeug und von wem?
• Gibt es eine Dokumentation, mit der eine andere Fachperson weiterarbeiten kann?
• Was passiert, wenn ich in einem Jahr einen neuen Bereich brauche?
• Wer hat den Code gelesen, bevor er live ging?

Die Fragen zu Domain, Hosting und Nutzungsrechten stehen im Ratgeber zum Vendor Lock-in.

Ich arbeite täglich mit KI. Entscheidend ist, ob vorher jemand festgelegt hat, was richtig ist, und es danach geprüft hat. Vibe-Coding überspringt genau diesen Schritt, Spec-Driven Development macht ihn zur Grundlage.