Mit KI prototypisieren: was Vibe Coding wirklich wert ist

Mit KI zu prototypisieren lohnt sich sehr – vorausgesetzt, man weiss, was man am Ende in der Hand hält. Vibe Coding, jene Praxis, bei der man in natürlicher Sprache beschreibt, was die Software tun soll, und ein Modell den Code produziert, komprimiert die Erkundung von mehreren Wochen auf wenige Tage. Was dabei entsteht, bleibt ein Prototyp: perfekt zum Entscheiden, ungeeignet, um Kunden zu bedienen. Der gesamte Wert der Praxis liegt in dieser Unterscheidung.

Artikel veröffentlicht im März 2026, überarbeitet am 25. Mai 2026, überprüft am 7. Juli 2026.

Vibe Coding, Definition ohne Mythologie

Vibe Coding bezeichnet eine Entwicklungspraxis, bei der die in natürlicher Sprache ausgedrückte Absicht dem Code vorausgeht: Man beschreibt die erwartete Funktionalität, ein von einem generativen Modell gespeistes System produziert die Implementierung, man überprüft sie und passt sie an. Der Begriff verbreitete sich Anfang 2025 – die Formulierung wird einem führenden KI-Forscher zugeschrieben – und löste eine öffentliche Debatte aus, die in keinem Verhältnis zu seiner tatsächlichen Tragweite steht.

Für die einen das Ende der Softwareentwicklung. Für die anderen eine neuartige Kategorie technischer Schuld. Die beobachtbare Realität liegt dazwischen: Die Prototyping-Phase wird tiefgreifend verändert, die Produktionsdisziplin nicht, und die beiden zu verwechseln kostet teuer.

Was sich ändert, wenn man eine Idee testet

Ein Prototyp hat nur ein Ziel: zu entscheiden, ob eine Idee den Bauaufwand wert ist. Nach diesem Kriterium verändert Vibe Coding die Lage bei Geschwindigkeit, Zugang und Vielfalt. Die Geschwindigkeit: ein Prototyp, der einem einzelnen Entwickler mehrere Wochen abverlangte, entsteht in wenigen Tagen, manchmal wenigen Stunden für ein einfaches Konzept – was zu teuer war, um validiert zu werden, wird testbar. Der Zugang: ein Produktmanager, ein Berater, ein Fachanalyst kann einen funktionierenden Prototyp erstellen, der seine Absicht konkret ausdrückt, ohne den Filter eines technischen Teams durchlaufen zu müssen. Die Vielfalt: mehrere Varianten desselben Konzepts parallel zu produzieren und diejenige zu behalten, die der Konfrontation mit der Realität standhält, wird erschwinglich, was die Qualität von Produktentscheidungen verändert.

Ich spreche aus direkter Erfahrung. FiscalDoc, die lokale Anwendung, die meine Steuerangelegenheiten verwaltet, entstand genau so: beschrieben, im Dialog erarbeitet, in drei Abenden angepasst. Die Geschichte ist veröffentlicht in FiscalDoc, oder ein SaaS durch lokale KI ersetzen, und die von mir genutzte Ausstattung wird in meinem Erfahrungsbericht zu Claude Code beschrieben.

Was der Prototyp Ihnen nicht gibt

Drei Bereiche bleiben den Versprechen von Vibe Coding fremd, und sie kosten teuer, wenn man sie ignoriert.

Zunächst die unsichtbare Schuld. Ein durch iterativen Dialog produzierter Code funktioniert oft, aber seine Gesamtkohärenz wird von niemandem garantiert. Jede Ergänzung verkompliziert das Ganze still und leise, und die Kosten zeigen sich genau in dem Moment, in dem der Prototyp zum Produkt werden sollte – also zu spät, um ohne substanzielle Neuschreibung korrigiert zu werden.

