Vibe Coding heisst, Software zu bauen, indem man einer KI beschreibt, was man will, und das Ergebnis zu übernehmen, ohne den Code genau zu prüfen. Für Prototypen ist das stark. Für Software mit echten Kunden, Daten oder Zahlungen braucht es zusätzlich Planung, Tests, Sicherheit und jemanden, der dafür geradesteht.
Selbsttest
Prototyp oder produktionsreif?
Zehn Aussagen, eine Orientierung. Es ist kein Sicherheitsaudit und ersetzt keine Prüfung des Codes.
Was steht auf dem Spiel? Wählen Sie, was zutrifft.
Was ist schon abgesichert? Wählen Sie, was zutrifft.
Auf dem Spiel: 0 von 6 · Abgesichert: 0 von 4
Ein Prototyp reicht vorerst
Es steht wenig auf dem Spiel. Zum Ausprobieren, Zeigen und Testen einer Idee ist ein Vibe-Coding-Prototyp das richtige Werkzeug. Sobald echte Kunden, Personendaten oder Zahlungen dazukommen, lohnt sich die Prüfung.
Mehr dazu: MVP produktionsreif machen
Vibe Coding heisst, Software zu bauen, indem man einer KI beschreibt, was man will, und das Ergebnis zu übernehmen, ohne den Code genau zu prüfen. Der Begriff stammt von Andrej Karpathy (2. Februar 2025), der es selbst für «throwaway weekend projects» geeignet hielt. Für Prototypen ist es schnell und stark. Für Software mit echten Kunden, Daten oder Zahlungen braucht es zusätzlich, was keine KI ersetzt: Planung, eine tragfähige Grundlage, Tests, Sicherheit, Betrieb und jemanden, der dafür geradesteht. KI-Unterstützung beim Entwickeln ist heute normal (90 Prozent laut DORA-Report 2025). Der Unterschied liegt nicht im Werkzeug, sondern im Prozess drumherum.
Vibe Coding und geprüfte, KI-gestützte Entwicklung im Vergleich
| Vibe Coding | KI-gestützte, geprüfte Entwicklung | |
|---|---|---|
| Wer liest den Code? | Niemand oder kaum jemand | Eine Person, jede Änderung |
| Wer entscheidet über Aufbau, Daten und Sicherheit? | Die KI, oft ohne dass jemand fragt | Ein Mensch, die KI macht Vorschläge |
| Wofür geeignet | Prototyp, Demo, Lernprojekt, Wegwerf-Werkzeug | Produkte mit Kunden, Daten und Zahlungen |
| Wer steht für das Ergebnis gerade? | Sie, ohne es zu wissen | Sie, mit nachvollziehbarer Prüfung |
Transkript lesen
Was ist Vibe Coding? Und reicht ein KI-Prototyp für echte Kunden?
Vibe Coding heisst: Sie beschreiben, was Sie wollen, die KI schreibt den Code, und Sie übernehmen das Ergebnis, ohne es genau zu prüfen. Für einen Prototyp ist das stark.
Stellen Sie sich ein Auto auf der Messe vor. Es glänzt, die Türen gehen auf, es sieht fahrbereit aus. Auf die Strasse darf es trotzdem nicht. Dafür braucht es Bremsen, eine Prüfung und jemanden, der dafür geradesteht.
Bei Software fehlt dem Prototyp meist dasselbe. Erstens: ein Plan, welche Daten wem gehören. Zweitens: Zugriffsregeln, damit niemand fremde Daten sieht. Drittens: Tests. Viertens: Backups, die jemand wirklich zurückgespielt hat. Und fünftens: eine Person, die den Code geprüft hat und dafür geradesteht.
KI gehört heute zum Entwickeln dazu. Der Unterschied ist nicht das Werkzeug, sondern ob jemand plant, prüft und die Verantwortung trägt.
Haben Sie schon einen Prototyp aus Lovable, Bolt, v0 oder Replit?
Im kostenlosen 60-Minuten-Review gehen wir 7 Punkte durch und sagen Ihnen ehrlich, ob er zu retten ist. Danach härten wir ihn in 2 bis 4 Wochen, zum Festpreis nach dem Review.
Was ist Vibe Coding?
Der Begriff geht auf einen Beitrag von Andrej Karpathy auf X vom 2. Februar 2025 zurück. Er beschrieb eine Art zu programmieren, bei der man sich ganz auf die KI einlässt und, wie er schrieb, «forget that the code even exists»: Er bestätigte alle Vorschläge, las die Änderungen nicht mehr und kopierte Fehlermeldungen ohne Kommentar zurück in die KI. Dazu schrieb er, das gehe für «throwaway weekend projects» ganz gut. Das ist die ursprüngliche, engere Bedeutung, und sie ist der Massstab dieses Ratgebers.
Seitdem ist der Begriff in die Alltagssprache gewandert. Merriam-Webster definiert «vibe coding» als den Vorgang, mit einem KI-System Computercode in einer Programmiersprache zu erzeugen. Collins Dictionary wählte es zum Wort des Jahres 2025, laut CNN am 6. November 2025. Im Alltag wird «Vibe Coding» heute oft für jede Programmierung mit KI-Hilfe benutzt. Das ist ungenau, und genau diese Ungenauigkeit ist das Problem: Wer mit KI-Unterstützung entwickelt und jede Änderung prüft, tut etwas anderes als jemand, der den Code nie liest.
Werkzeuge gibt es zwei Arten. Baukästen wie Lovable, Bolt, v0 oder Replit erzeugen aus einer Beschreibung eine lauffähige Anwendung, oft samt Datenbank und Hosting. Editoren und Agenten wie Cursor oder Claude Code schreiben Code in einem Projekt, das jemand betreut. Beide können für Vibe Coding benutzt werden, und beide können Teil einer sauberen Entwicklung sein. Entscheidend ist, was drumherum passiert.
Wofür Vibe Coding gut ist
Vibe Coding hat die Hürde gesenkt, eine Idee sichtbar zu machen. Das ist ein echter Gewinn:
- Eine Idee in Tagen zeigen: Ein klickbarer Prototyp ersetzt viele Seiten Beschreibung.
- Mit Nutzern sprechen, bevor man Geld ausgibt: Ein Prototyp ist die billigste Form, um herauszufinden, ob jemand das Produkt will.
- Interne Wegwerf-Werkzeuge: Eine Auswertung, die nur Sie brauchen und die keine fremden Daten berührt.
- Lernen und Ausprobieren: Wer verstehen will, wie Software aufgebaut ist, lernt am Ergebnis.
Wer das tut, braucht kein schlechtes Gewissen. Das Problem beginnt erst, wenn aus dem Prototyp unbemerkt ein Produkt wird: Es kommen Kunden, dann Daten, dann Zahlungen, und niemand hat dazwischen innegehalten.
Wo es aufhört: Prototyp und produktionsreife Software
Zwei Anwendungen, die auf dem Bildschirm gleich aussehen, können sich darin völlig unterscheiden, was dahinter passiert. Die Gegenüberstellung zeigt, was bei einem Prototyp meist offen ist und was bei produktionsreifer Software geklärt sein muss:
| Bereich | Prototyp (typisch beim Vibe Coding) | Produktionsreife Software |
|---|---|---|
| Zweck und Nutzer | Eine Person oder wenige, die Bescheid wissen | Echte Kunden, die sich auf die Anwendung verlassen |
| Planung | Ein Prompt, dann der nächste | Anforderungen, Rollen, Datenflüsse und Fehlerfälle sind beschrieben |
| Grundlage | Was die KI gewählt hat | Framework und Architektur sind bewusst gewählt, so dass andere Teams übernehmen können |
| Datenmodell | Entsteht nebenbei und wächst unordentlich | Geplant, nachvollziehbar, mit klarem Besitz der Daten |
| Rechte | Oft nur in der Oberfläche versteckt | Auf dem Server und in der Datenbank erzwungen, mit Tests belegt |
| Schlüssel | Oft im Code oder im Browser | Nur auf dem Server, getrennt für Entwicklung, Test und Betrieb |
| Eingaben | Werden angenommen, wie sie kommen | Auf dem Server geprüft, Anfragen begrenzt |
| Tests | Man klickt es durch | Automatisierte Tests und eine Testumgebung ohne echte Daten |
| Fehler und Ausfälle | Man merkt es, wenn jemand schreibt | Monitoring mit Alarm auf einem Kanal, den Sie lesen |
| Backups | Keine, oder nie zurückgespielt | Täglich, und einmal wirklich zurückgespielt |
| Datenschutz | Nicht bedacht | Datenflüsse bekannt, Hosting-Standort gewählt, nDSG-Dokumentation möglich |
| Verantwortung | Niemand hat den Code gelesen | Jemand hat ihn geprüft und steht dafür gerade |
Die rechte Spalte ist keine Kür. Sie ist der Unterschied zwischen einer Anwendung, die man zeigt, und einer, der man Kundendaten anvertraut.
«Die meisten entwickeln doch heute mit KI.» Ja, aber nicht als Vibe Coding
Das stimmt, und es ändert nichts am Argument. Zwei grosse Befragungen aus 2025 zeigen, wie verbreitet KI-Werkzeuge sind, und wie wenig davon Vibe Coding im strengen Sinn ist:
- Stack Overflow, Developer Survey 2025 (über 49’000 Antworten aus 177 Ländern): 84 Prozent nutzen KI-Werkzeuge oder planen es (Vorjahr: 76 Prozent), 51 Prozent der professionellen Entwickler täglich. Gleichzeitig sagen 72 Prozent, Vibe Coding sei nicht Teil ihrer Arbeit, weitere 5 Prozent schliessen es entschieden aus. Und mehr Befragte misstrauen der Genauigkeit der KI (46 Prozent) als ihr vertrauen (33 Prozent). Am häufigsten (66 Prozent) ärgern sie sich über Lösungen, die «fast richtig, aber nicht ganz» sind.
- DORA-Report 2025 von Google (knapp 5’000 Befragte): 90 Prozent nutzen KI bei der Arbeit, 30 Prozent vertrauen dem erzeugten Code wenig oder gar nicht.
Beides sind Befragungen, keine Messungen, und DORA wird von einem Anbieter von KI-Werkzeugen durchgeführt. Das Bild ist trotzdem klar: KI-Unterstützung ist Standard, ungeprüftes Übernehmen ist die Ausnahme. Wer professionell entwickelt, nutzt KI und liest trotzdem, was herauskommt.
Der DORA-Report liefert dazu den wichtigsten Satz für alle, die Software betreiben: KI beschleunigt die Entwicklung, aber sie lege Schwächen offen, die weiter hinten in der Kette liegen. Die Studie findet einen positiven Zusammenhang zwischen KI-Einsatz und Lieferleistung, aber einen negativen mit der Stabilität der Auslieferung. Ohne starke Kontrollen, etwa automatisierte Tests, saubere Versionsverwaltung und schnelle Rückmeldungen, führt mehr Änderungsvolumen zu mehr Instabilität. Das ist kein Argument gegen KI, sondern für den Prozess drumherum.
Gefühl und Messung gehen auseinander. Eine kontrollierte Studie von METR (Juli 2025) liess 16 erfahrene Open-Source-Entwickler 246 echte Aufgaben mit und ohne KI-Werkzeuge lösen. Mit KI dauerten die Aufgaben 19 Prozent länger, obwohl die Entwickler vorher 24 Prozent Zeitgewinn erwartet hatten und hinterher glaubten, 20 Prozent schneller gewesen zu sein. Das ist ein kleines Experiment mit frühen KI-Werkzeugen. METR selbst bezeichnet das Ergebnis heute als überholt und schreibt in einem Update vom Februar 2026, die neuen Daten seien ein unzuverlässiges Signal. Was bleibt, ist nur die Vorsicht: Wie schnell oder sicher etwas ist, sollte man messen und nicht fühlen. Genau dafür gibt es Tests.
Was produktionsreife Software ausmacht
Produktionsreife ist keine Eigenschaft einzelner Zeilen, sondern des ganzen Vorgehens. Sechs Bereiche machen den Unterschied zu einem Prototyp.
1. Planung: die Fragen vor dem ersten Prompt
Ein Prototyp beantwortet «Sieht es so aus?». Ein Produkt muss auch beantworten können:
- Wer benutzt die Anwendung, und welche Rollen gibt es?
- Welche Daten werden gespeichert, und wem gehören sie?
- Welche Daten sind personenbezogen oder besonders schützenswert?
- Wer darf was sehen, ändern und löschen?
- Was passiert, wenn eine Zahlung scheitert oder zweimal ausgelöst wird?
- Was passiert, wenn ein Dienst ausfällt, den die Anwendung braucht?
- Wie viele Nutzer sollen es in einem Jahr sein?
- Welche Systeme müssen angebunden werden?
- Wo müssen die Daten liegen, und wer darf darauf zugreifen?
- Wer übernimmt die Anwendung, wenn die erste Person nicht mehr da ist?
Eine KI beantwortet diese Fragen nicht von selbst, weil sie niemand gestellt hat. Jede unbeantwortete Frage ist später eine Überraschung, meist im ungünstigsten Moment.
2. Der Rahmen: Framework und Architektur wählen
Ein Framework ist das Gerüst, auf dem eine Anwendung gebaut wird. Beim Vibe Coding wählt es meist die KI, ohne dass jemand nach Alternativen fragt. Bei einem Produkt ist die Wahl eine Entscheidung mit Folgen. Gute Kriterien sind:
- Verbreitung und Pflege: Wird es breit eingesetzt und regelmässig aktualisiert, auch mit Sicherheitsupdates?
- Übernahme: Kann ein anderes Team es lesen und weiterführen, oder hängt alles an einer Person?
- Hosting: Wo kann es laufen, auch in der Schweiz, falls das verlangt ist?
- Kosten bei Wachstum: Was kostet es bei zehnmal mehr Nutzern?
- Abhängigkeit: Wie schwer ist ein Wechsel des Anbieters, falls nötig?
- Passung: Löst es Ihre Aufgabe, oder biegt man die Aufgabe zurecht?
Wichtiger als das einzelne Framework ist die Frage, was später teuer zu ändern ist: das Datenmodell, die Anmeldung, die Trennung mehrerer Kunden auf einer Software, der Hosting-Standort und der Zahlungsanbieter. Diese Dinge entscheidet man früh und bewusst. Die Oberfläche lässt sich dagegen fast jederzeit ändern.
3. Rechte und Sicherheit
Besonders folgenreich ist fehlende Zugriffskontrolle. Die OWASP-Liste der kritischsten Risiken für Webanwendungen führt «Broken Access Control», also Nutzer, die Dinge tun können, die ihnen nicht erlaubt sind, in den Ausgaben 2021 und 2025 auf Platz 1. Praktisch heisst das:
- Rechte gehören auf den Server und in die Datenbank. Eine Schaltfläche im Frontend auszublenden ist keine Berechtigung. Wer die Anfrage selbst abschickt, umgeht sie.
- Zugriffsregeln in der Datenbank (Row-Level-Security) legen fest, welche Zeilen wer lesen darf. Tests müssen belegen, dass fremde Daten unlesbar sind.
- Schlüssel gehören auf den Server. Ein Zugangsschlüssel im Browser ist für jeden lesbar, der die Seite öffnet. Entwicklung, Test und Betrieb brauchen getrennte Schlüssel.
- Eingaben prüfen, Anfragen begrenzen. Der Server darf keiner Eingabe trauen, und jeder Endpunkt braucht eine Obergrenze.
Als Massstab gibt es öffentliche Standards: den OWASP Application Security Verification Standard (ASVS, Version 5.0.0 vom 30. Mai 2025) mit drei Stufen, wobei die erste die Mindestanforderungen enthält und die zweite für die meisten Anwendungen empfohlen wird, und das Secure Software Development Framework des US-Instituts NIST (SP 800-218, Version 1.1 vom Februar 2022). Beide sind Empfehlungen, keine Zertifikate.
4. Tests
Ein Test ist ein kleines Programm, das prüft, ob ein anderes Programm tut, was es soll. Er ist das Sicherheitsnetz, das bei jeder Änderung prüft, ob etwas anderes kaputtgegangen ist. Es gibt vier Ebenen:
- Einzelne Funktionen: Stimmt die Berechnung, greift die Regel?
- Zusammenspiel: Funktionieren Anmeldung, Datenbank und Zahlung gemeinsam?
- Abläufe von Anfang bis Ende: Kann ein Kunde sich anmelden, bestellen und eine Rechnung erhalten?
- Sicherheit: Kann Nutzer A die Daten von Nutzer B lesen? Die Antwort muss ein Test geben, nicht eine Vermutung.
Dazu gehört eine Testumgebung, die der echten gleicht, aber keine echten Kundendaten enthält. Jede Änderung läuft zuerst dort. So wird ein Update zu einem Routinevorgang statt zu einem Ereignis. Die DORA-Studie nennt automatisierte Tests ausdrücklich als Gegengewicht zur Instabilität, die mehr Änderungsvolumen mit sich bringt.
5. Betrieb
Software ist nicht fertig, wenn sie läuft, sondern wenn man sie betreiben kann:
- Backups, die jemand zurückgespielt hat. Ein Backup, das nie wiederhergestellt wurde, ist keins. Man spielt es einmal zurück und hält fest, wie lange es dauert.
- Monitoring mit Alarm. Fehler und Ausfälle melden sich bei Ihnen auf einem Kanal, den Sie tatsächlich lesen, bevor Kunden anrufen.
- Getrennte Umgebungen. Entwicklung, Test und echter Betrieb dürfen nicht dieselbe Datenbank teilen. Ein Fall aus 2025 zeigt, warum (siehe unten).
- Updates. Betriebssysteme, Bibliotheken und Dienste ändern sich. Wer nicht nachzieht, sammelt bekannte Lücken.
6. Verantwortung und Übergabe
Am Ende zählt die Frage, wer für die Anwendung geradesteht. Jemand muss den Code gelesen haben, erklären können, wie die Anwendung funktioniert, und die Verantwortung für das Ergebnis tragen. Zur Übergabe gehören Code, Konten und Zugänge, damit ein anderes Team weiterarbeiten kann, und eine Struktur, die man verstehen kann. Eine KI kann Code schreiben, aber sie kann nicht haften und nicht antworten, wenn ein Kunde nachfragt.
Was schiefgehen kann: belegte Fälle
Die folgenden Fälle sind öffentlich dokumentiert. Es sind Einzelfälle und Angaben von Herstellern oder Forschern, keine Marktzahlen: Sie zeigen, was passieren kann, nicht wie oft.
- Lovable, März 2025: Der Sicherheitsforscher Matt Palmer untersuchte 1’645 Projekte aus dem Lovable-Showcase. Bei 170 davon (rund 10,3 Prozent) fand er unzureichende Zugriffsregeln in der Datenbank, über die auch Namen, Telefonnummern und Zahlungsangaben abrufbar waren. Er prüfte nur die Startseiten der Projekte. Daraus entstand der Eintrag CVE-2025-48757 (veröffentlicht Ende Mai 2025), den der Hersteller bestreitet: Jeder Kunde sei selbst für den Schutz seiner Daten verantwortlich.
- Moltbook, Februar 2026: Die Sicherheitsfirma Wiz fand bei dieser Plattform, deren Gründer sagte, er habe keine einzige Zeile Code selbst geschrieben, eine Datenbank mit vollem Lese- und Schreibzugriff: 1,5 Millionen API-Schlüssel, 35’000 E-Mail-Adressen und private Nachrichten waren offen. Ursache war ein Schlüssel im Browser-Code und fehlende Row-Level-Security. Nach der Meldung wurde die Lücke innert Stunden geschlossen. Wiz verkauft Cloud-Sicherheit.
- Replit, Juli 2025: Der KI-Agent von Replit löschte bei einem Experiment des SaaStr-Gründers Jason Lemkin die Produktionsdatenbank, obwohl ein Code-Freeze galt (The Register, 21. Juli 2025). Es war eine Demo-App, und die Wiederherstellung gelang am Ende, obwohl der Agent sie zuerst für unmöglich erklärt hatte. Laut heise lagen damals Vorschau, Test und Produktion in derselben Datenbank; Replit kündigte danach die Trennung an.
- Veracode, Juli 2025: In einem Test mit 80 Aufgaben und über 100 Modellen enthielt der KI-Code in 45 Prozent der Fälle Sicherheitslücken. Das ist ein Benchmark für das Vervollständigen von Code, kein Mass für ganze Projekte, und Veracode verkauft Sicherheitssoftware.
- Stanford, 2022: In einer Studie von Perry, Srivastava, Kumar und Boneh schrieben Teilnehmende mit einem KI-Assistenten deutlich weniger sicheren Code und hielten ihn eher für sicher. Das war ein Experiment mit einem älteren Modell und sagt nichts über heutige Werkzeuge. Es zeigt aber ein Muster: Wer der KI vertraut, prüft weniger.
Gemeinsam ist den Fällen nicht die KI, sondern das Fehlen dessen, was oben beschrieben ist: Zugriffsregeln, getrennte Umgebungen, Prüfung, Verantwortung.
Sicherheit und Recht in der Schweiz
Wer Personendaten bearbeitet, unterliegt dem Schweizer Datenschutzgesetz (DSG, in Kraft seit 1. September 2023). Drei Artikel sind für Software wichtig:
- Art. 8: Der Verantwortliche und der Auftragsbearbeiter gewährleisten durch geeignete technische und organisatorische Massnahmen eine dem Risiko angemessene Datensicherheit. Der Bundesrat legt Mindestanforderungen fest.
- Art. 24: Eine Verletzung der Datensicherheit, die voraussichtlich zu einem hohen Risiko für die betroffenen Personen führt, ist dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten so rasch als möglich zu melden. Eine feste Stundenfrist nennt das Gesetz nicht.
- Art. 61 Bst. c: Wer vorsätzlich die Mindestanforderungen an die Datensicherheit nicht einhält, kann auf Antrag mit einer Busse bis 250’000 Franken bestraft werden. Die Busse richtet sich gegen private Personen. In Geschäftsbetrieben trifft sie nach dem Verwaltungsstrafrecht grundsätzlich die handelnden und verantwortlichen Personen, nur bei Bussen bis 50’000 Franken kann stattdessen das Unternehmen zahlen.
Die Datenschutzverordnung (DSV, Art. 1 bis 3) nennt, was «angemessen» heisst: den Schutzbedarf der Daten bestimmen, das Risiko beurteilen und Massnahmen festlegen. Genannt werden unter anderem Zugriffskontrolle, Wiederherstellung nach einem Zwischenfall, Systemsicherheit mit aktueller Software, Eingabekontrolle und das rasche Erkennen von Verletzungen. Mehrere dieser Punkte, etwa Zugriffskontrolle, Wiederherstellung und das rasche Erkennen von Verletzungen, entsprechen Punkten aus unserem Review.
Zwei Einschränkungen gehören dazu. Erstens ist das keine Rechtsberatung: Welche Verordnungsartikel «Mindestanforderungen» im Sinn von Art. 61 sind, ist eine Rechtsfrage, und die Strafbarkeit setzt Vorsatz und einen Strafantrag voraus. Zweitens ändert die Rechtslage nichts am Kern: Ein Prototyp, der Kundendaten ohne Zugriffsregeln speichert, ist ein Risiko für Ihre Kunden, lange bevor er ein Bussgeld ist.
KI-gestützt entwickeln, aber richtig
Wer KI beim Entwickeln einsetzt und trotzdem ein verlässliches Produkt will, hält sich in professionellen Teams an einige Regeln:
- Erst planen, dann bauen lassen. Anforderungen, Rollen und Datenflüsse stehen, bevor die KI loslegt.
- Die Grundlage bewusst wählen. Framework, Datenmodell und Hosting sind Entscheide eines Menschen.
- In kleinen Schritten arbeiten. Kleine Änderungen lassen sich prüfen, grosse nicht.
- Jede Änderung lesen. Ein Mensch versteht, was geändert wurde, und lehnt ab, was er nicht versteht.
- Tests als Sicherheitsnetz. Automatisierte Tests laufen bei jeder Änderung, auch die für Zugriffsregeln.
- Getrennte Umgebungen. Weder Agent noch Entwickler arbeiten am echten Betrieb, bevor die Änderung getestet ist.
- Keine Geheimnisse in der Anfrage. Zugangsschlüssel gehören nicht in Prompts oder in den Code.
- Einer ist verantwortlich. Es steht fest, wer für das Ergebnis geradesteht.
Das sind keine Geheimrezepte, sondern Grundregeln guter Softwareentwicklung. Ob ein Anbieter oder ein Team sie einhält, lässt sich fragen und am Ergebnis prüfen: Gibt es Tests? Wurde ein Backup zurückgespielt? Wer hat den Code gelesen?
Prototyp behalten oder neu bauen?
Das hängt vom Zustand der Grundlage ab. Spricht das Datenmodell die Sprache Ihres Geschäfts, ist der Umfang überschaubar und lassen sich die Lücken einzeln benennen, ist Härten meist der kürzere Weg. Zieht sich das Fehlen von Struktur und Sicherheit durch die ganze Anwendung, ist ein Neubau günstiger und sicherer. Was Sie am Prototyp gelernt haben, bleibt in beiden Fällen: Abläufe, Bildschirme und die Fragen der ersten Nutzer sind die beste Vorlage für die saubere Version.
Die Details zu dieser Entscheidung, zu den sieben Prüfpunkten und zu den Preisen stehen auf der Seite Vibe-Coding-Projekt produktionsreif machen.
Was wir anbieten
Haben Sie einen Prototyp aus Lovable, Bolt, v0, Replit oder einem anderen KI-Werkzeug, der ernst genommen werden soll? Im kostenlosen 60-Minuten-Review gehen wir sieben Punkte durch: Zugriffsregeln, Rollen, Schlüssel, Eingaben, Backups, Monitoring und Testumgebung. Sie bekommen eine schriftliche Liste, die bei Ihnen bleibt, auch wenn Sie danach nichts bei uns machen. Ist das Projekt nicht zu retten, sagen wir das in der ersten Stunde.
Danach härten wir es in 2 bis 4 Wochen, auf Ihrem Stack, in Ihren Konten und an Ihrem Code, zu einem Festpreis, den wir nach dem Review nennen. Code und Konten gehören mit der vollständigen Bezahlung Ihnen (AGB, Ziffer 12). Wäre ein Neubau besser, gelten die veröffentlichten Einstiegspreise: Plattform oder Webportal ab CHF 25’000, native App ab CHF 19’000, Progressive Web App ab CHF 9’800. Mehr zu den Kosten steht im Ratgeber Was kostet App-Entwicklung in der Schweiz? und bei SaaS Entwicklung.
Das Review ist kein Penetrationstest und keine Garantie. Es ist ein ehrlicher Blick in Projekt und Code entlang von sieben Punkten.
Vibe Coding ist ein gutes Werkzeug für Prototypen und ein schlechter Ersatz für Planung, Tests und Verantwortung. KI gehört heute zum Entwickeln dazu. Ob etwas ein Produkt ist, entscheidet nicht das Werkzeug, sondern ob jemand es geprüft hat und dafür geradesteht.
Quellen und Stand
Alle Angaben Dritter stammen von deren eigenen Seiten und wurden am 31.10.2026 gelesen. Sie können sich ändern; prüfen Sie die Quelle, bevor Sie sich auf eine Zahl stützen.
- Begriff: Andrej Karpathy auf X, 2.2.2025, Merriam-Webster «vibe coding», CNN zu Collins Word of the Year 2025
- Verbreitung: Stack Overflow Developer Survey 2025, KI, Google Cloud: DORA-Report 2025
- Messung: METR, Juli 2025 und METR, Update Februar 2026
- Sicherheit von KI-Code: Veracode, GenAI Code Security Report 2025, Perry et al., Stanford (arXiv)
- Fälle: Matt Palmer, Statement on CVE-2025-48757, NVD: CVE-2025-48757, Wiz: Moltbook, The Register: Replit, heise: Replit
- Recht: Datenschutzgesetz (DSG), Fedlex, Datenschutzverordnung (DSV), Fedlex, Verwaltungsstrafrecht (VStrR), Fedlex
- Standards: OWASP Top 10, OWASP ASVS, NIST SP 800-218 (SSDF)
Läuft Ihr Prototyp schon, und kommen die ersten echten Kunden? Buchen Sie das kostenlose Review. Sie bekommen eine schriftliche Liste und eine ehrliche Antwort, ob Härten oder Neubau der bessere Weg ist.
