Vibe Coding mit dem Google AI Studio: In diese Fallen kann man tappen

Vibe Coding, also das (Web-)Programmieren ohne Programmierkenntnisse, funktioniert. Aber: Als Nicht-Coder kommt man von der ersten Idee bis zum Aufspielen der fertigen „App“ auf einen Server an viele Stellen, an denen es echt haarig wird.

Hier sind, ohne Anspruch auf Vollständigkeit, einige üble Fallen. Diese sind mir speziell mit dem Google AI Studio (LLM: Gemini 3.1 Pro Preview) aufgefallen. Das ist hier ist also kein „WOW VIBE CODING IST GENIAL DAS ÄNDERT ALLES“ Artikel als jubelndes Vibe Coding Tutorial, sondern eine Auflistung einiger echter Alltagsprobleme, die den Vibe killen können.

Im Bild oben siehst du einen Screenshot aus dem Google AI Studio, Bereich „Apps“. Ich habe eine Art Bildbearbeitung gebaut, mit der man speziell Layouts für Instagram erstellen kann. Ja, Freemium-Apps können das auch (und besser), aber ich wollte auch testen, wie weit man mit Vibe Coding kommt und welche erwartbaren und überraschenden Hürden es so gibt.

Du denkst, die Vibe-Coding-KI wäre ein guter Softwarearchitekt. Ist sie nicht.

Vibe Coding zeigt hervorragend auf, wie wichtig Softwarearchitektur ist. Weil es sich damit von Haus aus, im Fall des Google AI Studios, schwer tut.
Oder anders gesagt: Die Abwesenheit von Softwarearchitektur kann dir um die Ohren fliegen.

Bevor man sich also eine Art App baut, sollte man auch bei Just-for-fun-Projekten ein paar Leitplanken festlegen:

• Technologiestack: React oder Vue? Next.js? Was anderes? Wenn du nichts vorgibst, wird sich Gemini bspw. für React entscheiden, abhängig von deinem Vorhaben.
• Responsive Design: funktioniert manchmal, manchmal nicht. Verlasse dich nicht drauf. Wenn du ein Design brauchst, das auch auf Smartphones funktionieren muss, solltest du das zu Beginn einprompten.
• Cloud ja oder nein: Soll das Projekt letztlich als App in der Cloud laufen, oder soll es eine Desktop-App werden? Das ist eine wichtige Grundfrage und betrifft dann auch den weiteren Punkt Datenspeicherung weiter unten.
• Ordner- und Codestruktur: Ohne Vorgaben bastelt sich Gemini was zusammen. Das kann OK sein, muss es aber nicht. Prompte mit ein, dass du eine sinnvolle Struktur haben willst.
• Gemini legt nicht von Haus aus eine AGENTS.md bzw. PROJECT_MEMORY.md an. Das ist aber sinnvoll. Prompte die Erstellung dieser Dateien direkt zu Beginn mit rein. Mit diesen beiden Dateien kann sich die – in der Tat vergessliche – KI merken, was sie eigentlich so treibt bzw. löst bzw. verbockt. Dort kannst du selbst nachsehen, ob unkluge Lösungen implementiert sind.
  Beispiel-Inhalte: Vision / Architectural Decisions Record (ADR) / Integrations & APIs / Data Model / DAM Architecture / Feature-Definitionen / Quirks & Best Practices / Workflows & Use Cases / Feature Backlog / Deployment & Build / Current Status
  ABER: Gemini erinnert sich nicht automatisch daran, dass eine Project Memory gibt. Du könntest ausprobieren, in den „Instructions“ reinzuschreiben, dass der Project Memory beachtet werden muss. Was auch funktioniert: Zwischendurch öfter prompten, dass es die PROJECT_MEMORY.md gibt, dann „gewöhnt“ sich das System daran, die Datei „freiwillig“ zu nutzen.
