Ich möchte ganz klar zu etwas sein, bevor wir anfangen.
Heb dir das auf :)
Ich bin kein Entwickler. Ich war noch nie ein Entwickler. Ich habe keinen Informatikabschluss. Ich habe keinen einzigen Coding-Bootcamp besucht. Ich kann den meisten Code nicht lesen und dir sagen, was er tut.
Aber letztes Wochenende habe ich eine funktionierende Webanwendung ins Internet gebracht. Echte Benutzer haben sich angemeldet. Echte Daten wurden gespeichert. Echte Funktionen haben funktioniert.
Ich habe das ganze Ding mit Claude Code in zwei Tagen gebaut. Und ich werde dir die Wahrheit darüber sagen, wie diese Erfahrung wirklich war. Nicht die bearbeitete Version. Die chaotische, frustrierende, von Durchbrüchen geprägte Realität.
Denn jede "Ich habe eine App mit KI gebaut"-Geschichte im Internet hört sich mühelos an. Es ist nicht mühelos. Aber es ist sehr, sehr machbar.
Samstagmorgen: Die Idee
Ich wollte ein einfaches Tool bauen. Einen Content-Kalender, mit dem du deine Beiträge über Plattformen hinweg planen, zwischen Tagen ziehen und als veröffentlicht markieren kannst. Nichts Revolutionäres. Aber etwas, das ich für meinen eigenen Workflow tatsächlich brauchte.
Ich öffnete Claude Code zum ersten Mal um 9 Uhr morgens in meinem Terminal.
Um 9:15 Uhr hatte ich bereits meinen ersten Fehler gemacht.
Fehler #1: Ohne Plan anfangen
Meine allererste Eingabe an Claude Code war:
Baue mir eine Content-Kalender-App
Claude generierte einen Haufen Dateien. Etwas erschien auf dem Bildschirm. Es sah aus wie ein Content-Kalender, der von jemandem entworfen wurde, der noch nie einen Kalender gesehen hatte.
Hier geben 90 % der Leute auf. Sie tippen eine vage Eingabe ein, bekommen ein vages Ergebnis und schließen daraus, dass Vibe-Coding nicht funktioniert.
Das Problem war nicht Claude. Das Problem war ich. Ich hatte ihm nichts gegeben, womit er arbeiten konnte.
Was ich hätte tun sollen:
Ich hätte im Plan-Modus starten sollen. Drücke Shift + Tab in Claude Code, um vom Aktionsmodus in den Planmodus zu wechseln. Im Planmodus denkt Claude nach, bevor er baut. Er stellt Fragen. Er zeichnet die Architektur auf. Er zeigt dir, was er zu erstellen plant.
Ich ging zurück und machte es richtig:
Ich möchte eine Content-Kalender-Web-App bauen. Bevor du irgendeinen Code schreibst, lass uns das planen.
Die App braucht:
- Eine Wochenansicht mit 7 Spalten (Montag bis Sonntag)
- Die Möglichkeit, Beiträge mit einem Titel, einer Plattform (Twitter, LinkedIn, Instagram) und einem Status (Entwurf, geplant, veröffentlicht) hinzuzufügen
- Drag & Drop, um Beiträge zwischen Tagen zu verschieben
- Ein einfaches, sauberes Design mit Tailwind CSS
- Daten, die in einer lokalen Datenbank gespeichert werden, damit sie zwischen Sitzungen erhalten bleiben
Welchen Tech-Stack sollen wir verwenden? Wie ist die Ordnerstruktur? Führe mich durch die Architektur, bevor du etwas baust.
Claude kam mit einem detaillierten Plan zurück. Next.js als Framework. SQLite als Datenbank. Tailwind fürs Styling. Eine saubere Ordnerstruktur, Datei für Datei aufgeschlüsselt.
Gelernte Lektion: Starte immer im Planmodus. Beschreibe immer im Detail, was du willst. Die 5 Minuten, die du mit Planen verbringst, sparen dir 2 Stunden Neuaufbau.
Fehler #2: Versuchen, alles auf einmal zu bauen
Nach der Planung war ich aufgeregt. Ich sagte Claude, er solle das ganze Ding auf einmal bauen.
Das Ergebnis war ein Chaos. Einige Funktionen funktionierten. Andere waren nur halb implementiert. Das Drag & Drop war kaputt. Die Datenbank speicherte nicht richtig. Ich hatte keine Ahnung, wo ich anfangen sollte, es zu reparieren.
Was ich hätte tun sollen:
Baue eine Funktion nach der anderen. Das ist die goldene Regel des Vibe-Codings.
Ich fing von vorne an und folgte dieser Reihenfolge:
Sitzung 1: Nur das grundlegende Seitenlayout. Sieben Spalten. Keine Funktionen. Sitzung 2: Füge die Möglichkeit hinzu, einen Beitrag zu erstellen (nur ein einfaches Formular). Sitzung 3: Zeige gespeicherte Beiträge in der richtigen Tagesspalte an. Sitzung 4: Füge Drag & Drop-Funktionalität hinzu. Sitzung 5: Füge die Statusfunktion hinzu (Entwurf/geplant/veröffentlicht). Sitzung 6: Mach es gut aussehen.
Jede Funktion bekam ihre eigene Unterhaltung. Neuer Kontext. Klare Aufgabe. Sauberes Ergebnis.
Als ich eine Funktion nach der anderen baute, funktionierte jede perfekt. Als ich versuchte, alles auf einmal zu bauen, funktionierte nichts.
Gelernte Lektion: Eine Unterhaltung pro Funktion. Vermische niemals mehrere Funktionen in derselben Claude Code-Sitzung.
Fehler #3: Keine CLAUDE.md-Datei erstellen
Am Samstagnachmittag hatte ich ein funktionierendes Grundlayout und war aufgeregt. Aber ich stieß immer wieder auf die gleichen Probleme:
Claude fügte ständig unnötige Komplexität hinzu. Er erstellte ausgeklügelte Fehlerbehandlungssysteme, wenn ich nur ein einfaches Try-Catch wollte. Er fügte Animationsbibliotheken hinzu, wenn ich nur einen sauberen Übergang wollte. Er strukturierte mein gesamtes Ordnersystem um, wenn ich eine kleine Änderung verlangte.
Ich korrigierte immer wieder dieselben Dinge.
Dann erinnerte ich mich daran, über CLAUDE.md gelesen zu haben.
Ich erstellte eine Datei in meinem Projekt-Root:
CLAUDE.md
Projektregeln
- Dies ist ein einfacher Content-Kalender. Halte alles minimal.
- Verwende Next.js 14 mit dem App Router
- Verwende Tailwind CSS für das gesamte Styling. Keine anderen CSS-Frameworks.
- Verwende SQLite mit Prisma ORM für die Datenbank
- Halte es einfach. Keine unnötigen Abstraktionen oder Entwurfsmuster.
- Wenn ich sage "mach es gut aussehen", meine ich: saubere Abstände, lesbare Schriftarten, subtile Hover-Effekte, abgerundete Ecken
- Füge niemals neue Abhängigkeiten hinzu, ohne mich vorher zu fragen
- Frage nach, bevor du vorhandenen Code umstrukturierst
Codestil
- Einfacher, lesbarer Code. Ein Anfänger sollte ihn verstehen können.
- Klare Variablennamen. Keine Abkürzungen.
- Kommentare nur für nicht offensichtliche Logik
Nachdem ich diese Datei erstellt hatte, änderte sich die Erfahrung dramatisch. Claude hörte auf, Overengineering zu betreiben. Er hörte auf, zufällige Bibliotheken hinzuzufügen. Er hörte auf, Dinge umzustrukturieren, die ich nicht angefasst haben wollte.
Jedes Mal, wenn Claude etwas tat, das ich nicht wollte, fügte ich eine neue Regel zu CLAUDE.md hinzu. Bis Sonntagabend hatte diese Datei 30+ Regeln und Claude befolgte sie alle perfekt.
Gelernte Lektion: Erstelle CLAUDE.md am ersten Tag. Aktualisiere es ständig. Es ist das mit Abstand mächtigste Werkzeug in Claude Code.
Fehler #4: Keine Screenshots verwenden
Samstagabend. Die App funktioniert, sieht aber hässlich aus. Ich tippte:
Mach das Design moderner und professioneller
Claude änderte Dinge. Sie sahen anders aus. Nicht besser, nur anders.
Ich versuchte, visuelle Probleme mit Worten zu beschreiben. Das ist unglaublich ineffizient.
Stattdessen fing ich an, Screenshots von Websites zu machen, deren Design ich liebte. Ich fügte sie direkt in Claude Code ein:
[Screenshot einer sauberen Kalender-UI]
Ich möchte, dass mein Kalender so aussieht. Konkret:
- Diesen exakten Grauton für den Hintergrund
- Diese abgerundeten Karten für jeden Beitrag
- Diesen Abstand zwischen den Elementen
- Die Art, wie der aktive Tag blau hervorgehoben wird
Claude traf das Design fast perfekt. Beim ersten Versuch.
Als dann etwas komisch aussah, machte ich, anstatt es zu beschreiben, einen Screenshot, umkreiste den Problembereich, fügte ihn ein und sagte "dieser Abstand ist falsch" oder "diese Schrift ist zu klein."
Gelernte Lektion: Screenshots sind 10x besser als Worte für visuelles Feedback. Füge immer Bilder ein, anstatt zu beschreiben, was du siehst.
Sonntag: Alles kam zusammen
Am Sonntagmorgen hatte ich eine funktionierende App mit sauberem Design, Drag & Drop, persistenten Daten und einer funktionierenden Datenbank. Ich hatte das ganze Ding gebaut, ohne den Großteil des Codes zu verstehen.
Aber es existierte nur auf meinem Laptop. Zeit zum Bereitstellen.
Fehler #5: Angst vor dem Deployment haben
Deployment klang erschreckend. Server. Domains. DNS. Konfigurationsdateien.
Ich hätte fast aufgehört. Ich hätte fast entschieden "lokal laufen lassen ist gut genug."
Aber ich drückte durch und fragte Claude:
Ich möchte diese App live im Internet bereitstellen. Ich möchte Vercel verwenden, weil ich gehört habe, dass es am einfachsten ist. Führe mich durch die genauen Schritte.
Claude gab mir sieben Schritte:
- Pushe den Code zu GitHub (Claude half mir, Git einzurichten)
- Melde dich bei Vercel an (kostenlos)
- Verbinde Vercel mit meinem GitHub-Repo
- Richte die Umgebungsvariablen für die Datenbank ein
- Klicke auf Bereitstellen
- Warte 90 Sekunden
- Erhalte meine Live-URL
Ich befolgte die Schritte. Drei Minuten später war meine App live. Ich schickte die URL an fünf Leute. Sie öffneten sie. Sie funktionierte.
Gelernte Lektion: Deployment ist nicht beängstigend. Es ist nur eine Checkliste. Claude wird dich durch jeden Schritt führen.
Die 12 Regeln, die ich gerne vor dem Start gewusst hätte
Alles, was ich in zwei Tagen gelernt habe, zusammengefasst in Regeln:
Regel 1: Starte jedes Mal im Planmodus. Shift + Tab. Denke nach, bevor du baust.
Regel 2: Eine Unterhaltung pro Funktion. Neuer Kontext ist besserer Kontext.
Regel 3: Erstelle CLAUDE.md am ersten Tag. Jede Korrektur wird zu einer dauerhaften Regel.
Regel 4: Verwende Screenshots für jedes visuelle Problem. Kreise das Problem ein. Füge es direkt ein.
Regel 5: Baue zuerst die einfachste Version. Füge Komplexität erst hinzu, nachdem die einfache Version funktioniert.
Regel 6: Beschreibe im Detail, was du willst. Je spezifischer deine Eingabe, desto besser die Ausgabe. "Baue eine Login-Seite" bringt Müll. "Baue eine Login-Seite mit E-Mail- und Passwortfeldern, einem 'Passwort vergessen'-Link darunter, einem blauen Submit-Button und einer Weiterleitung zu /dashboard bei Erfolg" bringt genau das, was du verlangt hast.
Regel 7: Verwende /compact, wenn Unterhaltungen lang werden. Claudes Qualität sinkt, wenn der Kontext voll wird.
Regel 8: Committe nach jeder funktionierenden Funktion zu Git. Claude kann dir dabei helfen. Wenn etwas kaputt geht, kannst du zurückrollen.
Regel 9: Wenn etwas kaputt geht, kopiere die Fehlermeldung und füge sie in Claude ein. Sage "Diagnostiziere die Ursache, bevor du etwas reparierst." Claude findet das Problem fast immer sofort.
Regel 10: Versuche nicht, jede Codezeile zu verstehen. Verstehe, was jede Datei tut und wie sie zusammenhängen. Das reicht, um Claude effektiv zu führen.
Regel 11: Wenn Claude in einer Schleife steckt, dasselbe immer wieder zu reparieren, höre auf. Starte eine neue Unterhaltung. Füge nur die relevante Datei und eine klare Beschreibung des Problems ein.
Regel 12: Bringe es live, bevor es perfekt ist. Version eins muss nicht schön sein. Sie muss funktionieren. Du kannst sie in Version zwei immer noch verbessern.
Was ich seit diesem Wochenende gebaut habe
Das ist drei Wochen her. Seitdem habe ich gebaut:
- Ein Kunden-Onboarding-Portal mit Login und Datei-Uploads
- Ein internes Dashboard, das meine Content-Metriken verfolgt
- Einen einfachen Rechnungsgenerator, der PDF-Rechnungen aus einem Formular erstellt
- Einen Lesezeichen-Manager, der Links nach Thema speichert und organisiert
Ich kann immer noch den meisten Code nicht lesen. Ich verstehe immer noch nicht 80 % von dem, was in den Dateien passiert. Aber ich kann klar genug beschreiben, was ich will, dass Claude es baut. Ich kann Fehler beheben, indem ich Claude den Fehler zeige. Ich kann funktionierende Produkte im Internet bereitstellen.
Das ist Vibe-Coding. Du bist nicht der Programmierer. Du bist der Produktmanager. Claude ist der Programmierer. Deine Aufgabe ist es zu wissen, was zu bauen ist, und es klar zu kommunizieren.
Die meisten Leute werden sich weiterhin einreden, dass sie erst programmieren lernen müssen, bevor sie etwas bauen können.
Diejenigen, die dieses Wochenende ihr Terminal öffnen, werden bis Montagmorgen eine funktionierende App haben. Ich weiß das, weil genau das mir passiert ist.
Folge mir @eng_khairallah1 für weitere KI-Kurse, Tools und Workflows. Jede Woche neue Inhalte.
hoffe, das war nützlich für dich, Khairallah ❤️
