Die wichtigste Erkenntnisse aus vier Produktversionen, über 60 dokumentierten Bugs und Hunderten Stunden Entwicklungszeit in einem Backend-SaaS, das ich komplett mit AI gebaut habe. Ohne Programmier-Background.
Backend, nicht Frontend — ein anderes Spiel
Die meisten Vibecoding-Erfahrungsberichte handeln von Todo-Apps und Landing Pages. Mein Projekt war ein Backend-SaaS: Decision Engine, Budget Engine, Recommendation Engine. PostgreSQL mit über 20 Tabellen und Dutzenden Abhängigkeiten. Google Ads API-Integration, eigenes Watchtime-Approximationsmodell, drei Runtime-Umgebungen. Komplexität: 7 von 10.
Der entscheidende Unterschied zu Frontend-Projekten: Wenn dein Frontend nicht funktioniert, siehst du es — die Seite ist weiß. Wenn dein Backend nicht funktioniert, sieht alles gut aus, nur die Daten sind falsch.
Schritt Null: Mit der AI im Zug reden
Bevor ich dokumentiere, bevor ich mit AI Code schreibe — rede ich. Einfach mit der AI über das Vorhaben sprechen, im Taxi, im Zug, an der Haltestelle. Zehn Minuten, wenn gerade Zeit ist. Was soll das Produkt leisten? Was gibt es schon? Was ist der Kern? Die AI stellt dabei Fragen, auf die man allein nicht kommt. Das kann Wochen dauern — und genau das ist der wichtigste Schritt im ganzen Prozess.
Die wichtigste Eigenschaft: Neugier
Nicht technisches Vorwissen, sondern Neugier. Was passiert, wenn ich X mache? Wie weit kann ich gehen? Ausdauer haben viele im Business, daran mangelt es nicht. Aber die Bereitschaft, Dinge auf eigene Faust auszuprobieren und Fragen zu stellen, die niemand gestellt hat — das ist der Unterschied.
Ich habe im letzten Jahr durch AI-gestützte Entwicklung mehr gelernt als in Jahren davor — Expertise, die ich neben der regulären Arbeit nie hätte aufbauen können. AI beschleunigt Aufgaben von Monaten auf Tage. Aber nur, wenn du verstehst, was du tust.
AI ist Exekutor, nicht Architekt. Du bist der Architekt.
Dokumentation — dein Steuerungsinstrument
Eine App kann auf eine Million Arten gebaut werden. Dokumentation reduziert diese Million auf fünf, und mit den richtigen Custom Instructions fragt die AI bei diesen fünf nach, statt selbst zu entscheiden.
Product Architecture.MD
Zuerst schreibe ich eine Product Documentation in eigenen Worten. Daraus entsteht ein Master File — kein Einzeiler, sondern ein umfassender Prompt, der die technische Architektur generiert. Beides kommt in die Project Files. Dann lasse ich eine Todo-Liste generieren und jede Komponente als Grafik visualisieren, weil das mich zwingt, alles zu durchdenken. Alle generierten Dateien lese ich durch und denke darüber nach. Das hat über 30 Stunden gedauert, über alle Versionen hinweg.
Wichtig: Diese Dateien sind keine Einmal-Dokumente, sondern lebende Dateien, die mit dem Produkt wachsen — dazu später mehr.
Die Architektur-Dokumentation sorgt dafür, dass die AI in jedem Moment weiß, wo sie steht, was sie löst und was die nächsten Schritte sind. Dazu gehört auch eine Todo-Liste, die ich aus der Architektur generieren lasse — erst detailliert, dann gekürzt. Beide Versionen kommen in die Project Files. Die AI weiß dadurch bei jedem Prompt und jeder Antwort, wo wir uns im Projekt befinden und was als Nächstes kommt.
Architektonische Entscheidungen — was wo gespeichert wird, wann berechnet wird — sind dabei zehnmal wichtiger als der Code selbst. Die AI ist mein Programmierer, ich bin der Product Owner. Sie schreibt den Code, aber ich treffe die Entscheidungen.
Changelog
Zusätzlich führe ich einen Changelog — eine laufende Dokumentation aller Threads und Entscheidungen: Was wurde gebaut, was geändert, was verworfen. Zusammen mit der Architektur, den Project Files, der Bug-Dokumentation und den AI Error Patterns hat die AI dadurch perfekten Kontext. Sie weiß nicht nur, was das Produkt tun soll, sondern auch, was bereits passiert ist und welche Entscheidungen warum getroffen wurden.
Es ist keine Blackbox mehr — es ist vollständige Transparenz. Und genau das macht den Unterschied zwischen „AI produziert irgendwas“ und „AI produziert genau das, was ich will“.
Bug-Dokumentation
Die wertvollste Datei im ganzen Projekt. Jeder Bug wird dokumentiert — Root Cause, Evidenz, Fix, Verifikation. Zehn dokumentierte Bugs mit Prevention Rules bedeuten, dass derselbe Bug nie zweimal vorkommt. Die AI lernt aus eigenen Fehlern, aber nur, wenn du sie dokumentierst.
Über 60 Bugs habe ich dokumentiert und daraus eine Analyse erstellt. Bestimmte Muster schlagen ohne Dokumentation immer wieder zu: Google Ads Scripts lassen Felder stillschweigend fallen — kein null, kein Error, die Daten fehlen einfach. parseInt(undefined) || 0 maskiert Datenverlust, weil der Code fehlerfrei läuft, die Zahl aber Müll ist. parseFloat(0) || null behandelt einen legitimen Nullwert als „kein Wert“.
Bug-Dokumentation hat Vorrang vor der Architektur. Der Dateiname signalisiert der AI, dass diese Informationen aktueller sind. Bei Widersprüchen gewinnt die Bug-Dokumentation — und mit der Zeit baut diese Dokumentation eigene Regeln und ein Decision Brain für deinen Chatbot auf.
Perfektes Produktverständnis
Vibecoding ist halt ein anderes Level von Abstraktion als. Um ein perfektes Produktverständnis und perfekte Memory der AI zu erzielen, empfehle ich folgende Dateien als Project Files:
- Produkt Architektur
- Produkt To-DO Liste
- Bug-Dokumentation (auch 3-4 Dateien)
- Change Logs (letzte 3-4 Logs)
- Database Structure
- Github Folder Structure
- AI Error Patterns
- UX/UI Guildelines
- Alle Prio-Files für Backend/Frontend
Dokumentation pflegen und versionieren
Das Produkt verändert sich, und die Dokumentation wird veraltet. Veraltete Dokumentation ist dabei schlimmer als keine, weil die AI dann auf falscher Basis arbeitet.
Deshalb pflege ich meine Project Files aktiv — spätestens zu Beginn jedes neuen Monats, manche Dateien auch häufiger. Die Architecture.md wird nicht einmal geschrieben und vergessen — ich regeneriere sie regelmäßig mit den neuesten Änderungen. Nach einem Monat Entwicklung sieht das Produkt anders aus als am Anfang, also lasse ich die AI eine aktualisierte Version generieren, prüfe sie und ersetze die alte. Dasselbe gilt für die AI Error Patterns-Dokumentation — jedes neue Fehlermuster wird eingetragen, veraltete Einträge entfernt.
Schlüsseldateien des Projekts lade ich regelmäßig mit Datum in die Project Files hoch und aktualisiere sie bei Änderungen. Die AI arbeitet so immer mit dem neuesten Stand, nicht mit einer Version von vor sechs Wochen.
Bei einer neuen Produktversion übernehme ich die Project Files der Vorgängerversion, ersetze sie schrittweise durch aktuelle und lösche die alten, damit sie keine Tokens verbrauchen. Veraltete Dateien bleiben nur als Referenz, wenn ich ein neues Projekt starte — gekennzeichnet mit einem Prefix wie xObsolete_V2, damit die AI sie als Inspiration nutzen kann, aber nicht als aktuelle Wahrheit behandelt. Das allein hat bei mir die Token-Kapazität von 28 % auf 14 % halbiert — bei gleicher Leistung.
Format: .txt und .docx — nie PDFs, die liest die AI am schwersten. Und es lohnt sich, die AI zu fragen, was sie braucht — vielleicht will sie einen Database Structure Dump, vielleicht will sie etwas löschen.
Verifizierung — die eigentliche Arbeit
AI gibt dir Code schnell, aber ohne Verifizierung jedes einzelnen Schritts baust du auf Sand.
Nicht am Ende prüfen, sondern nach jedem Schritt. Ich habe Bugs nur gefunden, weil ich die Datenbank direkt kontrolliert habe — leere Tabellen, null-Werte in 27+ Zeilen, fehlende Datumsfelder. Ein besonders tückischer Fall: Ein ALTER TABLE-Bug, bei dem INSERT-Operationen stillschweigend fehlschlugen. Die API gab Success zurück, aber null Einträge landeten in der Datenbank. Ohne DBeaver-Queries hätte ich das nie gesehen.
Verifizierung machte 80 % meiner Arbeitszeit aus, und selbst das reichte nicht — siehe den Rewards-Bug, der wochenlang unentdeckt blieb. Mein Richtwert inzwischen: 200–300 % der restlichen Zeit in Verifizierung investieren. Das klingt übertrieben, ist es aber nicht.
Und selbst wenn du denkst, der Backend steht und du musst nur noch das Frontend aufsetzen, kommen plötzlich fatale Bugs. Ich dachte, ich müsse nur das Frontend feinschleifen — stattdessen war alles durchgehend verbuggt.
Die AI wusste es. Wochenlang. Und sagte nichts.
Mitten im Build stellte ich durch Zufall fest, dass mein Rewards-System — eine zentrale Komponente meiner Software, die Kampagnen-Performance züsatzlich bewertet — seit Wochen nicht funktionierte. Die Google Ads API lieferte schlicht keine Daten dafür. Die AI wusste das, sie hatte bei jeder Interaktion den vollen Kontext. Aber sie sagte nichts.
Ich fand es nur, weil ich in allem herumstochere — Datenbank-Queries, Screenshots, Logs. Nicht weil das System mich gewarnt hätte.
Domain-Expertise — was die AI nicht wissen kann
Für mein Projekt musste ich API-Limitierungen reverse-engineeren, die nirgendwo dokumentiert waren: nur drei Campaign-Level-Operationen für Video-Kampagnen, obwohl 25+ Metriken verfügbar sind, von denen ich nur fünf brauche usw.
Kein AI-Modell kann dieses Wissen generieren. Das ist Branchenwissen — und der Unterschied zwischen einem funktionierenden und einem nützlichen Produkt.
Die kritischste Entdeckung des gesamten Projekts: Die offizielle Google Ads API-Dokumentation behauptete, bestimmte Schreiboperationen für Video-Kampagnen würden unterstützt. Das Backend blockierte sie stillschweigend — kein Fehler, keine Warnung. Nimm keine Dokumentation als Wahrheit, ohne sie real zu testen.
AI denkt wie ein Techniker, nicht wie ein Product Owner
Manchmal behauptet die AI, ein Problem sei unlösbar — eine API-Limitierung, kein Workaround möglich. Sie denkt dabei technisch korrekt, aber nicht unternehmerisch. Workarounds existieren fast immer.
In meinem Fall: Statt OAuth zu implementieren, nutze ich Google Ads Scripts als Integrationsschicht. Technisch unelegant, geschäftlich perfekt — einfacher zu deployen, kein Token-Management, der Kunde merkt keinen Unterschied. WordPress dient als View Layer, nicht als Backend — saubere Trennung der Verantwortlichkeiten.
Vibecoding allein reicht bei 7/10 Komplexität nicht aus. Ich habe es geschafft, aber wegen systemischem Denken und Branchenexpertise. „Mach gute Dokumentation und es läuft“ ist nicht die ganze Wahrheit.
Weitere Learnings
Custom Instructions als Decision Brain. Der Pre-Prompt definiert, wie die AI denkt: Verifizierung nach jedem Schritt, Erklärung vor Code, Optionen vorlegen statt selbst entscheiden. Diese Regeln bauen ein eigenes Entscheidungssystem für deinen Chatbot auf.
Schritt für Schritt. AI spuckt fünf Dateien aus, du lädst sie hoch, fertig? So funktioniert kein Backend-Produkt. Basis erstellen, jede Verbindung einzeln testen, dann die nächste Komponente. Alles dauert dabei viermal so lange wie geschätzt — und die erste und zweite Version wegzuwerfen ist normal, nicht die Ausnahme.
Keine großen Schritte am Anfang. Wenn es deine erste oder zweite App ist, oder wenn das Projekt komplexer wird, mach alles Schritt für Schritt und verifiziere nach jedem einzelnen Befehl. Als Product Owner musst du den Überblick behalten und das Produkt verstehen — und jeder manuelle Schritt ist eine Gelegenheit, Fehler zu finden und das Produkt zu verbessern.
Verstehen statt akzeptieren. Selten akzeptiere ich eine generierte Datei einfach so, weil ich verstehen will, was passiert. Deshalb mache ich Änderungen oft selbst und lade die Datei dann zurück — so verifiziert die AI meine Änderungen und bekommt gleichzeitig frischen Kontext. Am Anfang eines Projekts akzeptiere ich mehr, aber je weiter es fortschreitet, desto mehr mache ich selbst.
Screenshots (und Logs) als Erkenntnisquelle. Wenn ich der AI einen Screenshot eines Logs oder einer Ordnerstruktur schicke, kann sie Dinge entdecken, die sie vorher gar nicht auf dem Schirm hatte — Zusammenhänge, die außerhalb ihres bisherigen Kontexts lagen. Oft braucht es dazu nicht mal einen Prompt, nur den Screenshot. Und mit der Zeit fängt die AI an, selbst nach Screenshots zu fragen, wenn sie welche braucht.
Mehrere Dateien gleichzeitig einspielen — die AI findet den Fehler. Manchmal lade ich vier Screenshots aus DBeaver, drei aus den Railway Logs und noch ein paar andere Dateien gleichzeitig hoch. 12 Files auf einmal. Die AI liest alles, versteht die Zusammenhänge zwischen Datenbank, Deploy und Code — und findet präzise die Stelle, an der es sich verhakt. Oft schneller als ich, weil sie alle Ebenen gleichzeitig sieht.
Ganze Dateien zur Durchsicht geben. Wenn ich einen ganzen Code-File in die AI kopiere, findet sie regelmäßig kleine Fehler, die mir entgangen sind. Das ist kein aufwendiger Review-Prozess — einfach den File reinkopieren und die AI drüberschauen lassen. Oft sind es Kleinigkeiten, die aber in der Summe Probleme verursacht hätten.
Thread-Management. Wenn der Thread zu lang wird, fasse ich die letzten zwei Threads als Textdatei zusammen und mache in einem neuen weiter. Der AI sage ich, sie soll zuerst die Architektur scannen und dann die Text-Threads lesen. Nach jeder Diskussion lasse ich die nächsten Schritte zusammenfassen und eine Todo-Liste erstellen — das hilft mir und der AI gleichermaßen.
Fragen stellen. Sich Dinge von der AI erklären zu lassen ist keine Zeitverschwendung — es ist der schnellste Weg, das eigene Produkt zu verstehen. Ich mache das in separaten Threads, damit der Hauptthread nicht aufgebläht wird. Je mehr ich verstehe, desto bessere Entscheidungen treffe ich.
Wie ich dazu kam
Ich bin kein Entwickler. Ich bin AI-Enthusiast und Marketing-Mensch, etwas technischer als der Durchschnitt — ich konnte ganz gut HTML und CSS, aber einen Tech-Job hatte ich nie.
Drei Dinge haben mich ins Vibecoding gebracht. Ein Bekannter erzählte in einem Podcast, dass er mit AI-gebautem Software Umsätze im niedrigen Millionenbereich macht — das hat gesessen. Gleichzeitig hatte ich als Freelancer Content-Distribution-Dienstleistungen angeboten, aber es wurde zu wenig komplex, nur ein Teil des Funnels. Mein Preis stieg, und ohne ausreichendes Budget hätte sich das für den Kunden nicht mehr gelohnt.
Und drittens wollte ich meine AI-Skills auf ein Level bringen, das mir in allen Lebensbereichen hilft. AI ist für mich ein Hebel, nicht nur ein Tool.
Also habe ich angefangen, die Dienstleistung zu automatisieren, die ich vorher manuell erbracht habe. Meine Methodologie zur Optimierung auf Completed Watchtime überlebt — nur jetzt als Software, zu einem Bruchteil des Preises.
Ich habe immer gedacht, ich ende als Entwickler, aber das Leben hat mich auf einen anderen Weg geführt. Vibecoding hat mir ermöglicht, eigene Software zu bauen.
Und ehrlich — es fühlt sich an wie damals mit fünfzehn, als ich als 15-jähriger Teeneger neben GTA Webseiten mit PHP-Fusion und phpBB gebastelt habe. Dieselbe Neugier, dieselbe Freude am Entdecken.
