Vibe Coding und unterstütztes Prototyping: Was diese Praxis erlaubt und was nicht

Überarbeitete Notiz vom 25. Mai 2026. Ursprünglich im März 2026 veröffentlicht — vollständige Überarbeitung.

Der Begriff Vibe Coding wurde zu Beginn des Jahres 2025 popularisiert — die Formulierung wird in mehreren öffentlichen Publikationen dieser Zeit Andrej Karpathy zugeschrieben —, um eine Entwicklungspraxis zu beschreiben, in der die in natürlicher Sprache ausgedrückte Absicht dem Verfassen des Codes vorausgeht. Die Entwicklerin oder der Entwickler beschreibt, was sie oder er erreichen möchte — eine Funktion, ein Verhalten, eine Oberfläche — und ein durch ein generatives Modell gespeistes System produziert die entsprechende Implementierung, die die Entwicklerin oder der Entwickler überprüft und anpasst.

Diese Praxis hat innerhalb weniger Monate eine im Verhältnis zu ihrer tatsächlichen Tragweite überdimensionierte öffentliche Debatte ausgelöst. Für die einen kündigt sie das Ende der Softwareentwicklung an, wie wir sie kennen. Für die anderen offenbart sie eine neue Kategorie beispielloser technischer Schuld. Die beobachtbare Realität liegt zwischen beiden. Vibe Coding transformiert die Prototyping-Phase tatsächlich und substanziell. Es entbindet hingegen nicht von der softwarebezogenen Produktionsdisziplin, wenn es darum geht, den Prototyp in ein Produkt zu verwandeln, und das Vermischen der beiden Phasen führt zu kostspieligen Abwägungen.

Was Vibe Coding im Prototyping ermöglicht

Software-Prototyping ist konstruktionsbedingt eine Erkundungstätigkeit. Es zielt nicht darauf ab, ein fertiges Produkt zu liefern, sondern zu validieren, dass eine Idee — ein User Journey, eine Geschäftslogik, ein Integrationsmechanismus — in der Praxis funktioniert. Das Erfolgskriterium eines Prototyps ist, dass er es erlaubt zu entscheiden, ob der Aufwand fortgesetzt werden soll oder nicht.

Unter dieser Erkundungsfinalität eröffnet Vibe Coding drei operative Fähigkeiten.

Die Iterationsgeschwindigkeit zuerst. Ein Prototyp, der einer einzelnen Entwicklerin oder einem einzelnen Entwickler mehrere Wochen abverlangte, kann heute in wenigen Tagen, bei einfachen Konzepten manchmal in wenigen Stunden produziert werden. Diese Komprimierung des Ideenzyklus verändert die Ökonomie des Hypothesentests: Was zu kostspielig war, um validiert zu werden, wird testbar.

Die Zugänglichkeit für nicht-entwicklungsorientierte Profile danach. Eine Produktverantwortliche oder ein Produktverantwortlicher, eine Beratende oder ein Berater, eine Geschäftsanalystin oder ein Geschäftsanalyst kann einen funktionalen Prototyp produzieren, der seine Absicht konkret ausdrückt, ohne den Filter eines technischen Teams. Diese Autonomie der Erkundungsphase befreit Zeit der Entwicklerinnen und Entwickler für Tätigkeiten, bei denen ihre Expertise unersetzlich ist.

Die Variantenexploration schliesslich. Wo ein Prototyp pro Variante substanziellen Aufwand verlangte, wird es möglich, mehrere Versionen desselben Konzepts parallel zu produzieren, sie kurz zu testen und jene zu behalten, die der Konfrontation mit der Realität am besten standhält. Diese Pluralität verändert die Qualität der Produktentscheidungen.

Was Vibe Coding nicht transformiert

Jenseits der Grenze des Prototyps bleiben drei Zonen den Versprechen des Vibe Coding weitgehend fremd.