• Datenspeicherung: Sollen Daten gespeichert werden? Dann musst du nachdenken, welche Daten das sind, und wie groß sie sind. Texte etc. lassen sich gut in einer Firebase-Datenbank speichern (im Google-Universum ist das ganz praktisch, ist aber „Vendor Lock-in“). Größere Roh-Dateien (Bilder, Videos, Dokumente…) sollten in einen Cloud-Speicher.
  Sinnvoll ist es, sich über die Datenbankstruktur vorher Gedanken zu machen. Triff diese Entscheidung zu Beginn des Projekts, und lege ggf. eine zum Projekt passende Datenbank neu an.
  Achtung: Firebase Security Rules! Hurra, deine Datenbank ist in der Cloud, und jeder kann drauf zugreifen. Soll auch jeder reinschauen und rumpfuschen dürfen (bspw. Hacker?)? Nein. Du musst also Sicherheitsregeln festlegen. Wenn man da Fehler macht, ist die Datenbank offen für alle.
• Brauchst du Logins? Was sehr gut funktioniert, ist in Apps die Login-Möglichkeit per Google-Account einzubauen. Aber: Dann kann sich jeder mit Google-Account einloggen. Ups. Du musst dir also Gedanken machen, wie die Authentifizierung gelingt. Was auf die Schnelle funktioniert ist ein einfacher Nicht-Zwei-Factor-Login mit E-Mail-Adresse und Passwort. Du kannst einprompten, dass deine App neue User zwar erstmal akzeptiert, du diese dann aber manuell im Backend freischalten musst (Whitelist-Funktion). Stelle dich auf weiteren Hirnschmalz-Bedarf ein, wie Hacker-Schutz (bspw. reCAPTCHA).
• Brauchst du Mehrmandantenfähigkeit? Beispiel: User A soll nicht sehen, was User B so in der App treibt (und abspeichert). Also brauchst du möglicherweise getrennte „Kundenbereiche“. Prompte das zu Beginn mit rein.
• Frontend und Backend: Es ist deine App, also willst du wahrscheinlich der Super-Admin sein und Einstellungen vornehmen, und zwar in der App und nicht ständig im Quelltext. Also brauchst du ein Backend. Das solltest du direkt zu Beginn einbriefen: Ich brauche ein Frontend und ein Backend.
• Rollenkonzept: Mit dem Thema Backend sind wir schon beim Thema Rollenkonzept. Wer darf was in deiner App machen? Willst du der Super-Admin sein? Gibt es Kunden-Admins? Redakteure? Prompte ein, wie du das Rollenkonzept haben willst.
• Brauche ich jetzt oder in Zukunft Mehrsprachigkeit? Dann dürfen Interface-Texte, Buttontexte, Pop-up-Texte etc. NICHT hardgecodet werden. Du brauchst also bspw. eine Datei namens LanguageContent.tsx, in der als „Single Source of Truth“ alle Texte enthalten sind (das ist nicht unbedingt Best Practice, aber in jedem Fall besser als nix). Heißt: Du musst im Basis-Architektur-Prompt vorgeben, wie du das Sprachenmanagement haben willst.
• Sicherheit: Gut am Google AI Studio ist, dass „Credentials“, also geheime Zugangsdaten, API-Keys etc., „ab Werk“ (meistens) sinnvoll und sicher gemangt werden. Trotzdem kann das System Böcke schießen, im Tandem mit deinen Böcken. Beispiel: Du lässt eine AGENTS.md anlegen. Gemini schreibt deine E-Mail-Adresse als Super-Admin-Zugang hart gecodet in die Datei rein. Du schiebst dein Projekt auf GitHub und stellst es „öffentlich“. Dann kann JEDER sehen, welche E-Mail-Adresse der Super-Admin hat. Für sowas bekommst du keine Warnung. Ebenso kann es sein, dass dir schlimme Sicherheitsmängel nicht auffallen werden.

Bugs, Bugs, Bugs

