Unter Vibe Coding versteht man eine Arbeitsweise, bei der Software nicht Zeile für Zeile getippt, sondern in natürlicher Sprache beschrieben und von einem KI-Modell erzeugt wird. Die Entwicklerin oder der Entwickler formuliert, was entstehen soll, prüft das Ergebnis, korrigiert nach und wiederholt den Zyklus. Aus einer Idee wird so in überschaubarer Zeit ein klickbarer Prototyp.

Dass dieses Vorgehen inzwischen über Experimente hinaus ist, zeigt sich auch an der Weiterbildungslandschaft: Es gibt mittlerweile Workshop-Formate, die genau drei Punkte adressieren – die Auswahl der passenden Werkzeuge, das Formulieren von Anforderungen und die Prüfung der generierten Ergebnisse. Diese drei Punkte sind kein Zufall. Sie markieren die Stellen, an denen prompt-getriebene Entwicklung in der Praxis gelingt oder scheitert.

Warum der Prototyp plötzlich früher kommt

Im klassischen Ablauf liegt zwischen einem Anforderungsprofil und etwas Vorzeigbarem eine Strecke aus Konzept, Wireframe, Datenmodell und erster Implementierung. Jeder dieser Schritte kostet Zeit, und jeder Schritt transportiert Missverständnisse weiter, ohne sie sichtbar zu machen.

Vibe Coding verschiebt diese Reihenfolge. Statt lange über ein Dokument zu diskutieren, entsteht früh ein Artefakt, das man anklicken kann. Fachabteilung und Entwicklung reden dann nicht mehr über Interpretationen eines Textes, sondern über einen konkreten Bildschirm. Das ist der eigentliche Gewinn: nicht weniger Arbeit insgesamt, sondern früheres Feedback.

Für mittelständische Unternehmen ist das besonders relevant, weil dort Budget- und Freigabeentscheidungen oft von Personen getroffen werden, die keine Spezifikation lesen wollen, einen Prototyp aber in zehn Minuten bewerten können.

Toolauswahl: Die erste Weichenstellung

Die Frage, mit welchem Werkzeug gearbeitet wird, entscheidet mehr über das Ergebnis als die Formulierungskunst im Prompt. Die verfügbaren Ansätze unterscheiden sich stark darin, wie tief sie in ein bestehendes Projekt eingreifen und wie viel Kontrolle sie abgeben.

  • Chat-basierte Assistenz liefert Codefragmente, die manuell übernommen und eingeordnet werden. Volle Kontrolle, aber wenig Tempo.
  • In die Entwicklungsumgebung integrierte Assistenten arbeiten mit dem vorhandenen Projektkontext und können mehrere Dateien gleichzeitig anfassen.
  • Prototyping-Plattformen erzeugen aus einer Beschreibung direkt eine lauffähige Anwendung samt Oberfläche. Sehr schnell, dafür mit vorgegebenem Technologie-Stack.

Für einen Wegwerf-Prototyp, der eine Idee validieren soll, ist der vorgegebene Stack unproblematisch. Soll aus dem Prototyp später ein Produkt werden, wird er zur strategischen Entscheidung – und sollte als solche getroffen werden, nicht nebenbei.

Anforderungen: Der Prompt ist die neue Spezifikation

Die Erfahrung aus prompt-getriebener Arbeit lässt sich knapp zusammenfassen: Ein unpräziser Prompt erzeugt präzise das Falsche – nur eben schnell. Modelle füllen Lücken mit plausiblen Annahmen, und diese Annahmen bleiben unsichtbar, bis jemand sie prüft.

Hilfreich ist es deshalb, beim Beschreiben einer Anwendung systematisch dieselben Dimensionen abzudecken:

  1. Zweck und Nutzergruppe – wer arbeitet womit und zu welchem Zweck?
  2. Datenmodell – welche Objekte gibt es, welche Felder, welche Beziehungen?
  3. Abläufe – welche Schritte durchläuft ein Vorgang vom Anfang bis zum Ende?
  4. Randbedingungen – Technologie, Schnittstellen, Rollen und Rechte, Mehrsprachigkeit.
  5. Abgrenzung – was ausdrücklich nicht Teil des Prototyps ist.

Der letzte Punkt wird regelmäßig unterschätzt. Ohne klare Abgrenzung produzieren KI-Werkzeuge gern Funktionen, die niemand bestellt hat und die anschließend mitgepflegt oder wieder entfernt werden müssen.

Interessant ist der Nebeneffekt: Wer gute Prompts schreibt, schreibt damit auch eine brauchbare Anforderungsbeschreibung. Die Disziplin, die man ohnehin für ordentliche Projekte braucht, wird hier unmittelbar belohnt.

Prüfung: Der Schritt, der nicht entfallen darf

Generierter Code sieht fast immer überzeugend aus. Er ist formatiert, kommentiert und kompiliert häufig auf Anhieb. Genau das macht die Prüfung anspruchsvoll, denn Oberflächenqualität sagt nichts über Korrektheit aus.

Sinnvoll ist eine Prüfung auf mehreren Ebenen:

  • Funktional: Tut die Anwendung, was sie soll – auch bei unvollständigen oder fehlerhaften Eingaben?
  • Sicherheitsbezogen: Wie werden Eingaben validiert, wie werden Zugriffsrechte geprüft, wie werden Zugangsdaten abgelegt?
  • Strukturell: Ist der Code so aufgebaut, dass ein Mensch ihn in sechs Monaten noch ändern kann?
  • Rechtlich: Welche Abhängigkeiten wurden eingezogen, unter welchen Lizenzen stehen sie, wo liegen verarbeitete Daten?

Diese Prüfung setzt Fachwissen voraus. Vibe Coding ersetzt Entwicklungskompetenz nicht, es verlagert sie: weg vom Schreiben, hin zum Bewerten. Wer nicht beurteilen kann, ob eine Lösung tragfähig ist, kann auch nicht beurteilen, ob die KI eine tragfähige Lösung geliefert hat.

Prototyp ist nicht gleich Produkt

Die größte organisatorische Gefahr liegt nicht in der Technik, sondern in der Erwartungshaltung. Wenn ein Prototyp nach wenigen Tagen funktioniert, entsteht leicht der Eindruck, das Produkt sei nahezu fertig. Tatsächlich fehlen dann meist Fehlerbehandlung, Berechtigungskonzept, Barrierefreiheit, Betrieb, Monitoring und Dokumentation – also jene Anteile, die den Großteil des Aufwands in realen Projekten ausmachen.

Hilfreich ist, den Status von Anfang an zu benennen: Ein Prototyp beantwortet eine Frage. Ist die Frage beantwortet, wird entschieden, ob weitergebaut oder neu gebaut wird. Beide Wege sind legitim; unklar bleiben darf die Entscheidung nicht.

Einordnung für Web- und Softwareprojekte

Für Web- und Softwareprojekte verschiebt prompt-getriebene Entwicklung vor allem die frühe Phase: Konzeptrisiken lassen sich günstiger ausräumen, weil Annahmen schneller sichtbar werden. Gleichzeitig steigt die Anforderung an Anforderungsqualität und Review-Disziplin, denn fehlerhafte Entscheidungen skalieren jetzt ebenso schnell wie gute. Wer Vibe Coding als Werkzeug für Erkenntnisgewinn einsetzt und die Entscheidung über die Produktivarchitektur bewusst davon trennt, gewinnt Tempo, ohne technische Schulden zu übernehmen.

Quellen