Ein (halber) Tag im Leben eines Vibecoders

Vier Stunden Vibe-Coding mit Lovable – ein Erfahrungsbericht zwischen Wow-Effekt, Warnsignalen und Wirklichkeit.

Vor einigen Monaten bat mich ein ehemaliger Kunde um Unterstützung. Er plante den Schritt in die Selbstständigkeit und wollte im Rahmen seines Businessplans eine grobe Kosteneinschätzung für eine eigene Website inklusive App. Der Einsatz von Standardlösungen kam für ihn aus verschiedenen Gründen nicht infrage. Nachdem wir seine Anforderungen in ein, zwei Runden durchgesprochen hatten, nannte ich ihm – eher konservativ geschätzt – einen Betrag von 60.000 bis 80.000 Euro für eine solide entwickelte, barrierefreie, SEO-optimierte Webanwendung mit Integration in relevante Umsysteme.

Die Summe überraschte ihn. Verständlich – viel Geld für ein Startup, das zu diesem Zeitpunkt noch nicht einmal offiziell gegründet war.

Gerade in solchen Situationen wirken die zahlreichen Vibe-Coding-Plattformen, die aktuell wie Pilze aus dem Boden schießen, besonders verlockend. Vibe-Coding ist ein von Andrej Karpathy – ehemaliger KI-Chef von Tesla und Mitgründer von OpenAI – geprägtes Konzept (Quelle bei X): Man beschreibt in natürlicher Sprache, was man bauen möchte, und ein großes Sprachmodell generiert direkt lauffähigen Code. Der Code selbst wird meist nicht wirklich verstanden – man folgt dem „Vibe“, iteriert in schnellen Feedbackschleifen. Eine faszinierende Vorstellung, besonders für Gründer ohne technisches Know-how.

Ein prominentes Beispiel für eine solche Plattform ist das schwedische Start-up Lovable: Nur drei Monate nach seiner Gründung Ende 2023 zählte es nach eigenen Angaben bereits 30.000 Abonnenten und erzielte einen jährlich wiederkehrenden Umsatz (Annual Recurring Revenue, ARR) von 17 Millionen Dollar (Handelsblatt). Keine fünf Monate später legte Lovable noch einmal nach – und wurde zum jüngsten Software-Unternehmen aller Zeiten, das die Marke von 100 Millionen Dollar ARR durchbrach (Tech.eu).

Aber ich gebe auch zu: Ich stehe dem konkreten Thema Vibe-Coding eher skeptisch gegenüber. Vielleicht, weil es niemand gern hört – und noch weniger gern zugibt –, dass das, was man selbst jahrelang gelernt, gelehrt und beruflich begleitet hat, plötzlich von einer Maschine besser, schneller und billiger erledigt werden könnte. Aber: Ist diese Skepsis berechtigt? Oder doch nur verletzter Entwicklerstolz?

Um genau das herauszufinden – um meiner Skepsis entweder ein solides Fundament zu geben oder es ihr zu entziehen – habe ich mich in ein kleines Offsite zurückgezogen. Für einen halben Tag bin ich selbst zum Vibecoder geworden: kein Editor, keine Zeile selbstgeschriebener Code. Nur ich, ein Use Case, ein KI-Tool – und vier Stunden Zeit.

Und genau von diesem halben Tag im Leben eines Vibecoders möchte ich euch jetzt erzählen.

Der Usecase

Ein reales Kundenprojekt schied allein schon aus Sicherheitsgründen aus – also musste ein internes Vorhaben her, das auch über meinen kleinen Proof of Concept hinaus einen echten Mehrwert bringt. Gleichzeitig sollte das Szenario überschaubar genug sein, um Lovable eine realistische Chance zu geben, aber auch nicht zu trivial – idealerweise mit mindestens einem integrierten Umsystem.

Die Wahl fiel schnell auf einen Profilgenerator. Bei neuen oder freiberuflichen Berater:innen entsteht regelmäßig Aufwand, ihren Lebenslauf oder ihre Projekthistorie in unser internes Standardformat zu überführen. Intern nutzen wir bereits intensiv Google Gemini, das sich gut dafür eignen sollte, Informationen aus Lebensläufen zu extrahieren und ansprechend aufzubereiten. Wenn das Ergebnis anschließend auch noch automatisch in Google Docs abgelegt wird, haben wir einen Use Case mit zwei Systemintegrationen – bei gleichzeitig klar umrissenen Ziel.

