Vibe Coding fühlt sich großartig an. Mit einem Prompt entsteht eine App, die schon fast wirkt wie das fertige Produkt. Bei einem meiner neueren Projekte, einer App zum Sprachenlernen, dachte ich, als ich das Ergebnis nach dem ersten Prompt sah: fast perfekt. Nur noch ein paar Details…
Aber dann geht es oft los mit der Frustration: Es kommt zu Missverständnissen, Änderungen in den falschen Bereichen, oder Dinge, die funktioniert haben, sehen auf einmal anders aus. In meiner App war der Hintergrundsound der Anfangsszene beim ersten Mal falsch und ließ sich ganz einfach korrigieren. Nur leider hat die KI ihn im Lauf des Projekts geschlagene 5 Mal wieder zurückgeändert zur falschen Version.
Auch änderten sich immer wieder Texte und Reihenfolgen, obwohl die eigentlich feststanden, gut waren und nichts in diesem Bereich zu ändern war.
Was fehlte, war das, was beim Film ein eigener Job ist: Continuity, also Kontinuität des Gezeigten. Wenn die Heldin das Schwert in der Linken trägt, im nächsten Schnitt aber in der Rechten, spricht man vom Anschlussfehler. Und die passieren so leicht, dass es auf dem Filmset eine eigene Person gibt, die nur auf solche Dinge achtet.
One-Shot funktioniert gut
Ob Film oder Vibe Coding: Alles, was in einem einzigen Stück gedreht oder gepromptet werden kann, ist einfach. Anschlussfehler können hier nicht entstehen, einfach daher, weil es keine Anschlüsse gibt – alles ist aus einem Guss.
Auch wenn Sie nur ein paar Details per Prompt korrigieren, gibt es meist wenig Probleme. Ein One-Pager, eine Landingpage und auch eine Website mit einer Handvoll Seiten sind normalerweise unproblematisch.
Bei größeren Projekten dagegen ist es praktisch unverzichtbar, ein Design-System anzulegen. Darin halten Sie fest, wie der visuelle Teil Ihrer Site oder App gestaltet sein soll. Also Dinge wie Schriftarten und -größen, Abstände, Raster, Farben und die visuelle Sprache. Denn sonst laufen Sie Gefahr, dass es immer wieder zu Abweichungen kommt. Was die KI nicht weiß, füllt sie mit Vermutungen und der wahrscheinlichsten Lösung. So tendieren Projekte ohne klare Gestaltungsvorgaben zum Durchschnitt, zu dem, wie die meisten Projekte aussehen, die in den Trainingsdaten vorkamen.
Weitere Probleme entstehen, wenn Sie über längere Zeit oder mit mehreren anderen an einem Vibe-Coding-Projekt arbeiten. Dann entstehen mehr und mehr Versionen, die sich oft sehr ähnlich sind und nur mit Mühe auseinanderzuhalten sind. Wenn Sie später zu einem älteren Stand zurückkehren wollen, wird es sehr schwer, den richtigen zu finden. Dadurch, dass Änderungen so unglaublich einfach sind mit KI, können in einer Stunde Dutzende von Versionen entstehen, bei denen kein Mensch den Überblick behalten kann.
Entwicklung ist mehr als Code
Wer im Design arbeitet, den ärgert es sehr, wenn andere meinen, Aufgabe des Designs sei, Dinge hübsch zu machen. Ähnlich ist es, wenn man über Entwicklung sagt, ihre Aufgabe sei, Code zu tippen. Darauf läuft es aber hinaus, wenn wir jetzt meinen, mit KI entwickeln zu können.
Die Softwareentwicklung hat seit Ende der 1960er-Jahre viele Methoden etabliert, die helfen, größere Software-Projekte erfolgreich zu managen. Schon in dieser Zeit wurde von einer „Softwarekrise“ gesprochen. Der Informatiker Edsger W. Dijkstra formulierte es so:
Die Hauptursache der Softwarekrise ist, dass die Maschinen um viele Größenordnungen leistungsfähiger geworden sind. Kurz: Als es keine Maschinen gab, war Programmierung auch kein Problem. Als wir ein paar wenig leistungsfähige Computer hatten, wurde Programmierung zu einem kleinen Problem. Und jetzt haben wir riesige Computer, und Programmierung ist zu einem riesigen Problem geworden.
Das Zitat ist von 1972, es könnte aber auch die Situation heute beschreiben. Aber die Softwareentwicklung hat seither Wege gefunden, sogar sehr große Projekte beherrschbar zu machen. Wir können uns bei den Methoden des Software Engineering bedienen. Davon profitieren Sie auch, wenn Sie nur kleine Prototypen für UX-Tests erstellen. Denn auch hier iterieren Sie, nach jedem Test verbessern Sie den Prototyp, und vielfach verwenden Sie Teile später wieder. Machen Sie sich das Leben leichter und upgraden Sie Ihre Arbeitsweise. Wie, dazu geben uns 3 weitere Experten Tipps:
John Maeda ist Designer und Informatiker. Er war Präsident der Rhode Island School of Design und ist heute bei Microsoft für Design und KI zuständig. Er sagt, zu wissen, was man gestalten soll, sei schwer. Noch schwerer aber sei, es so zu bauen, dass es zuverlässig und skalierbar läuft. Jeder gute Prototyp wirft die Frage auf, wie man das in angemessener Zeit umsetzen soll, gerade mit KI.
Luke Wroblewski war Produktdesigner bei Google, Yahoo und eBay, er ist Autor des einflussreichen Buchs „Mobile First“. Er rät statt Vibe Coding zu Craft Coding, also zu handwerklichem Coding. Er sieht uns aus dem Design als Teil des Entwicklungsteams. Wir sollten nicht einfach irgendwelchen Code erzeugen, sondern solchen, der später in die Entwicklung eingeht. Dadurch müssen wir uns auch an die Standards der Softwareentwicklung halten – die die meisten von uns erst einmal kennenlernen müssen.
Simon Willison, einer der meistgelesenen Blogger zu praktischer KI-Entwicklung, sagt: Wir sollten zu Vibe Engineering übergehen. Also zum Entwickeln mit KI auf Basis der bewährten Softwareentwicklungspraktiken. Dazu gehören vor allem Planung, Dokumentation, Versionskontrolle (dazu gleich mehr) und (technische) Tests. Er betont: Der Großteil der Arbeit bei der Entwicklung ist nicht, den Code zum ersten Mal zu schreiben. Der Großteil der Arbeit ist, den Code weiterzuentwickeln, Fehler zu finden, Verbesserungen umzusetzen und Erweiterungen einzubauen.
Das Drehbuch für die KI
Erster Punkt: Wenn wir mit Coden beginnen, sollten wir nicht das vergessen, was wir selbst anderen seit Jahren sagen: Vor dem Loslegen brauchen wir ein ordentliches Konzept. In der Softwareentwicklung gibt es dafür die (Anforderungs-)Spezifikation oder englisch Software Requirements Specification, kurz SRS. Diese ist oft sehr umfangreich, und das muss bei uns nicht sein – es geht nur darum, die Grundlagen anfangs zu definieren. Denn die KI kennt die allgemeinen Regeln, aber nicht Ihre. Wenn sie Abweichungen findet, hält sie diese für Fehler und ändert sie. Daher müssen Sie die technischen Rahmenbedingungen klar definieren, vor allem aber die Ziele und Details Ihres Projekts, die Sie schon im Kopf haben.
Gut geeignet ist dazu eine reine Textdatei, z. B. SPEC.md. Darin, nicht im Prompt, halten Sie dauerhaft fest, wie die Anwendung aussehen soll. Damit vermeiden Sie auch, dass Sie bei jedem neuen Chat von vorn anfangen müssen. Und Sie haben automatisch dokumentiert, was eingeflossen ist. So kann das Dokument aussehen:
# Spezifikation: [Name der App]
## Ziel
Wozu gibt es die App? Welches Problem löst sie?
[z. B. Erwachsene ohne Vorkenntnisse lernen Spanisch in kurzen Lektionen unterwegs]
## Zielgruppe
Wer nutzt sie, mit welchem Vorwissen, auf welchem Gerät?
## Kernfunktionen
- Anfangsszene als Einführung (bewusst anders gestaltet als die Lektionen)
- [Anzahl] Lektionen mit [Aufbau]
- Fortschrittsanzeige
- [...]
## Bewusst nicht enthalten
- keine Benutzerkonten
- keine Bewertung durch Punkte/Score
- [...]
## Struktur und Ablauf
Anfangsszene → Lektionsübersicht → Lektion → Abschluss
## Gestaltung
Verweis auf Design-System. Bewusste Abweichungen:
- Anfangsszene: eigenes Layout, eigener Hintergrundsound
## Inhalte
Texte liegen in /texte, Reihenfolge ist verbindlich.
## Offene Fragen
- [...]
Eine echte Anforderungsspezifikation ist noch deutlich detaillierter, aber für den Anfang reicht uns so ein Dokument. Zwei weitere Sachen können wir uns abschauen: Akzeptanzkriterien und die Definition of Done. Akzeptanzkriterien definieren für eine einzelne Funktion, woran Sie erkennen, dass diese fertig ist. Eine Fortschrittsanzeige etwa ist fertig, wenn sie auf jedem Lernscreen zu sehen ist, nach jeder abgeschlossenen Lektion aktualisiert wird und den Stand als „Lektion 3 von 12“ anzeigt. Die Definition of Done dagegen gilt fürs ganze Projekt: Sie ist eine knappe Liste von Anforderungen, die jede Änderung erfüllen muss, damit sie als erledigt gilt. Ein Beispiel für so solche Anforderungen: Läuft auf dem Smartphone, Texte wie festgelegt nicht verändert, Commit mit Beschreibung angelegt (zum Commit gleich mehr).
Im Projektverlauf hilft ein zweites Textdokument sehr, das die Arbeitspakete definiert, etwa TASKS.md. Darin steht, was in jedem einzelnen Schritt zu tun ist und was schon erledigt ist. Dieses Dokument lassen Sie von der KI pflegen, sie hält darin fest, was sie erledigt hat und was noch zu tun ist. Hinein kommen auch Dinge, die in späteren Schritten zu erledigen sind, die jetzt aber noch nicht angegangen werden. In der agilen Entwicklung heißt diese Liste Backlog. Auch wird hier dokumentiert, wenn etwas nicht getan werden soll oder anders umgesetzt wird als üblich oder als definiert.
Aufpassen müssen Sie nur, weil viele KIs hier dann sehr ausführlich dokumentieren. Es finden sich auch manchmal Entscheidungen wieder, die überholt sind oder nicht so allgemein gelten, wie es die KI festgehalten hat. Das Dokument braucht also auch Pflege. Die kann ein übergeordneter Agent übernehmen, im Idealfall werfen Sie selbst aber zumindest gelegentlich einen Blick hinein.
Die Filmklappe: der Commit
Beim Film wird vor jeder Aufnahme eine Klappe ins Bild gehalten, auf der steht, welche Szene und Einstellung jetzt kommt und die wievielte Version das ist („Take“). Etwas Vergleichbares ist der Commit bei der Softwareentwicklung, nur kommt der am Ende. Wenn Sie einen kleinen Abschnitt der Entwicklung abgeschlossen haben, dann speichern Sie den Code nicht einfach nur, sondern Sie committen ihn ins Repository (kurz Repo), also ins Archiv aller Versionen Ihres Projekts. Und, ganz wichtig: Sie beschreiben, was sich geändert hat und warum. Das erleichtert es, später zu finden, an welcher Stelle z. B. eine neue Funktion hinzugekommen ist – oder ein Fehler. Und vor allem ist es auch ein Denkwerkzeug: Sie müssen an der Stelle darüber nachdenken, was Sie jetzt eigentlich gemacht haben bzw. die KI haben machen lassen. Die Wirkung davon sollten Sie nicht unterschätzen, weil man gerade beim Vibe-Coden dazu neigt, zu schnell von einem Punkt zum nächsten zu gehen, ohne nachzudenken, ob man den jetzt überhaupt sinnvollerweise angehen sollte und ob der vorige abgeschlossen ist.
Bei dem eingangs genannten Beispiel habe ich das nicht getan – mit Commits und einem gelegentlichen Blick auf die Änderungen (mit dem Werkzeug diff) wäre mir der immer wieder auftauchende Sound immer gleich aufgefallen.
Unser Werkzeugkasten aus der Softwareentwicklung
Wir können uns mit vielen Methoden bedienen, und leider braucht es natürlich etwas Einarbeitungszeit. Ich empfehle Ihnen, sich mit folgenden zu beschäftigen, wenn Sie in Zukunft mit mehr Freude vibe-coden wollen:
Spezifikation (Grobkonzept)
Dokument, das vor Ihrem ersten Prompt dokumentiert, was die Anwendung leisten soll, für wen sie ist und was bewusst nicht umgesetzt wird. Häufig heißt diese Datei SPEC.md.
Eine einfache Textdatei mit der Endung .md (Markdown) ist dafür üblich. Erklären Sie Ziel, Zielgruppe, Kernfunktionen und nicht Umzusetzendes. Der erste Prompt verweist dann einfach auf diese Datei.
Versionskontrolle (und Commit)
Versionskontrolle heißt ein System wie das kostenlose Git, das jede Fassung eines Projekts mit einer kurzen Beschreibung der Änderung sichert. Ein solcher Speicherpunkt heißt Commit. Alte Stände lassen sich zurückholen und alle Änderungen nachverfolgen.
Git selbst bedienen müssen Sie nicht unbedingt, Sie können die KI auch bitten, das zu tun (Claude Code oder Codex können das). Sie sagen der KI dann nach jedem Schritt, der eine neue Funktion ergänzt oder einen Fehler behoben hat, dass sie einen Commit machen soll. Die Beschreibung formulieren Sie dabei aber bitte unbedingt selbst (siehe oben).
Diff
Ein Diff (von englisch difference) zeigt, was sich zwischen zwei Versionen geändert hat. Dabei fällt auch auf, wenn die KI ungefragt etwas mitgeändert hat.
Werfen Sie regelmäßig einen Blick auf die Änderungen. Etwa mit GitHub Desktop, einem kostenlosen Programm für Git. Kommt Ihnen etwas komisch vor, fragen Sie einfach nach.
Branch
Ein Branch ist ein Zweig des Projekts. Hier können Sie z. B. Dinge ausprobieren, ohne den aktuellen Stand zu gefährden.
Vor größeren Umbauten oder dem Ausprobieren von Alternativen legen Sie einen Branch an. Sind Sie zufrieden, binden Sie diese Version mit einem Merge in die Hauptfassung ein.
Arbeitspakete
Ein klar definierter Auftrag für eine Sitzung: was geändert wird und was ausdrücklich nicht angefasst werden soll.
Für jede Sitzung halten Sie am besten in einer Markdown-Datei fest, was genau zu tun ist. Das kann ein eigenes Dokument sein oder ein fortlaufend gepflegtes, auf das Sie dann im aktuellen Prompt verweisen.
Akzeptanzkriterien und Definition of Done
Vorab festgelegte, prüfbare Kriterien, wann etwas als fertig gilt: Akzeptanzkriterien für einzelne Funktionen, die Definition of Done für jede Änderung im Projekt.
Notieren Sie für jede Funktion und jede Korrektur 3 bis 5 Akzeptanzkriterien, die sich eindeutig prüfen lassen. Die Definition of Done ergänzt sie um eine kurze Liste, die immer gilt. Ist beides erfüllt, markieren Sie den Teil als abgenommen. Ändern sollte er sich danach nur noch, wenn Sie das bewusst entscheiden.
Design-System
Sammlung von Farben, Schriften, Abständen und Bausteinen der Benutzungsoberfläche. Häufig heißt die Datei DESIGN.md.
Beschreiben Sie die Gestaltung so detailliert wie nötig. Halten Sie darin auch Ausnahmen fest, wenn Sie sie während des Projekts festlegen, sonst fällt die KI immer wieder auf den Standard zurück.
Projektdokumentation
Grundregeln für das Projekt. Diese liest die KI zu Beginn jeder Sitzung. Bei Claude Code heißt die Datei CLAUDE.md. Viele andere Werkzeuge lesen eine Datei namens AGENTS.md.
Halten Sie die Beschreibung kurz. Sehen Sie gelegentlich darauf und löschen Sie alles, was nicht zwingend nötig ist oder was nicht mehr stimmt.
Trennung von Inhalt und Gestaltung
Texte und Bilder liegen getrennt von Code und Layout. So kann die KI am Layout arbeiten, ohne versehentlich Inhalte zu verändern.
Für Websites gibt es dazu Redaktionssysteme (CMS), Empfehlungen dazu im Newsletter Welches CMS – und wann keines. Bei kleineren Projekten legen Sie die Inhalte zumindest getrennt ab und weisen die KI in der Projektdokumentation darauf hin, dass die Ressourcen unangetastet bleiben sollen.
Fazit
Tun Sie sich und Ihren Projekten einen Gefallen und bedienen Sie sich großzügig beim Werkzeugkasten, den Software Engineering zur Verfügung stellt. Mit der KI haben Sie praktisch ein riesiges Entwicklungsteam an der Hand, das Sie führen müssen. Wenn Sie diese neue Aufgabe gut ausfüllen, wird die Qualität Ihrer Ergebnisse so wachsen, wie es jetzt schon das Tempo tut. Und Sie ersparen sich das, worüber ich mich beim Sprachlern-Projekt so geärgert habe: ständig die gleichen Fehler wegprompten zu müssen.
In der Praxis
Wenn Sie ins KI-Coding für Prototypen und Anwendungen einsteigen wollen: Am 27. Oktober sehen Sie im Online-Kurs beim Rheinwerk Verlag an einem Vormittag, wie mit Claude Design und Claude Code ein fertiger Prototyp entsteht. Vom ersten Konzept über die Prompts bis zur lauffähigen App. Wir starten mit dem Design-System und sehen, wie man damit die ersten Schritte macht. Programmierkenntnisse sind nicht nötig. Infos: https://www.rheinwerk-verlag.de/online-kurse/prototypen-erstellen-claude-design-und-claude-code/
Lohnende Links
Luke Wroblewski: AI Coding Agents for Designers
Wie wir im Design mit KI-Agenten am Code arbeiten; vor allem in großen Unternehmen
Simon Willison: Vibe engineering
Erklärt, warum wir bei KI-Entwicklung technische Tests, Dokumentation und Versionskontrolle brauchen
Li et al.: Vibe Coding for UX Design, arXiv 2025
Studie, für die 20 UX-Fachleute zu ihrer Arbeit mit KI befragt wurden
Brad Frost: Agentic Design Systems in 2026
Beschreibt seine Arbeitsweise mit Design-Systemen als Grundlage für KI-Agenten
Patrick Neeman: Design.md – the one standard file carries your visual identity
Zeigt, wie Sie DESIGN.md für Ihre eigene Gestaltung anlegen
Xinran Ma: Git Concepts for Beginners
Git-Grundlagen von einer Designerin erklärt
