Was ist Vibe Coding? Die einfache Erklärung — und das Kapitel, das die Ratgeber auslassen

Jedes Vibe-Coding-Tool, egal wie es sich vermarktet, fährt eine Version derselben Schleife: beschreiben → erzeugen → ausführen → reagieren. Du schreibst „eine Checkliste, in der sich die Einträge nach Frist sortieren“; der Agent plant die Änderung, schreibt den Code über so viele Dateien wie nötig, kompiliert das Projekt, sieht dieselben Fehler, die ein Programmierer sehen würde, behebt sie und zeigt dir ein laufendes Ergebnis. Dein nächster Satz — „die überfälligen sollen rot sein“ — wiederholt den Zyklus gegen alles, was schon gebaut ist.

Drei Dinge unter der Haube entscheiden, ob diese Schleife etwas Gutes produziert, und es lohnt sich, sie zu kennen, weil sie jeden Qualitätsunterschied zwischen Tools erklären:

Kontext. Der Agent kann nur respektieren, was er sehen kann — deine früheren Entscheidungen, den vorhandenen Code, das Designsystem. Die Tools unterscheiden sich enorm darin, wie viel sie sich merken und wie sie auswählen, was sie anschauen.

Struktur. Verlang Funktionen eine nach der anderen ohne Plan, und der Agent improvisiert pro Prompt eine Architektur — für eine Demo in Ordnung, bei Funktion zwanzig ein Problem, das sich aufgetürmt hat. Tools, die Struktur vorab festlegen (oder dich festlegen lassen), produzieren Code, der brauchbar bleibt.

Verifikation. Die besten Tools geben dir keinen Code, der funktionieren sollte; sie kompilieren ihn, führen ihn aus, testen ihn und beheben ihre eigenen Fehler, bevor du etwas siehst. Der Unterschied zwischen „erzeugt Code“ und „liefert Software“ wohnt fast vollständig hier. Selbst Apple hat Agents in Xcode eingebaut, die durch Build-und-Fix-Schleifen iterieren — das ist inzwischen der Standard, nicht die Ausnahme.

Beachte, was in dieser Liste fehlt: deine Fähigkeit zu programmieren. Was die Schleife tatsächlich verbraucht, ist deine Fähigkeit, präzise zu beschreiben und ehrlich zu reagieren — und deshalb haben Produktleute schneller den Dreh raus als alle anderen. Aufzuschreiben, was existieren soll, Szenario für Szenario, war schon vorher der Job. Wie ein Agent daraus konkret eine App mit KI erstellt — kompilieren, Fehler beheben, wieder bauen — steht in unserem Ratgeber dazu.

Gut, heute: von der Idee zur laufenden Software in einer Sitzung; billig iterieren (der „noch mal anders“-Versuch, der früher den Nachmittag eines Entwicklers kostete, kostet jetzt einen Satz); Standard-Produktoberflächen — Screens, Formulare, Listen, Konten, Zahlungen gegen verwaltete Backends; und die Person mit dem Produkturteil direkt bauen lassen, statt durch Ebenen hindurch zu briefen.

Scheitert noch, ehrlich gesagt: Arbeit ohne beschreibbare Spezifikation (wenn du nicht sagen kannst, wie „richtig“ aussieht, kann es der Agent auch nicht); wirklich neue Algorithmen und ungewöhnliche Systemprogrammierung; eine große alte Codebasis retten, die er nicht selbst gebaut hat; und fehlendes Produktdenken kompensieren — ein Agent verstärkt die Qualität von Entscheidungen in beide Richtungen.

Und ein Fehlermodus gehört dem Nutzer, nicht den Tools: eine Demo mit einem Produkt verwechseln. Jedes Tool auf dieser Seite liefert dir an einem Nachmittag eine beeindruckende Demo. Produkte brauchen zusätzlich Struktur, die Funktion zwanzig überlebt, Konten, die funktionieren, Daten, die bleiben, Updates, die rausgehen, und Code, der dir gehört. In dieser zweiten Hälfte unterscheiden sich die Tools viel stärker als in der Demo-Geschwindigkeit — und das bringt uns zur Landkarte.

Die meisten Listen sortieren nach Geschwindigkeit und Politur. Sortiere stattdessen nach dem Ergebnis — was das, was du beschreibst, tatsächlich wird — und der ganze Markt zerfällt in fünf Gruppen. (Keine Preise hier: Sie ändern sich, und jeder Anbieter veröffentlicht seine eigenen. Die Frage, die du stellen solltest, ist immer dieselbe: In welchem Tarif kann ich veröffentlichen und den Code mitnehmen? Für den deutschen Markt haben wir die Baukästen und KI-Tools im Vergleich einzeln angeschaut.)

Web-Builder — Ergebnis: Web-Apps. Lovable ist die Referenz: React-Apps, GitHub-Sync, Backend bei Supabase. v0 von Vercel und Bolt spielen dasselbe Spiel. Für Web-Produkte sind sie wirklich veröffentlichungsreif; für Prototypen von allem sind sie hervorragend.

Prototyp-Tools — Ergebnis: interaktive Wegwerf-Demos. Figma Make lebt im Design-Ökosystem und ist ehrlich darüber, was es ist: zum Erkunden gebaut, nicht zum Veröffentlichen.

Coding-Agents, bring deine eigene KI — Ergebnis: was immer du steuern kannst. Claude Code, Cline, Aider: Agents, die in einer echten Codebasis mit deinem eigenen Abo oder API-Key arbeiten. Maximale Freiheit, keine Leitplanken — großartig für Entwickler, und der Weg, auf dem Produktleute am dringendsten die Struktur brauchen, die die nächste Gruppe eingebaut hat.