Dann die Sicherheit. Der generierte Code funktioniert auf dem Standardpfad; Fehlerfälle, Injektionen, Berechtigungen, Grenzbedingungen – alles, was die Anwendungssicherheit ausmacht – wird nicht systematisch behandelt. Akzeptabel für ein Modell, das in einer geschlossenen Umgebung getestet wird. Gefährlich vor echten Nutzern.

Schliesslich die Konformität. Regulierte Schweizer Branchen – Finanzen, Gesundheit, Versicherung – verlangen eine Nachvollziehbarkeit technischer Entscheidungen, die die dialogische Generierung nicht natürlich erzeugt: wenig deterministische Prozesse, selten dokumentierte Entscheidungen, konstruktionsbedingt lockere Reviews. Für einen Prototyp nichts Ausschliessendes; in der Produktion wird alles dazu.

Die Entscheidungsregel: validieren damit, bauen ohne

Die Regel, die ich anwende, besteht aus zwei Sätzen. Vibe Coding ist das geeignete Werkzeug, um zu validieren, dass eine Idee es verdient, gebaut zu werden; es ist nicht das Werkzeug, um sie anschliessend zu bauen. Diese Unterscheidung ist kein Zugeständnis an die Vorsicht: Es ist die effizienteste Nutzung der Praxis selbst.

Die Teams, die den grössten Nutzen daraus ziehen, prototypisieren schnell, validieren, was validiert werden muss, und bauen dann sauber neu auf, was seinen Wert bewiesen hat – Architektur, Tests, Review. Jene, die den Prototyp in die Produktion drängen, häufen eine Schuld an, die sich in den folgenden Monaten rächt und die keine zusätzliche Prompt-Iteration zurückzahlt. Der saubere Neuaufbau wiederum gehört zu einer gerahmten Individualentwicklung: Das ist ein anderes Arbeitsregime, mit einem anderen Anspruchsniveau.

Vier Situationen, in denen ich nicht einmal prototypisiere

Selbst zum Erkunden fallen manche Kontexte aus dem Rahmen.

• Echte Daten. Ein Prototyp, der identifizierbare Kunden-, Finanz- oder medizinische Daten verarbeitet, übersteigt, was der Prototypenstatus absorbiert. Fiktive oder anonymisierte Daten, isolierte Umgebung – ohne Ausnahme.
• Öffentliche Exposition. Ein Online-Prototyp ohne Zugangskontrolle ist eine Inbetriebnahme ohne die entsprechende Sorgfalt. Das ist der häufigste operative Fehler bei Teams, die die Praxis ohne Rahmung übernehmen.
• Eine Verbindung zu Ihren Produktionssystemen. Verbunden mit Ihrer Verwaltung, einer Fachdatenbank oder einer kritischen API, hat ein Prototypen-Bug reale Konsequenzen. Getrennte Umgebung, immer.
• Fehlende Überprüfung. Niemand zeigt einem Kunden, einem Investor oder einem Nutzer einen Prototyp, ohne dass eine kompetente Person hätte sagen können, ob das Ergebnis trägt.

Und FiscalDoc, dann?

Man könnte mir entgegenhalten, dass FiscalDoc, ein in drei Abenden im Dialog entstandener Prototyp, bei mir noch täglich läuft. Das stimmt, und der Umfang erklärt alles: ein Nutzer – ich –, meine eigenen Daten, eine lokale Maschine, keine Netzwerkexposition, keine Daten Dritter. Genau das ist der Umfang, in dem ein Prototyp lange leben kann. An dem Tag, an dem ein solches Werkzeug jemand anderem als seinem Autor dienen sollte, wird es mit Produktionsdisziplin neu gebaut.

Wenden Sie denselben Test auf Ihre Prototypen an: Wenn ihr Umfang diesem ähnelt, können sie leben; wenn nicht, bauen Sie neu, bevor die Schuld für Sie entscheidet.

Was das in Ihrer Organisation erfordert