Klingt fair für mich.

Eine kurze Vorbereitung

Eine erste Prompt zur Profilerstellung war schnell geschrieben – und funktionierte überraschend gut. Das Zauberwort lautete: Few-Shot-Prompting. Auch die Einrichtung von Lovable war unkompliziert: Innerhalb von fünf Minuten war ich startklar und hatte für 25 $ im Monat das Pro-Abo abgeschlossen, inklusive 100 Credits. Insgesamt habe ich während meiner vier Stunden rund 130 Credits verbraucht und 50 € ausgegeben.

Das Creditsystem von Loveable

Zur Nutzung von Lovable braucht man sogenannte Credits. Unabhängig von der Version (auch in free) erhält man täglich 5 Credits (jedoch nur maximal 30 kostenlose Credits im Monat). Jede Anfrage kostet – abhängig von ihrer Komplexität – unterschiedlich viele Credits. Lovable gibt dazu eingängige Beispiele:

• Button-Farbe ändern: 0,5 Credits
• Footer entfernen: 0,9 Credits
• Neue Landingpage mit Bildern erstellen: 1,7 Credits
  

Zur Erinnerung: Im Pro-Abo erhält man 4 Credits pro Euro. Buttonfarbe ändern kostet also 0,13$, Aufbau einer Landingpage 0,43$. Nach jeder Aktion zeigt Lovable transparent an, wie viele Credits sie gekostet hat. Der initiale Aufbau meines Profilgenerators lag z. B. bei 2 Credits.

Die Preisrelation wirkte mir jedoch nicht immer konsistent: Die bloße Umstellung von „Sie“ auf „du“ auf der Startseite kostete mich beispielsweise 1,4 Credits – während die vollständige Integration von Dark- und Light-Mode samt Einbindung unseres Corporate Designs lediglich 1 Credit beanspruchte.

Mein erster Eindruck: Große, autonome Aufgaben sind oft günstiger, als viele kleine Änderungen einzeln anzustoßen. Wer effizient arbeiten will, sollte Lovable eher mit klaren, zusammenhängenden Paketen füttern statt micromanagen.

Preislich finde ich Loveable so oder so sehr fair – das sei vorweg genommen.

Erste Schritte

Jetzt wurde es ernst: Mein erster Vibe-Coding-Prompt war schnell formuliert – und dann hieß es erstmal warten. Gut, nur kurz: Nach exakt 3 Minuten und 16 Sekunden stand die erste Version meines Profilgenerators. Lovable informiert dabei sehr benutzerfreundlich darüber, woran gerade gearbeitet wird.

Und tatsächlich: Die erste Version sah schon ziemlich schick aus.
Ein kleiner Bug hatte sich eingeschlichen – das Kontextmenü ließ sich per Slider aktivieren, aber nicht wieder deaktivieren. Der Fix war für 0,6 Credits schnell erledigt. Der Vibe stimmte noch nicht ganz, aber nach fünf – sechs Iterationen und etwa 20 Minuten stand ein Design, mit dem ich wirklich zufrieden war. Inklusiver automatische Unterstützung für Light- und Dark-Mode als kleine Spielerei.

Stimmungsbarometer zu diesem Zeitpunkt: 9/10.

Für einen (eingerosteten) Entwickler, der sich eher in Backend-Architekturen und Algorithmik zuhause fühlt, war die schnelle Erstellung eines modernen (wenn auch etwas generischen) Frontends schlicht ein Traum. Ich selbst hätte dafür sicherlich mehr als einen Tag gebraucht, und auch ein erfahrener UI-Entwickler hätte einige Stunden investieren müssen.

Warum keine 10/10?

Ein paar Kinderkrankheiten gibt es noch. So konnte ich unser Unternehmenslogo nicht direkt hochladen, sondern musste Lovable erst mit einem GitHub-Repository meiner Wahl verbinden und die Bilddatei manuell ablegen. Kein Beinbruch – aber als echter Vibe-Coder will man eigentlich nichts mehr mit den src/assets-Ordnern dieser Welt zu tun haben.

Immerhin: Die GitHub-Integration funktioniert hervorragend.

Lovable committed sauber, transparent, und der Re-Sync läuft quasi in Echtzeit.

Zwischen Begeisterung und Bauchschmerzen: Das erste echte Problem