Wer findet Bugs? Wahrscheinlich du. Weißt du, wie das geht?
Wenn nein: Teste einfach, wie ein normaler neugieriger User, nach jedem Prompt-Durchlauf die Funktionen durch und schreibe dir auf, was kaputt ist, bzw. „was unerwartetes Verhalten“ ist. Du kannst Gemini auch bitten, Tests zu erstellen und durchlaufen zu lassen. Aufs Ergebnis verlassen solltest du dich nicht.
Wenn du fit mit Bugs bist: Wenn du einen Bug findest und willst, dass er behoben wird, wird dir Gemini danach möglicherweise sagen, dass jetzt alles Tippitoppi ist. Das kann stimmen, das kann halb stimmen, und das kann gelogen sein. Beispiel: Du hast an einer Stelle gesehen, dass in der App ein Dateispeicherungs-Dialog einen Fehler hat (= zeigt keine Ordner an o.ä.). Du lässt es an dieser Stelle reparieren. An den anderen Stellen wird der Fehler aber bleiben, wenn es blöd läuft. Du musst jedes Feature gründlich checken. Und es kann sein, dass Gemini funktionierende Features irgendwann kaputt macht. Häufige Änderungen haben den Effekt, dass an Stelle A Lösung A gecodet wurde, und Stelle B Lösung B. Also uneinheitlich. Horror. Im Grunde ist ein Murks-Projekt irgendwann reif für ein Refactoring, also eine Kernsanierung des Codes. Da kommt man dann in Probleme wie Versionierung etc. rein; wenn der Code danach neu ist, können neue Bugs drin stecken. Fass ohne Boden!

Fehlerbehandlung, Logging / Monitoring sind noch mal ein ganz eigener Schnack. Grobe Bugs beim Ausführen der App bemerkt Gemini und bietet an, diese zu beheben. Das funktioniert gut. Die vielen kleinen Fehler musst du selbst in der Konsole nachsehen (Chrome, Windows: Control – Shift – I).

Schreib dir Tickets auf

Du bist für dein Projekt der Product Owner, unter anderem. Du musst dir also überlegen, welche Aufgaben die liebe KI als Nächstes machen soll. Das können neue Features sein, oder die Behebung von Fehlern.

Problem: Es gibt viel zu tun.

Mache dir deshalb eine Liste mit To-Dos. Im einfachsten Fall tut es ein Word-Dokument, Hauptsache irgendwas Speicherbares.

Dann priorisierst du die nächsten Schritte. Ich würde zur Empfehlung neigen, dass du Bugfixes priorisieren solltest. Sofern du Bugs findest. Denn mit jedem neuen Feature kommen neue Bugs dazu. So wird dann aus einer Liste von 5 Bugs auf einmal eine Liste von 10 Bugs, und diese werden schwerer behebbar, weil dein Projekt größer ist als vorher.

Und denke auf keinen Fall, dass du dir deine nächsten Schritte merken kannst. Denn bei komplexeren Projekten ist es möglich, dass nach der Eingabe deines Prompts Gemini 40 Minuten arbeitet! Und nach den 40 Minuten ist nicht Ende, da kommt dann evtl. „The task timed out, retry“. Also nochmal. Und dann ist es möglich, dass kein Kontingent für Generierungen für den Tag aufgebraucht ist. Bis morgen hast du dann vergessen, was du im Anschluss tun wolltest.
(Die Time-outs treten teils „schon“ nach 5 oder 25 Minuten auf. Immerhin macht die KI nach dem „Retry“ nahtlos weiter, die Time-outs sind also nicht megaschlimm. Wenn der Time-out allerdings mitten im Optimieren von Dateien auftrat, können erstmal Funktionen der App – oder die komplette App – geschrottet sein).

Du denkst, du könntest endlos rumspielen. Kannst du nicht.

Am Anfang ist man mit Google Gemini im AI Studio relativ stark begrenzt, in Bezug auf „wie viele Wünsche kann ich der KI einbriefen“. Zuerst wird das „free quota“ verbraten, dann kannst du zwar über einen eigenen API-Key noch nachlegen, aber irgendwann ist Schluss für den Tag. Der Grund: Zu Beginn ist man in Tier 1, da limitiert Google den Zugang zu den Premium LLMs (bspw. Gemini 3.1 Pro Preview im Max mode…) auf wenige Requests am Tag. Erst nachdem man „echte“ 100 Dollar ausgegeben hat (= abgebucht bei dir, Betrag kann sich ändern), kommst du in den nächsten Tier. Das ist zumindest der Stand beim Schreiben des Artikels, das kann sich aber jederzeit ohne Vorwarnung ändern.

Ein weiterer Punkt ist das „Context Window“: Je mehr Arbeit im Projekt drinsteckt, desto weniger weiß die KI, womit es anfing. Eine AGENTS.md etc. helfen, aber komplett sicher kannst du dir nie sein, dass die KI sich an alles „erinnert“.

Du denkst, die KI würde dich nicht anlügen. Tut sie aber.