Für ein Schweizer KMU ist die Herausforderung weniger technisch als eine Frage der Rahmung. Definieren Sie explizit, was in Vibe Coding prototypisiert werden kann und was einer betreuten Entwicklung bedarf – diese Klärung entsteht in wenigen Wochen und vermeidet improvisierte Entscheidungen. Bewahren Sie die Dialoge auf, die gute Ergebnisse hervorgebracht haben: Das ist ein Methodenkapital, das weitergegeben werden kann, statt eines stillschweigenden Wissens, das sich verflüchtigt.

Und verbinden Sie die Praxis mit Ihren tatsächlichen Prioritäten. Ein Prototyp ist nur so viel wert, wie er eine wichtige Hypothese testet, was voraussetzt, dass Sie zuvor Ihre Abläufe und Ihre Automatisierungsvorhaben festgelegt haben. Für die Reihenfolge dieser Vorhaben findet sich der allgemeine Rahmen in Was muss ein Schweizer KMU 2026 in Sachen KI tun?.

Wichtig in Kürze

— Vibe Coding komprimiert die Erkundung: Was Wochen dauerte, wird in wenigen Tagen getestet, auch ohne technisches Profil. — Was es produziert, bleibt ein Prototyp: unsichtbare Schuld, Sicherheit und Nachvollziehbarkeit schliessen eine direkte Produktivsetzung aus. — Mit dem Prototyp validieren, sauber neu bauen, was sich bewährt hat: Die Regel besteht aus einem Satz.

FAQ

Kann ein Nicht-Entwickler wirklich allein prototypisieren? Ja, um zu erkunden und eine Absicht auszudrücken: Der daraus entstehende Prototyp ist mehr wert als ein abstraktes Pflichtenheft, weil er getestet werden kann. Bevor man ihn ausserhalb des Teams zeigt oder mit irgendetwas verbindet, bleibt eine Überprüfung durch eine kompetente Person notwendig.

Kann man einen Prototyp in Produktion behalten? Nur wenn sein Umfang der eines Prototyps bleibt: ein einzelner Nutzer oder ein geschlossener Kreis, nicht sensible Daten, keine öffentliche Exposition, keine Verbindung zu Ihren kritischen Systemen. Sobald eine dieser Mauern fällt, ist der Neuaufbau unumgänglich. FiscalDoc lebt bei mir genau deshalb, weil es diese Grenzen respektiert.

Wie viel kostet ein KI-unterstützter Prototyp? Intern oft nur wenige Arbeitstage, wo früher Wochen nötig waren – das ist der Kern des Gewinns. Bei einem Mandat hängt der Betrag vom Umfang ab: Verlangen Sie einen schriftlich festgehaltenen Umfang und einen Festpreis vor dem Start, und seien Sie misstrauisch bei einem Prototyp, der als fertiges Produkt verkauft wird.

Was ist der Unterschied zwischen Vibe Coding und KI-unterstützter Entwicklung? Vibe Coding zielt auf Erkundung ab: Die Absicht geht dem Code voraus, die Review ist reduziert, das Ergebnis ist prinzipiell wegwerfbar. Die KI-unterstützte Entwicklung bewahrt die Produktionsdisziplin – Architektur, Tests, systematische Review – und nutzt KI als Ausführungsbeschleuniger. Gleiche Werkzeugfamilie, zwei unterschiedliche Arbeitsregime.

Und Ihre wartenden Ideen? Die KI-Nutzungsdiagnose: sechzig Minuten, um Ihre realen Abläufe festzulegen, zu identifizieren, was eine Individuallösung verdient, was in SaaS bleibt, und was gar keine KI braucht. Diagnose buchen

Jérôme Deshaie ist CEO und Gründer von MCVA Consulting SA, einer augmentierten Agentur mit Sitz im Wallis. Fünfzehn Jahre im Dienst grosser internationaler Marken, heute direkt im Einsatz für Schweizer KMU. Werdegang.