Der Usecase
Es fing an mit einer einfachen Frage: Wie präsentieren wir eigentlich unsere Berater? Wir brauchten einen Profil-Generator — ein Tool, das strukturierte Beraterprofile erzeugt, hübsch formatiert als PDF, pflegbar über ein simples Web-Interface. Nichts Wildes, aber auch kein Wochenendprojekt.
Ein befreundeter Dienstleister hatte ein vergleichbares Tool für einen Kunden gebaut. Aufwand: 60.000 bis 80.000 Euro, verteilt über mehrere Monate. Backend, Frontend, PDF-Rendering, Datenhaltung, Deployment. Klassische Individualsoftware, klassischer Preis.
Und dann dachte ich: Was wäre, wenn ich das an einem halben Tag mit einer Vibe-Coding-Plattform baue? Nicht perfekt, nicht produktionsreif — aber funktionsfähig genug, um zu verstehen, wo die Grenzen liegen.
Die Plattform meiner Wahl: Lovable. Kein Code schreiben, nur Prompts. Die KI generiert den Code, deployed automatisch, und ich steuere per natürlicher Sprache. So zumindest das Versprechen.
Vorbereitung
Lovable arbeitet mit einem Credit-System. Jede Interaktion — ob Prompt, Bugfix oder Deployment — kostet Credits. Das klingt harmlos, wird aber schnell relevant, wenn man iterativ arbeitet.
Ich startete mit dem Starter-Plan. Spoiler: Der hat nicht lange gereicht.
Mein Setup war denkbar einfach: Browser auf, Lovable geöffnet, erster Prompt formuliert. Kein lokales Repository, kein IDE, kein Terminal. Nur ich und ein Textfeld.
Erste Schritte
15:04 Uhr. Erster Prompt: „Erstelle eine Web-App zur Verwaltung von Beraterprofilen. React mit TypeScript, Supabase als Backend. Jedes Profil hat Name, Foto, Kernkompetenzen, Projekterfahrung und einen PDF-Export.”
Lovable generierte eine komplette React-Anwendung. Routing, Formulare, Supabase-Anbindung, sogar ein halbwegs ansprechendes UI mit Tailwind. Deployed und erreichbar unter einer Lovable-Subdomain.
15:20 Uhr. Sechzehn Minuten nach dem ersten Prompt hatte ich eine lauffähige Anwendung mit Login, Profilverwaltung und einer Profilansicht. Nicht perfekt — das Styling war an manchen Stellen holprig, die PDF-Generierung fehlte noch — aber es funktionierte.
Stimmungsbarometer: 9/10. Ehrlich beeindruckt. In sechzehn Minuten mehr erreicht als in manchen Sprint-Plannings besprochen wird.
Zwischen Begeisterung und Bauchschmerzen
Die nächsten Prompts liefen gut: PDF-Export mit react-pdf hinzugefügt, Profilfelder erweitert, Design angepasst. Lovable verstand die meisten Anweisungen auf Anhieb und generierte funktionierenden Code.
Dann der erste Dämpfer: Ich schaute mir das generierte Git-Repository an und fand eine .env.local-Datei — mit dem Supabase Service Role Key im Klartext, eingecheckt in Git.
Lovable hatte die .env.local nicht in die .gitignore aufgenommen. Ein Anfängerfehler, den die KI offenbar von den Trainingsdaten geerbt hat. Ich fixte es per Prompt — aber das Vertrauen hatte den ersten Kratzer bekommen.
Stimmungsbarometer: 6/10. Der Wow-Effekt war noch da, aber die Alarmglocken läuteten.
Kontrollverlust
Je mehr Features ich hinzufügte, desto häufiger traten Seiteneffekte auf. Ein neuer Prompt brach ein bestehendes Feature. Ein Styling-Fix verschob das Layout an anderer Stelle. Das Gefühl, die Kontrolle über die Codebasis zu haben, schwand mit jedem Iterationsschritt.
Dann lief ich npm audit gegen das generierte Projekt:
found 12 vulnerabilities (3 moderate, 7 high, 2 critical)
┌───────────────────────────────────────────────────┐
│ 2 critical │
├───────────────────────────────────────────────────┤
│ Prototype Pollution in lodash.merge │
│ ReDoS in postcss │
├───────────────────────────────────────────────────┤
│ 7 high │
├───────────────────────────────────────────────────┤
│ Cross-Site Scripting in react-pdf │
│ Path Traversal in vite dev server │
│ Denial of Service in semver │
│ ... │
└───────────────────────────────────────────────────┘Zwölf Schwachstellen, davon zwei kritisch. Lovable hatte veraltete Package-Versionen verwendet — und es gab keinen einfachen Weg, per Prompt ein npm audit fix auszulösen, das tatsächlich funktionierte.
Die Backend-Integration erwies sich als nächste Hürde: Supabase-Policies, die nicht griffen. RLS-Regeln, die sich gegenseitig blockierten. Fehlermeldungen, die Lovable nicht verstand und mit immer kreativeren — aber falschen — Workarounds beantwortete.
Stimmungsbarometer: 4/10. Ich verbrachte mehr Zeit damit, die KI zu korrigieren, als sie mir sparte.
Tests
An diesem Punkt dachte ich: Okay, ich schreibe wenigstens Tests, damit ich sehe, was kaputt geht. Prompt: „Schreibe Unit-Tests für alle Komponenten mit Vitest und Testing Library.”
Lovable generierte 14 Test-Dateien. Davon liefen 3 durch. Die restlichen 11 scheiterten an fehlenden Mocks, falschen Imports oder schlicht daran, dass sie Funktionalität testeten, die so nicht existierte. Die KI hatte Tests geschrieben, die zum Prompt passten, nicht zum Code.
Stimmungsbarometer: 3/10.
Claude to the Rescue
Frustration. Ich wechselte den Ansatz: Den generierten Code lokal geklont und Claude Code im Terminal gestartet. Prompt: „Analysiere die bestehenden Tests, finde die Fehler, und repariere sie.”
Claude Code arbeitete methodisch: Test für Test durchgegangen, Imports korrigiert, fehlende Mocks ergänzt, unrealistische Assertions angepasst. Nach vierzig Minuten liefen 12 von 14 Tests. Die zwei verbleibenden scheiterten an einem echten Bug im generierten Code — den Claude Code ebenfalls fand und fixte.
Der Unterschied war spürbar: Lovable generiert Code auf Basis von Prompts. Claude Code versteht den bestehenden Code und arbeitet damit. Zwei fundamental verschiedene Ansätze — und in diesem Moment war klar, welcher für mich besser funktioniert.
Stimmungsbarometer: 7/10. Erleichterung. Und die Erkenntnis, dass man Vibe Coding nicht isoliert betrachten sollte.
Rückkehr zur Freude
Ab diesem Punkt arbeitete ich mit drei KIs parallel: Lovable für schnelle UI-Iterationen, Claude Code für Backend-Logik und Bugfixes, und ChatGPT für Recherche und Konzeptfragen. Jede KI in ihrer Stärke.
Der nächste große Meilenstein: Google Docs Integration. Die Beraterprofile sollten nicht nur als PDF, sondern auch als editierbares Google Doc exportierbar sein. Ein Prompt an Lovable für das UI, ein Prompt an Claude Code für die Google Docs API-Anbindung, und ChatGPT half mir, die OAuth-Konfiguration zu verstehen.
In zwei Stunden stand eine funktionierende Integration, die Profile als formatierte Google Docs exportierte — inklusive Tabellen, Logos und Seitenumbrüchen.
Stimmungsbarometer: 8/10. Das Zusammenspiel mehrerer KI-Tools fühlte sich wie ein echter Workflow an.
Was ich geschafft habe
Nach vier Stunden und geschätzten 400 Lovable-Credits hatte ich:
- Eine funktionierende React-Anwendung mit Supabase-Backend
- Login, Benutzerverwaltung und Rollensystem
- CRUD für Beraterprofile mit strukturierten Feldern
- PDF-Export mit Custom-Template
- Google Docs Export mit formatierter Ausgabe
- 12 laufende Unit-Tests
- Ein Deployment auf einer Lovable-Subdomain
Was ich nicht hatte:
- Produktionsreife Sicherheit (der .env-Vorfall war nur die Spitze)
- Saubere Codebasis (Copy-Paste-Muster, inkonsistente Benennung)
- Vollständige Testabdeckung
- Vertrauen, dass ein Update nichts kaputt macht
- Dokumentation
Zwischenfazit
Vibe Coding mit Lovable ist beeindruckend für den Kaltstart. Die erste Stunde ist magisch — man sieht Ergebnisse, die normalerweise Tage brauchen. Aber der Zauber schwindet mit der Komplexität. Je mehr Features, desto mehr kämpft man gegen die KI statt mit ihr.
Die ehrliche Rechnung: Vier Stunden Vibe Coding haben mir vielleicht 60 % eines MVPs geliefert. Die restlichen 40 % — Sicherheit, Tests, Stabilität, Wartbarkeit — sind genau die Dinge, die eine professionelle Entwicklung ausmachen und die eine KI heute nicht zuverlässig liefert.
Ausblick
Eine Woche nach meinem Experiment rief mich ein ehemaliger Kunde an. Er hatte sein Unternehmen verlassen und plante ein Startup. Seine erste Frage: „Kann man nicht einfach alles mit KI bauen lassen? Braucht man überhaupt noch Entwickler?”
Ich erzählte ihm von meinem halben Tag als Vibecoder. Von der Begeisterung und den Bauchschmerzen. Von den .env-Dateien und den kaputten Tests. Von der Erkenntnis, dass KI ein fantastisches Werkzeug ist — aber kein Ersatz für Menschen, die verstehen, was sie tun.
Seine Antwort: „Also doch Entwickler einstellen?”
Meine Antwort: „Ja. Aber solche, die wissen, wie man KI-Tools als Hebel einsetzt. Das ist der eigentliche Skill der nächsten Jahre.”
Wie Ihr Team KI-Tools professionell als Entwicklungswerkzeug einsetzt? Genau darum geht es in unserer Schulung Agentenbasiertes Coding.
Geschäftsbereichsleitung «Finanzdienstleistungen»
Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter bei atra consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.