Mobile-Builder — Ergebnis: Handy-Apps, mit einer Gabelung innerhalb der Gruppe, die die meisten Listen nie erwähnen. Rork, Vibecode und RapidNative erzeugen React Native/Expo — plattformübergreifendes JavaScript, das über eine Brücke auf dem Handy läuft, meist in Credits abgerechnet. FlutterFlow setzt Flutter-Apps visuell zusammen. Und Modaal (unseres) erzeugt echten plattformnativen Code — Swift/SwiftUI fürs iPhone, Kotlin/Jetpack Compose für Android, beides aus einem Projekt — mit einem Plan, den du vor jeder Funktion freigibst, dem Code auf deiner eigenen Festplatte und unbegrenzten Prompts im kostenlosen Tarif. Warum diese Gabelung wichtig ist, ist das nächste Kapitel — denn es ist der Teil von Vibe Coding, den die Ratgeber ständig überspringen.

Hier ist die seltsame Lücke in jedem bisher veröffentlichten Vibe-Coding-Ratgeber, auf Deutsch wie auf Englisch: Sie erklären die Schleife, listen die Tools, zeigen eine Web-Demo — und hören beim Handy auf. „Mobile“ taucht, wenn überhaupt, als „deine Web-App läuft auch im Handy-Browser“ auf. Für alle, deren Produkt auf einen Homescreen gehört, versteckt dieser Satz die drei Fakten, die am meisten zählen:

1. Eine Website auf dem Handy ist keine App. Push-Benachrichtigungen, Offline-Nutzung, Kamera und Sensoren, Widgets, die Uhr und die Zahlungswege der Stores gehören zu echten Apps. Der Schnelltest: Kommen deine Nutzer, indem sie auf einen Link klicken — oder indem sie ein Icon öffnen?

2. Deine vibe-gecodete Web-App in eine Hülle zu packen, überbrückt die Lücke nicht. Die naheliegende Abkürzung — die Web-App in eine app-förmige Schale stecken — läuft in Apples Review, das dünne Hüllen um Websites regelmäßig ablehnt, und in jede Einschränkung von oben, weil die App weiterhin eine verkleidete Website ist.

3. Die Lücke ist jetzt mit derselben Fähigkeit überbrückbar. Das hat sich geändert, und das haben die Ratgeber noch nicht eingeholt: Die Beschreiben-und-Iterieren-Schleife produziert jetzt echten nativen Code. In Modaals Version ist die Schleife absichtlich strukturierter als beim Web-Vibe-Coding — ein Produktdokument, wenn das Projekt startet, und für jede Funktion schreibt der Agent zuerst einen prüfbaren Plan (Szenarien, Vorgehen, Risiken, Tests) und baut erst, nachdem du ihn freigegeben hast; das Ergebnis ist Swift und Kotlin, das ein Plattform-Entwickler wiedererkennt, kompiliert und getestet, auf deiner Festplatte. Vibe Coding, bei dem die Improvisation durch Spezifikationen ersetzt ist — genau die Anpassung, die produktionsreifen Output möglich macht.

Die praktische Konsequenz: Der Web-Weg und der Mobile-Weg beginnen jetzt gleich — mit einer Beschreibung — und müssen nicht mehr in einem Neubau enden. Etwas auf Lovable validiert, das sich als App entpuppt hat? Das Backend überlebt den Umzug meistens; die Vorderseite wird eine echte native App, beschrieben in derselben Sprache, die du für den Prototyp benutzt hast. Fängst du bei null mit einem Handy-Produkt an, geht App erstellen: der komplette Weg alle Schritte durch, Vibe Coding eingeschlossen — und die Android-Variante den Weg bis in den Play Store.

Die Einstiegsrampe für eine Sitzung, in der Reihenfolge, die die klassischen Fehler vermeidet:

1. Such dir etwas Echtes, aber Kleines. Nicht das Flaggschiff deiner Firma — ein Werkzeug, das du selbst willst. Das Lernen steckt in der Schleife, und kleine Dinge drehen schneller.

2. Schreib fünf Sätze, bevor du ein Tool anfasst. Was es tut; drei Szenarien „Nutzer macht X, sieht Y“; was Version 1 absichtlich weglässt. Das ist der Unterschied zwischen Steuern und Treiben — und die Gewohnheit, die später bis in die Produktion skaliert.

3. Wähl das Tool nach dem Ergebnis, nicht nach der Demo. Web-Produkt → Web-Builder. Handy-Produkt → ein Tool mit Mobile-Ergebnis (und entscheide bewusst zwischen nativ und plattformübergreifend). Nur erkunden → irgendeins, guten Gewissens.

4. Reagiere präzise. „Falsch“ lehrt den Agenten nichts; „der Button gehört nach unten, in Daumenreichweite“ erledigt es in einem Durchgang. Du briefst den Agenten so, wie du einen sehr wörtlichen, sehr schnellen Entwickler briefen würdest — eine Fähigkeit, die Produktleute schon haben.

5. Iteriere früh auf einem echten Gerät, wenn das Produkt mobil ist — der Simulator ist höflich, Daumen sind ehrlich.

Anfangen kostet nichts, was ins Gewicht fällt: Die Web-Builder haben kostenlose Tarife, und Modaals kostenloser Tarif ist ein komplettes Projekt mit unbegrenzten Prompts; Pro kostet 9 € pro Monat bei jährlicher Zahlung — die Details stehen auf der Preisseite. Was das Ganze wirklich kostet, mit jeder Zahl nachprüfbar, steht in App entwickeln: Kosten — und ob du überhaupt selbst bauen oder lieber entwickeln lassen solltest, ist eine eigene, ehrliche Rechnung. Die knappe Ressource ist dieselbe wie immer — zu wissen, was du bauen willst. Die Tools haben nur aufgehört, das zu verstecken.