Beispiel: Ich habe eine Art Cloud-Layout-Software „gebastelt“. Sie funktioniert sogar ganz gut, als eine Art One-Trick-Pony-Layout-Generator für Instagram-Posts (inklusive KI-Assistent zur Caption-Generierung). Heißt: Es geht auch um den Upload von Bildern (heißt: Bilder müssen in der Cloud gespeichert werden) und das Erstellen bzw. Bearbeiten von Layouts (heißt: die Layouts müssen in einer Datenbank oder einem Cloud-Storage gespeichert werden).

Problem: Gemini will per default nicht komplett auf Firebase, die Hyperscaler-Cloud-Datenbank-und-Storage-Lösung von Google zugreifen. Gemini will oft nur mit der Datenbank umgehen, obwohl es natürlich Storage nutzen kann (du kannst mit Firebase Storage bspw. ein Digital Asset Management bauen…). Was passiert also? Die KI baut einen Upload in die App ein, verkauft es dem User als Storage, schreibt aber in Wahrheit die Bilder in hochkomprimierter Form in die Datenbank rein. Und lügt dich frech an. Das ist ein No-Go. Diesen Fehler muss man selbst erkennen und fixen lassen. Das beginnt dann damit, dass man in Firebase zuerst manuell den Storage aktivieren muss, bzw. dass du beim Prompt explizit vorgibst, dass du Storage nutzen willst. Gemini hilft dir dann weiter, das klappt gut.

Du denkst, Vibe Coding kostet nix. Falsch.

Mit dem Google AI Studio gibt es fürs Vibe Coding zwar a) ein Startguthaben für Erstnutzer für die KI-Nutzung (sind um die 250 Dollar, kann sich ändern) und b) ein Startguthaben für APIs und c) ein Gratiskontingent für Serverleistungen (Speicherplatz, Datenbank), aber das reicht auf Dauer nicht. Wenn du eine echte App baust, wartest (Bug Fixes, neue Features…) und betreibst (Datenbankzugriffe, Cloudspeicher-Gebühren), kommen laufende Kosten auf dich zu.

Bei einem größeren Projekt kann dich ein einzelner Prompt (bzw. die Ergebnisse daraus) gut und gerne 2 bis 3 Euro kosten, wenn du aus dem Free Quota für den Tag raus bist und deinen API-Key nutzt. Monatliche laufende Zusatz-Kosten einer deployten App zwischen 0 und 50++ Euro sind möglich, also ganz grober Eindruck, dass es keinen „free Lunch“ gibt. Du weißt auch nicht, ob Google seine Gratis-Angebote irgendwann mal zurückfahren (oder ausbauen) wird. Extra-Kosten kommen dazu, wenn du einen API-Key für Generative KI hinterlegst, das kann – wenn du pfiffige, unbedarfte oder böse User hast – mehrere hundert Euro kosten. Am Tag. Abhilfe schaffen Nutzungslimits (die sind recht neu für die Gemini API). Da kannst du bspw. ein Maximalbudget für den Key von 100 Euro im Monat festlegen. Wenn du dann ans Limit kommst, bekommst du eine Mail von Google. Wenn das Budget aufgebraucht ist, funktioniert die KI nicht mehr.

„Free Quota“ resettet sich wirklich erst am nächsten Tag. Das kann bspw. 16 Stunden Zwangspause bedeuten. Wenn du das Generierungs-Limit mit deinem API-Key auch aufgebraucht hast, ist einfach Feierabend.

Du denkst, der Code reicht. Falsch, du willst ihn noch „deployen“.

Glückwunsch, du hast eine lustige oder praktische App gebaut, just for you. Doch wie bekommst du sie auf einen „echten“ Server? Bei Google ist das mit „Cloud Run“ recht einfach, denn diese Export-Möglichkeit ist im AI Studio eingebaut. Das funktioniert robust! Weniger robust ist der Export zu GitHub (bei mir hakt der ständig). Über GitHub könntest du dann bspw. auch über Vercel deployen o.ä. Vercel hat einige Fans, da im Grunde deine Änderungen in GitHub automatisch deployt werden können.

Tipp, wenn der GitHub-Sync hakt: Du kannst dein Projekt als .zip-Datei exportieren.

So geht es: Klicke im Google AI Studio im rechten Fenster, also der Vorschau der App, in der oberen Leiste auf „Code“ (im Normalfall hast du „Preview“ aktiviert).