Die unsichtbare technische Schuld zuerst. Ein im iterativen Dialog mit einem generativen System erzeugter Code funktioniert oft, aber seine architektonische Kohärenz ist nicht garantiert. Wenn die Entwicklerin oder der Entwickler keine klare Sicht auf das hat, was zusammengesetzt wurde, kompliziert jede weitere Ergänzung das Ganze, ohne dass es bemerkt wird. Diese Schuld häuft sich still an, und ihre Kosten offenbaren sich in dem Moment, in dem der Prototyp zu einem Produkt werden sollte — also in dem Moment, in dem es zu spät ist, sie ohne substanzielle Neuschrift zu korrigieren.

Die Anwendungssicherheit danach. Ein durch Vibe Coding erzeugter Code funktioniert standardmässig auf dem nominalen Pfad. Er behandelt nicht systematisch die Fehlerfälle, die Injektionen, die Berechtigungen, die Grenzbedingungen — alle Zonen, in denen sich die Anwendungssicherheit entscheidet. Für einen intern in geschlossenem Kreis getesteten Prototyp ist diese Einschränkung akzeptabel. Für ein an reale Nutzer ausgesetztes Produkt stellt sie ein Risiko dar, das keine zusätzliche Prompt-Iteration korrigiert.

Die regulatorische Konformität schliesslich. Die regulierten Branchen in der Schweiz — Finanzen, Gesundheit, Versicherungen — verlangen eine Rückverfolgbarkeit des erzeugten Codes, die in einem Vibe-Coding-Ansatz nicht natürlich ist. Die Erzeugungsprozesse sind wenig deterministisch, die technischen Entscheidungen sind selten ausdrücklich dokumentiert, die Reviews sind konstruktionsbedingt leichter. Keiner dieser Punkte ist für das Prototyping ein Ausschlussgrund, alle werden es für die Produktivsetzung.

Die Abwägungsregel, die Ernsthaftigkeit von Improvisation unterscheidet

Aus dieser Unterscheidung ergibt sich eine einfache und strukturierende Abwägungsregel. Vibe Coding ist das geeignete Werkzeug, um zu validieren, dass eine Idee es wert ist, gebaut zu werden. Es ist nicht das Werkzeug, um sie anschliessend zu bauen. Diese Unterscheidung ist kein Zugeständnis an die Vorsicht — sie ist die wirksamste Verwendung der Praxis selbst.

Die Teams, die mit dieser Praxis am erfolgreichsten sind, sind jene, die diese Trennung übernehmen. Sie prototypisieren schnell im Vibe Coding, sie validieren, was im Prototyp zu validieren ist, dann bauen sie sauber neu auf, was seinen Wert nachgewiesen hat. Die Teams, die der Versuchung erliegen, den Prototyp in Produktion zu behalten, häufen eine Schuld an, die sich in den darauffolgenden sechs bis zwölf Monaten als kostspielig erweist.

Die Kontexte, in denen Vibe Coding nicht hingehört, auch nicht zum Prototyping

Vier Situationen schliessen die Verwendung von Vibe Coding selbst für die Erkundungsphase aus.

Das Prototyping mit echten Daten zuerst. Wenn ein Prototyp echte Kundendaten, identifizierbare Finanz- oder Gesundheitsinformationen verarbeitet, weist der erzeugte Code Risiken von Lecks oder schlechter Verwaltung auf, die das absorbieren, was der Prototypstatus zulässt. Die minimale Disziplin besteht darin, fiktive oder anonymisierte Daten in einer isolierten Umgebung zu verwenden, unabhängig von der Geschwindigkeit, die Vibe Coding sonst bietet.

Das öffentlich exponierte Prototyping danach. Ein für öffentliche Tests ohne Zugangskontrolle online gestellter Prototyp ist kein Prototyp mehr: Es ist eine Produktivsetzung ohne entsprechende Strenge. Diese Verwechslung zwischen interner Mockup und öffentlichem Einsatz ist der häufigste operative Fehler, der bei Teams beobachtet wird, die Vibe Coding ohne Rahmen übernehmen.