Eines der Hauptargumente gegen Vibe-Coding ist, dass dabei nicht nur sogenannter bloated Code entsteht – also unnötig umfangreicher, redundanter oder unstrukturierter Code, der schwer wartbar ist –, sondern dass essenzielle Aspekte wie Sicherheit, Skalierbarkeit und Fehlertoleranz häufig zu kurz kommen.

Umso erfreulicher war es, dass Lovable bei einem sensiblen Punkt direkt reagierte:
Ich hatte das Tool bewusst darum gebeten, meinen Gemini-API-Key hart in den Code einzubetten – ganz im Sinne eines schnellen Prototyps. Doch statt den einfachsten Weg zu gehen, empfahl mir Lovable, den Schlüssel lieber in ein Secret auszulagern. Vorbildlich. (Mehr zu den Sicherheitsfeatures von Loveable findet sich hier).

Passenderweise bietet Lovable mit einer Supabase-Integration auch gleich eine Lösung an. Supabase ist – kurz gesagt – ein gehosteter Postgres-Dienst mit API-Zugriff, Authentifizierung und Dateispeicher (https://docs.lovable.dev/integrations/supabase).

Ich wollte jedoch bewusst nicht den für Lovable einfachsten Weg gehen und keine zusätzliche Anbieterabhängigkeiten schaffen. Also bat ich um einen Alternativplan. Nach kurzer Diskussion einigten wir uns darauf, den API-Key über eine Umgebungsvariable einzubinden – ganz im Sinne eines später cloudfähigen Deployments. Lovable generierte daraufhin automatisch eine .env.local-Datei und eine begleitende GEMINI_SETUP.md. Den Test-Key konnte ich direkt über den integrierten Code-Browser ablegen.

Und dann kam der erste grobe Patzer.

Die .env.local-Datei landete im Git-Repository. Ein klassischer Anfängerfehler: .gitignore nicht gepflegt. Ich bin mir relativ sicher, dass Lovable in ein paar Monaten genau solche Fehler zuverlässig vermeidet – und in der ursprünglich empfohlenen Supabase-Lösung (die ein echter Vibe-Coder wohl verfolgt hätte) wäre das gar nicht erst passiert.

Aber dennoch: Das sind Fehler, die Senior-Entwicklern – und ein solcher auf Steroiden will Lovable letztlich sein – nicht passieren dürfen.

Ein wenig bestärkt in meiner Skepsis, aber weiterhin beeindruckt von Tempo und Nutzerführung, bewegt sich meine Laune bei 6 von 10 Punkten.

Kontrollverlust mit Ansage: Wenn der Vibe kippt

Was wie ein kleiner Stimmungseinbruch wirkte, entpuppte sich leider als Auftakt zu einer echten Stunde des Vergessens.

Zunächst war da das Problem mit der .env.local: Die Umgebungsvariable wurde von der Anwendung in Lovable nicht gezogen – die Datei war schlicht verschwunden. Ich vermute, intern wurde auf den Stand aus Git zurückgesetzt, aus dem ich die Datei inzwischen ja wieder entfernt hatte. Also: GitHub-Verbindung ein zweites Mal bemüht, Repository lokal geklont – und siehe da, lokal funktionierte die Einbindung der Umgebungsvariable problemlos.

Alles gut? Mitnichten.

Beim ersten lokalen Start begrüßte mich die Konsole mit einer klassischen NPM-Warnung:

added 397 packages, and audited 398 packages in 6s, 7 vulnerabilities (1 low, 4 moderate, 2 high).

Der Vibe-Coder in mir war verunsichert. Also tat ich, was ein echter Vibecoder tun sollte: Ich fragte die KI um Hilfe. Und es passierte… nichts (Gutes).

Ob die internen Sicherheitsmechanismen von Lovable (siehe Screenshot) blockierten oder die KI einfach einen schlechten Tag hatte – keine Ahnung. Fest steht: Ich musste den Befehl npm audit fix lokal ausführen und den Code zurück ins Repository pushen, um die Sicherheitswarnungen loszuwerden.

Wenigstens konnte ich mich jetzt endlich der Backend-Integration widmen. Die Nutzung meines vorbereiteten Prompts zur Gemini-Anbindung funktionierte grundsätzlich: Ein API-Aufruf wurde generiert, die Kommunikation mit Gemini stand. Aber: Auf die Idee, die Rückgabewerte zu typisieren oder zu validieren, kam das Tool nicht. Stattdessen: lose JSON-Strukturen im Backend. An dieser Stelle fühlte sich Vibe-Coding das erste Mal wirklich falsch an.

Am Frontend sah ich sofort Ergebnisse. Ich habe Feedback, bekomme UI, sehe Fortschritt. Hier dagegen diskutierte ich eine Stunde lang mit der KI über API-Strukturen – ohne jedes wirkliche Feedback, ob wir uns in die richtige Richtung bewegen. Ohne eigene Programmier- oder Anwendungserfahrung wäre ich an diesem Punkt komplett verloren gewesen.

Vielleicht hätte ich auch einfach dem Vibe mehr vertrauen sollen. Aber hey – ich habe nicht jahrelang Programmieren gelernt, um dann schlechten Code blind durchzuwinken.

Immerhin: Lovable ließ sich schnell überzeugen, dass Typisierung vielleicht doch keine ganz dumme Idee ist.

Vertrauen ist gut – Tests sind besser?

Mit wachsender Skepsis wollte ich die Leine nun kürzer halten: „Please add a test framework and implement some tests for our work.“ – eine eigentlich einfache Bitte. Gerade Testfallerzeugung wird oft als Paradebeispiel für AI-Coding-Unterstützung genannt.

Doch es blieb wirklich der Wurm drin. Fünf Minuten Wartezeit, acht eigene „Let me fix this“-Schleifen – und am Ende stand wieder… nichts (Funktionierendes).Warum? Keine Ahnung. Zu viele Vorgaben meinerseits? Zu wenig Vibe-Vertrauen? Eine Laune der KI? Eine funktionierende Testabdeckung habe ich von Lovable jedenfalls nicht gesehen.

Claude to the Rescue?

Ganz wollte ich das Thema nicht abhaken – immerhin gelten Tests als KI-Paradedisziplin.

Also bat ich Claude Code um Hilfe. Auch hier brauchte es mehrere Runden, aber letztlich funktionierte es.

Claude Code

Claude Code ist ein KI-Modell von Anthropic, das – ähnlich wie ChatGPT – natürliche Sprache versteht und generieren kann. Die Claude-Modelle gelten als besonders hilfreich bei technischen Aufgaben wie Codeverständnis, Testfallerstellung oder Fehlersuche, da sie stark auf Sicherheits- und Zuverlässigkeitsmechanismen optimiert wurden.

Lovable nutzt intern übrigens selbst Claude – was eine gewisse Ironie hat, wenn man am Ende Claude braucht, um Lovable wieder zum Laufen zu bringen. (https://www.anthropic.com/customers/lovable) 

Der finale Fix wirkte etwas verzweifelt – aber hey, es lief.

Zu diesem Zeitpunkt, etwa drei Stunden nach Projektstart, war meine Laune am Tiefpunkt: 1/10. Die Euphorie der ersten Stunde war einer Mischung aus Frust und Ermüdung gewichen. 

Aber ich wollte das Experiment nicht so enden lassen. Also: kurze Pause, frische Luft, neuer Anlauf. Noch eine Stunde war übrig – und vielleicht ja auch noch ein bisschen Vibe.

In welcher Sprache kann man eigentlich Vibecoden?

Laut offizieller Beschreibung ist Lovable eine rein englischsprachige Plattform:

“Lovable is an AI-powered platform that enables users of any skill level to create full-stack web applications without requiring coding expertise by simply describing what they want in plain English.”

Natürlich konnte ich es mir nicht verkneifen, auch deutschsprachige Prompts zu testen – und konnte keine wirklichen Qualitätsunterschiede feststellen. Lovable reagiert problemlos auf Deutsch und gibt deutsche Antworten. Auch das Übersetzen der UI in deutsche Sprache stellte das Tool vor keine Probleme.

Wirklich überraschend ist das allerdings auch nicht: Die zugrunde liegenden Claude-Modelle von Anthropic unterstützen – wie eigentlich alle großen Sprachmodelle –  sehr robust Mehrsprachigkeit (https://docs.anthropic.com/en/docs/build-with-claude/multilingual-support).

Die Rückkehr zur Freude und ein Hauch von agentic AI

Nach einer dringend nötigen Pause startete ich in die letzte Stunde meines Experiments.

Die Backend-Anbindung an Gemini hatte mich etwas abgeschreckt, also zog es mich zurück auf den Happy Path – zurück zur Oberfläche, zurück zum UI.

Der Einstieg war vielversprechend: Eine Funktion zur Erstellung von Demo-Profilen mit Mock-Daten sowie die Möglichkeit, sämtliche Felder nachträglich zu bearbeiten, war innerhalb weniger Minuten umgesetzt. Und ganz ehrlich? Hier macht Vibe-Coding einfach Spaß. Schnelle Feedbackzyklen, sichtbare Fortschritte.

Einziger Wermutstropfen: Die Testabdeckung bleibt weiterhin keine Priorität von Loveable. Aber gut – wir reden doch alle über agentic AI. Also darf Claude dann eben parallel Tests prüfen sowie aktualisieren und mir nebenbei auch noch ein erstes Docker-Setup aufsetzen.

Zwischenzeitlich liefen sogar drei KIs gleichzeitig:

• Lovable baute UI-Features
• Claude machte Code-Reviews, testete, dockerisierte
• ChatGPT optimierte der Prompt für Gemini, sodass wirklich strukturierter Output (statt Fließtext) zurückkam

Und das Beste zum Schluss: Auch eine erste Google-Docs-Integration funktionierte auf Anhieb. Feine Formatierung war zwar eine Herausforderung – an der Stelle hätte ich die Klasse wohl selbst noch mal geschrieben – aber der technische Durchstich lief perfekt.

Zwischen Euphorie und Ernüchterung – mein Zwischenfazit

Das, was ich in nur vier Stunden erreicht habe, hätte ich ohne KI in dieser Zeit niemals auch nur annähernd geschafft. Ich verstehe absolut, wieso Vibe-Coding begeistert.

Gleichzeitig habe ich aber auch viele Herausforderungen gespürt, die dieser Ansatz heute noch mit sich bringt. Besonders bei Lovable habe ich das Gefühl, dass das Tool stark auf die schnelle und visuell überzeugende UI-Generierung optimiert ist – was aus Marketingsicht absolut Sinn ergibt, wenn man bedenkt, dass die Zielgruppe vor allem jene 99 % der Menschheit sind, die nicht programmieren können.

Doch sobald Lovable vom Happy Path abwich, geriet es ins Straucheln. Komplexere Logik, Fehlertoleranz, saubere Typisierung oder Testabdeckung – all das wurde deutlich schwieriger. Aber, um fair zu bleiben: Auch bei eigenen Programmierprojekten habe ich schon viele Stunden auf der Suche nach Bugs oder Denkfehlern verbracht, die sich im Nachhinein als trivial herausgestellt haben. Mehr als einmal. Viel mehr als einmal.

Und es bleibt festzuhalten: Ich habe mit kaum nennenswerter eigener Programmierleistung in vier Stunden eine funktionale, hübsche und zu 80 % fertige Web-App gebaut – inklusive Docker-Setup und KI-Integration. Das ist beachtlich.

Für den produktiven Einsatz im Alleingang ist Vibe-Coding für mich derzeit noch zu intransparent und fehleranfällig. Aber: Lovable war deutlich weiter, als ich erwartet hatte – und was Claude Code in Sachen Docker geliefert hat, war ebenfalls eine angenehme Zeitersparnis.

Besonders spannend finde ich aktuell jedoch vor allem einen Anwendungsfall: Kund:innen innerhalb weniger Minuten interaktive UI-Prototypen mit Mock-Funktionalitäten präsentieren, um Feedback frühzeitig einzuholen und gemeinsam zu iterieren. Für diesen Zweck könnte Vibe-Coding schon heute ein echter Gamechanger sein. 

Und was ist mit meinem ehemaligen Kunden und seinem Startup?

Ich gebe zu: Ich ringe noch ein wenig mit mir. Für einen ersten Proof of Concept ist ein Vibe-Coding-Ansatz wie Lovable durchaus geeignet. Gerade im Gespräch mit Investor:innen kann eine funktionierende App – selbst wenn sie noch nicht produktionsreif ist – ein starkes Argument sein. Nach diesen vier Stunden bin ich überzeugt: In ein bis zwei Wochen ließe sich ein funktionsfähiger Prototyp erstellen und in der Cloud der Wahl deployen.

Ob ich diesen Weg allerdings uneingeschränkt empfehlen kann, hängt von einer entscheidenden Frage ab: Wie tragfähig ist die technische Basis – und wie gut lässt sich darauf weiterentwickeln?