Erst dann werden rechts zwei weitere Icons sichtbar, ein Download-Icon und ein Zahnrad. Ein Klick auf das Download-Icon ermöglich den Download des gesamten Projekts als .zip-Datei. Diese kannst du manuell bei GitHub hochladen. Das ist a) ein super Backup, b) kannst du das Projekt in anderen Tools öffnen (bspw. VS Code), oder c) eine andere KI (bspw. Claude) drüberlaufen lassen. Wenn du dann aber einmal komplett aus dem AI Studio „ausgebrochen“ bist und deinen Code woanders bearbeitest, liegt dein Code an zwei Stellen. Nicht lustig, aber irgendwas ist immer.

Nach dem Deployen über Google:

Die URL ist grausam, sowas wie app122345454.us-west.run.app. Wenn die App unter deiner URL erreichbar sein soll, musst du in die DNS-Records deiner Domain reinkommen können. Das ist schon echtes Admin-Gedöns. Dann kannst du bspw. meineapp.meinedomain.de auf die Web-App umleiten.

Eine Alternative ist es, lokal laufende Apps zu bauen (für die Windows-Welt: .exe Dateien). Das geht. Schau dir Tutorials im Netz an. Dumm ist es, wenn deine App dann auf eine Cloud-Datenbank angewiesen ist. Dann ist der Umbau des Codes nicht ganz trivial. Sowas muss man sich vorher überlegen.

Deployment = neue Bugs

Während im Google AI Studio „Safe Space“ alles läuft (gut, nicht alles läuft: deine App-Preview ist in einem iFrame, da gehen manche Dialoge und Pop-ups nicht, die in der deployten App gehen würden), kann es in der Version auf deinem Server zu Problemen kommen. Beispiele: Abhängigkeiten fehlen, Credentials bzw. Umgebungsvariablen kaputt, Datenbankanbindung defekt, Fehlkonfigurationen, etc.

Mein Vorschlag: Deploye bereits frühe Versionen deiner App, damit du solche Fehler früh entdeckst. Wenn die App noch „leichtgewichtig“ ist, ist es leichter solche Probleme zu beheben.

DSGVO

Üble Sache, der Themenkomplex ist für diesen Artikel viel zu umfangreich. Wo stehen die Server? Wie werden Dateien gespeichert? Wie lange? Was passiert, wenn User ihren Account löschen („Recht auf Löschung“ etc.).
Bei Google kannst du in der Regel auch EU-Server fürs Hosting wählen, aber das kostet Aufpreis. Und du musst es aktiv wollen und an den richtigen Stellen die richtigen Vorgaben machen. Wenn du generative KI einbaust, kommen weitere Anforderungen dazu (EU AI Act).

Backups

In Google Firebase sind Backups nicht automatisch aktiviert. Du musst dir also – manuell – ein Backup-Konzept überlegen (gut, man muss Backups einfach nur aktivieren, aber trotzdem).

Wem gehört der Code?

Da du den Code nicht geschrieben hast, weißt du nicht, was Google genutzt hat, und ob damit Urheberrechte oder (Trivial-)Patente verletzt werden. Genauso problematisch: Open-Source-Bibliotheken bzw. Dependencies. Solche Lizenzen (bspw. GPL) können verlangen, dass dein kompletter Code ebenfalls Open Source sein muss. Andere, wie MIT, sind lockerer, erfordern aber eine Namensnennung.
Für eine Hobby-App hinter einem harten Login für Family & Friends ist das möglicherweise nicht schlimm, für kommerzielle Apps wird es dann „schwierig“.

Fazit

Vibe Coding macht Spaß, denn du wirst lernen, wie Software funktioniert. Wir alle nutzen Software, aber die meisten Leute verstehen sie nicht. Für den Hobby-Gebrauch kann man sich als ambitionierter Laie durchaus sinnvolle Lösungen bauen lassen. Für den kommerziellen Einsatz, speziell wenn Laien am Werk sind, würde ich von Vibe Coding abraten. Kritisch sollte man auch als User sein: vibe-gecodete Apps können Fehler und Sicherheitslücken haben, aber die stehen nirgends. Man muss also wachsam bleiben: Wem gebe ich meine Daten?