Das Prototyping, das Produktivsysteme berührt schliesslich. Wenn der Prototyp sich mit einem bestehenden Managementsystem, einer geschäftlichen Datenbank oder einer kritischen API verbindet, kann ein durch generativen Dialog erzeugter Bug reale Konsequenzen haben. Die praktische Regel besteht darin, den Prototyp in einer getrennten Umgebung ohne direkten Zugriff auf die operativen Systeme einzuschliessen.

Das Prototyping ohne menschliche Korrekturlesung vervollständigt die Liste. Vibe Coding ohne jemanden, der den erzeugten Code bewerten kann, bevor er einer Nutzerin oder einem Nutzer, einer Investorin oder einem Investor oder einer Kundin oder einem Kunden gezeigt wird, ist riskant. Die Review muss nicht schwer sein, aber sie ist notwendig — jemand muss sagen können, ob das Ergebnis trägt, unabhängig davon, wer es produziert hat.

Die Disziplin, die seriöse Praxis auszeichnet

Über die Ausschlusskontexte hinaus zeichnen drei Praktiken die Teams aus, die dauerhaften Wert aus dem Vibe Coding ziehen.

Die klare Trennung zwischen Prototyp und Produktion zuerst. Wenn ein im Vibe Coding erkundetes Konzept validiert ist, wird es sauber neu aufgebaut, mit der Architektur-, Test- und Review-Strenge, die seriöse Softwarearbeit auszeichnet. Diese Disziplin ist kein Rückschritt, sondern die normale Nutzung eines Prototyps: Er demonstriert, er dient nicht.

Die Dokumentation wirksamer Prompts danach. Wenn ein iterativer Dialog ein Qualitätsergebnis produziert, verdient die Spur dieses Dialogs erhalten zu bleiben. Sie stellt ein Methodenkapital dar, das mit der Praxis weitergegeben und verbessert wird, statt eines impliziten Wissens, das sich mit der Zeit verflüchtigt.

Die Einrichtung eines Governance-Rahmens vervollständigt die Liste. Für eine Organisation, die Vibe Coding über eine individuelle Nutzung hinaus übernimmt, vermeidet die ausdrückliche Definition dessen, was auf diese Weise prototypisiert werden kann und was zu einer eingerahmten Entwicklung gehört, Abdriftungen. Diese Klärung baut sich in wenigen Wochen auf und bewahrt die Organisation vor improvisierten Abwägungen.

Die tatsächliche Tragweite ohne die Mythologie

Vibe Coding ersetzt die Softwareentwicklung nicht. Es verlagert die Grenze zwischen Erkundung und Konstruktion. Diese Grenze hat sich zu einer schnelleren und zugänglicheren Erkundung verschoben, was es zu ergreifen lohnt. Sie hat die Strenge, die der Aufbau eines seriösen Softwareprodukts verlangt, nicht verlagert.

Für ein Schweizer KMU, das diese Praxis übernimmt, ist die Frage nicht technisch. Sie ist eine Frage der Rahmenfestlegung. Ein Team, das Prototyp und Produkt klar unterscheidet, das auch bei Prototypen eine minimale Review-Disziplin aufrechterhält und das das, was die Erkundung validiert hat, sauber neu aufbauen kann, gewinnt tatsächlich an Geschwindigkeit in seiner Fähigkeit, Ideen in Softwarevermögen zu verwandeln. Ein Team, das die beiden Zeiten verwechselt, das in Produktion bringt, was Prototyp bleiben sollte, häuft eine Schuld an, die keine spätere Prompt-Iteration korrigiert.

Vibe Coding ist ein Werkzeug. Wie jedes Werkzeug hängt sein Wert vom Gebrauch ab, der ihm zuteil wird, und von der Klarheit, mit der seine Grenzen gesetzt werden.

Jérôme Deshaie ist CEO der MCVA Consulting SA, Schweizer Kanzlei für strategische Beratung in künstlicher Intelligenz mit Sitz im Wallis.