Eine komplette App mit Claude Code bauen: Echte Beispiele

Ein Builder ohne jede Spieleentwicklungserfahrung brachte an einem einzigen Wochenende ein GTA-ähnliches Spiel auf realen Google-Earth-Städten live. Claude schrieb rund 80% des Codes. Das Spiel zieht echte Polizeistationen, Flughäfen und Häfen von OpenStreetMap. Das In-Car-Radio stimmt sich automatisch auf lokale Sender via Radio Garden API ein.

Das ist keine Demo. Es ist eine Live-Waitlist unter cw.naveen.to.

Das Muster hinter diesem Build — und mehreren ähnlichen — ist spezifisch und wiederholbar. Dieser Post zeigt, was die erfolgreichen davon gemacht haben, und was schiefging, wenn sie es nicht taten.

Was du wirklich an einem Wochenende bauen kannst

Drei echte Builds aus April 2026. Die Bandbreite ist wichtig.

Naveen (@naveenvkt auf X) brachte Crimeworld live: ein browserbasiertes GTA-ähnliches Spiel auf echten Google-Earth-Städten. Stack: Cesium, Google 3D Tiles, Three.js, Radio Garden API und OpenStreetMap-Daten. Kein Spieleentwicklungs-Hintergrund. Claude schrieb rund 80% des Codes. Der Build entstand an einem einzigen Wochenende. Es funktioniert, hat an einigen Stellen Bugs, und es gibt eine Live-Waitlist.

Santiago baute career-ops: ein KI-Job-Suchsystem ohne traditionellen Anwendungscode. Das gesamte System besteht aus rund 3.200 Zeilen Markdown-Prompt-Dateien. Vierzehn Skill-Modi leben in einem modes/-Verzeichnis. CLAUDE.md ist die Orchestrierungsschicht. Das System bewertete 740+ Stellenangebote, generierte 100+ ATS-optimierte CVs und landete eine Head-of-Applied-AI-Stelle. Es nutzt parallele Batch-Verarbeitung mit claude -p Workern für Sub-Agenten. Menschliche Überprüfung vor jeder Einreichung ist im Design verankert. Das System bewertet Jobs von A bis F und empfiehlt, bei unter 4,0/5 nicht zu bewerben. Der Quellcode ist MIT-lizenziert unter santifer/career-ops auf GitHub.

Ein dritter Builder ohne Finanz-Hintergrund testete eine Hedgefonds-Parkplatz-Zähl-Strategie mit Satellitenbildern. Er beschrieb die Hypothese auf normalem Englisch: Optische Satellitenbilder von Einzelhändler-Parkplätzen sollten Erträge vorhersagen. Claude baute die gesamte Analysepipeline aus dieser Beschreibung. Als der optische Ansatz bei rund 33% Genauigkeit scheiterte, beschrieb der Builder eine neue Hypothese: Radar reflektiert an Metallfahrzeugen anders als an Asphalt. Claude baute die Pipeline von Grund auf neu. Das finale System zieht Sentinel-2-optische und Sentinel-1-Radardaten via Google Earth Engine, verarbeitet Parkplatzbegrenzungen aus OpenStreetMap und führt Permutationstests, Binomialtests und Bootstrap-Resampling über 35+ Python-Skripte aus. Radar bei drei Einzelhändlern erzielte 100% Genauigkeit. Skaliert auf zehn Einzelhändler fiel sie auf 50%. Fazit des Builders: "Der Burggraben sind Datenqualität, nicht der Algorithmus." Das ist das ehrliche Ergebnis, wenn du baust, um zu testen — nicht um zu beweisen.

Drei verschiedene Bereiche. Drei verschiedene technische Hintergründe. Ein konsistenter Ansatz. Alle beschrieben, was sie wollten, auf normalem Englisch, teilten die Arbeit in Stücke auf und ließen Claude die Implementierung übernehmen.

Bevor du einen einzigen Prompt schreibst

Das Spec kommt zuerst. Immer.

Offizieller Anthropic-Ratschlag für Claude Code: Lass Claude dich interviewen, bevor es Code schreibt. Bitte Claude, klärende Fragen zu technischer Implementierung, UI/UX, Edge Cases, Einschränkungen und Kompromissen zu stellen. Schreib die Antworten in eine SPEC.md-Datei. Starte eine neue Session, um aus diesem Spec heraus zu arbeiten. Der WorthIt-Builder (ein Junior-Dev im Bootcamp, hauptsächlich Backend-Java, keine vorherige Full-App-Erfahrung) beschrieb es so: "Detaillierte Prompts schlagen vage jedes Mal, vollständige Produktspecs, nicht 'baue mir ein Dashboard.'"

CLAUDE.md ist keine Projektdokumentation. Dieser Unterschied ist wichtiger als die meisten Anleitungen zugeben.

Der Standardrat ist, CLAUDE.md mit Tech-Stack-Beschreibungen, Konventionen und Notizen zu deiner Ordnerstruktur zu füllen. Dieser Ansatz hat einen echten Fehler. Alles in CLAUDE.md hat hohe Priorität in Claudes Kontext. Eine aufgeblähte CLAUDE.md bringt Claude dazu, spezifische Anweisungen zu verlieren. Wenn Claude immer wieder etwas tut, das du nicht willst, obwohl du eine Regel aufgeschrieben hast, ist die Datei wahrscheinlich zu lang und die Regel wird begraben.

Die mächtigere Nutzung von CLAUDE.md ist als Orchestrierungs-Kontrolldatei. Definiere operative Workflows und Delegationsmuster. Verschiebe Tech-Stack-Dokumentation und Coding-Konventionen in Skills, die bei Bedarf geladen werden. Halte CLAUDE.md fokussiert auf Dinge, die Claude nicht aus deinem Code herauslesen kann: Bash-Befehle, Branch-Naming-Konventionen, Testing-Anweisungen, Architekturentscheidungen, die du aus nicht offensichtlichen Gründen getroffen hast, Eigenheiten deiner Entwicklungsumgebung.

Der offizielle Test für jede Zeile in CLAUDE.md: Würde das Entfernen dieser Zeile Claude einen Fehler machen lassen? Wenn nicht, streiche sie.

Nutze /init, um aus deiner bestehenden Codebasis eine Starter-CLAUDE.md zu generieren, bevor du etwas von Grund auf schreibst.

Die Anweisungspriorität für strukturierte Projekte: CLAUDE.md (hoch, immer geladen) über Rules-Verzeichnisse (hoch, pfad-gefiltert) über Skills (mittel, bei Bedarf geladen) über Dateiinhalte (Standard, wenn gelesen). Der Sweet Spot für ein strukturiertes Projekt sind 200 bis 400 Zeilen operative Regeln — nicht 60 Zeilen Projekttrivialitäten.

SESSION.md ist das andere Stück, das die meisten Builder überspringen. Pflege eine separate Datei, die verfolgt, was erledigt wurde, aktueller Status, offene Punkte und geänderte Schlüsseldateien. Aktualisiere sie vor dem Ende jeder Session. Starte neue Sessions mit "Resume project X." Halte fest, warum du entschieden hast, ein Feature zu implementieren oder nicht — mit Datum. SESSION.md macht Kontext-Overflow zu einem handhabbaren Ereignis statt einem projektbeendenden.

Der Wochenend-Build-Prozess

Jeder erfolgreiche Full-App-Build verwendete denselben Rhythmus: ein Feature pro Session, /clear zwischen Features.

Kontext-Übertragung von vorherigen Features verursacht falsche Annahmen und subtile Bugs. Wenn du ein Feature abschließt und das nächste anfängst, trägt Claude Annahmen darüber vor, was du gemacht hast. Diese Annahmen sind oft falsch für das neue Feature. /clear setzt den Kontext zurück und gibt dir einen sauberen Ausgangszustand.

Plan Mode vor jedem nicht-trivialen Feature. Shift+Tab zweimal oder /plan. Claude erforscht deine Codebasis und skizziert, welche Dateien es erstellen wird, welche Funktionen es einführen wird, welche Edge Cases existieren. Überprüfe und verfeinere den Plan vor der Ausführung. Füge immer "List any assumptions" zu deinem Plan-Prompt hinzu. Annahmen, die Claude still trifft, sind die Quelle der Bugs.

Was in einen guten Prompt gehört:

Scope: was dieses Feature tut und ausdrücklich, was es nicht tut
Einschränkungen: welche Dateien tabu sind, welchen Mustern zu folgen ist
Eine Beispieldatei: zeige auf eine bestehende Datei, die die gewünschte Form hat
Erfolgskriterien: spezifisch, testbar, nicht "mach es zum Laufen"

Der Erfolgskriterien-Teil verdient Betonung. Statt "implementiere E-Mail-Validierung" schreib: "Schreibe eine validateEmail-Funktion. Testfälle: user@example.com ist true, invalid ist false, user@.com ist false. Führe die Tests nach der Implementierung aus." Ohne Erfolgskriterien bist du der einzige Feedback-Loop.

Überprüfe immer den Diff, bevor du Output akzeptierst. Prüfe konkret auf Dateilöschungen, Public-API-Umbenennungen, Änderungen an tabuierten Dateien, neue Einträge in package.json und Schema-Migrationen. Claude kann öffentliche API-Endpunkte in deiner gesamten Codebasis umbenennen, ohne zu warnen. Jeder Client, der von diesen Endpunkten abhing, wird brechen. Der Diff ist der Ort, wo du es erwischst.

Kontext-Management: die Fähigkeit, die gute Builds von abgebrochenen trennt

Zu verstehen, was deinen Kontext-Fenster füllt, ist das, was Builds, die fertig werden, von Builds, die in Verwirrung abdriften, trennt.

Das effektive Kontextfenster für Claude Code liegt bei rund 200K Tokens, aber ca. 20K sind für Kompaktierungs-Output reserviert. Auto-Compact löst aus, wenn noch ca. 13.000 Tokens übrig sind. Eine Warnschwelle erscheint bei rund 20.000 Tokens. Manuelles Compact ist unter 3.000 Tokens blockiert. Diese Zahlen stammen aus der Analyse des Claude Code Quellcodes.

Drei offizielle Befehle:

/clear: Kontext zwischen nicht zusammenhängenden Aufgaben zurücksetzen. Nach zwei fehlgeschlagenen Korrekturen am selben Problem: aufhören zu korrigieren und /clear mit einem besseren initialen Prompt verwenden.
/compact <instructions>: Mit benutzerdefiniertem Fokus zusammenfassen. Beispiel: /compact Focus on the API changes behält den relevanten Kontext und lässt den Rest fallen.
Esc + Esc oder /rewind: Zurück zu dem Punkt, bevor etwas schiefging.

Für Untersuchungsaufgaben Sub-Agenten nutzen. In separaten Kontextfenstern laufen lassen, Zusammenfassungen zurückberichten. Deine Hauptsession bleibt sauber. Das Writer/Reviewer-Muster funktioniert genauso: Nutze eine frische Session, um Code zu überprüfen, den deine Hauptsession gerade geschrieben hat. Frischer Kontext erwischt Dinge, die ein müder Kontext übersieht.

Drei Anti-Muster aus den offiziellen Docs:

Die Kitchen-Sink-Session: eine Aufgabe, dann etwas Unrelated, dann zurück zur ersten. Kontext füllt sich mit irrelevanten Daten. Fix: /clear.

Immer wieder korrigieren: fehlgeschlagener Ansatz, du korrigierst, immer noch fehlerhaft, du korrigierst erneut. Nach zwei Korrekturen zum selben Problem: /clear und einen besseren initialen Prompt schreiben.

Endlose Erkundung: Claude bitten zu "untersuchen" ohne Scope, und es liest hunderte Dateien. Dein Kontext füllt sich mit Code, den du für dieses Feature nicht brauchst. Fix: Untersuchung eng eingrenzen oder Sub-Agenten nutzen.

SESSION.md löst das längerfristige Gedächtnisproblem. Nach ca. 30 Nachrichten kann Claude sich auf Entscheidungen beziehen, die nie getroffen wurden, anders erwähnte Dateien, oder Code, der früher in der Session verändert wurde. Die Session beginnt zu verwirren, was tatsächlich passiert ist. SESSION.md als externer Zustand, kombiniert mit /clear zwischen Features, verhindert, dass das einen Build entgleist.

Die Failure-Modes, vor denen niemand warnt

Dokumentiert, spezifisch, alle aus echten Projekten.

Ghost Files. GitHub Issue #26771 im offiziellen Claude Code Repository: Claude Code berichtet selbstsicher, Dateien erstellt zu haben, die nie auf die Festplatte geschrieben wurden. Der Tool-Output behauptet Erfolg. git status erzählt eine andere Geschichte. Ursachen sind Permission-Fehler, Pfad-Auflösungs-Fehler und verlorene Tool-Calls. Der Fix ist einfach: immer mit git status nach Dateioperationen überprüfen. Nicht davon ausgehen, dass die Datei existiert, weil Claude es gesagt hat.

API-Methoden-Halluzination. Claude generierte Code mit prisma.$upload(). Diese Methode existiert nicht in Prisma. Weitere dokumentierte Beispiele: erfundene Konfigurationsoptionen (trustProxy als Rate-Limiter-Option), erfundene Paketnamen, die nicht auf npm existieren. Fix: Deine Tests ausführen. Nicht annehmen, dass generierter Code funktioniert, weil er vernünftig aussieht.

Die Over-Engineering-Falle. Ein Builder mit 100+ Sessions Projekthistorie bat Claude, einen Bug zu beheben, bei dem Genehmigungspoups manchmal nicht erschienen. Claudes vorgeschlagener Fix: Genehmigungszustand auf der Festplatte speichern, damit er Abstürze überlebt. Das Problem: Der Agent nimmt nach einem Absturz aus dem Session-Log wieder auf, also würde der Genehmigungszustand sowieso nicht übernommen. Ein völlig nutzloser Fix, der wie gutes Engineering aussah. Die Frage vor dem Akzeptieren jedes komplexen Vorschlags: Muss dieses Problem wirklich gelöst werden?

Stille API-Umbenennungen. Claude benannte öffentliche API-Endpunkte in einer Codebasis um, ohne zu warnen. Jeder Client, der von diesen Endpunkten abhing, brach. Fix: immer den Diff überprüfen, bevor du akzeptierst. Konkret auf öffentliche API-Umbenennungen und Dateilöschungen prüfen.

Mobile Layouts. Claude generiert solide Desktop-Layouts. Mobile Views haben routinemäßig überlappende Elemente, Text-Overflow und beengten Abstand. Claude hat keinen Mechanismus, auf echten Geräten zu testen. Fix: Jedes Layout auf einem echten Handy prüfen, bevor es als erledigt gilt.

Kontext-Falscherinnerungen. Nach ca. 30 Nachrichten kann Claude sich auf Entscheidungen beziehen, die nie getroffen wurden, anders erwähnte Dateien, oder Code, der seit dem Gesprächsbeginn verändert wurde. Die Session beginnt zu verwirren, was tatsächlich passiert ist. Fix: SESSION.md als externer Zustand und /clear zwischen Features.

Das 80/20-Problem

Du kannst 80% einer funktionierenden App an einem Wochenende bekommen. Die restlichen 20% sind der Ort, wo die meisten vibe-codierten Projekte still scheitern.

Was nach dem initialen Build still scheitert: App-Store-Compliance, Real-Device-Performance, Auth-Flow-Security, Architekturentscheidungen (keine Tests, kein CI/CD) und Business-Logic-Edge-Cases. Das ist keine theoretische Beobachtung. Ein Unternehmen mit Millionen von Nutzern, mit KI-Beschleunigung gebaut, hatte fünf Ingenieure monatelang mit KI-Code-Review. Ihr Fazit: "Selbst Claude plus ein kompetenter Entwickler würde sich diesen Code ansehen und sagen: 'Ja, das ist okay.' Es war nicht okay."

Der WorthIt-Builder führte nach dem Launch einen dedizierten Security-Hardening-Pass durch und fand Input-Validierungslücken, fehlende Fehlerbehandlung und keinen XSS-Schutz. Security war nicht automatisch. Columbia DAPLab-Forschung identifiziert Fehlerbehandlung und Business-Logik als die schwerwiegendsten und häufigsten stillen Failure-Muster in KI-generiertem Code.

Der praktische Fix: Security als Teil jedes Features behandeln, nicht als Post-Launch-Schritt. Einen Security-Pass nach jedem größeren Feature ausführen. Mobile Layouts auf einem echten Gerät prüfen, bevor irgendetwas als erledigt gilt. Tests von Anfang an in die Erfolgskriterien aufnehmen — nicht als Nachgedanke.

Das ist kein Argument gegen das Bauen mit Claude Code. Es ist ein Argument dafür, ehrlich zu sein, was das Tool automatisch erledigt und was nicht.

Die strukturierte Alternative

Die oben beschriebenen Builds sind alle ad-hoc: eine Person, eine Claude-Code-Session, Feature für Feature. Dieser Ansatz funktioniert und hat echte Grenzen.

Die Grenzen zeigen sich vorhersehbar. Security ist nicht automatisch. Quality Gates erfordern Disziplin, um jedes Mal ausgeführt zu werden. Post-Launch-Infrastruktur (Error-Monitoring, Performance-Optimierung, Security-Scanning) muss für jedes Projekt separat aufgebaut oder eingerichtet werden. Die Over-Engineering-Falle und das Ghost-File-Problem erfordern manuelle Wachsamkeit.

Build This Now ist das, was die besten Vibe-Coder für sich selbst bauen. Es verpackt die Orchestrierung, Quality Gates und Post-Launch-Infrastruktur als fertig gemachtes System. Die 14 Post-Launch-Befehle (/security, /pentest, /performance, /audit) erledigen die Arbeit, die einzelne Builder nach dem Launch entdecken, dass sie sie brauchen. Row-Level-Security auf jeder Datenbanktabelle ist der Standard, nicht ein Nachgedanke. Die Quality-Gate- und Build-Fixer-Agenten fangen Fehler ab, die in Claudes Output vollständig aussehen, aber in der Praxis fehlschlagen. Der Planner-Agent trennt Architekturentscheidungen von der Implementierung, mit drei Spezialisten, die Features gleichzeitig analysieren, bevor Code geschrieben wird.

Der ad-hoc-Ansatz ist kostenlos und gut zum Lernen. Der strukturierte Ansatz ist das, was skaliert. buildthisnow.com hat die Details.

Die Wochenend-Builds oben sind keine Ausnahmefälle. Das ist das, was passiert, wenn du vor dem Prompting ein Spec schreibst, Kontext zwischen Features leerst, jeden Diff überprüfst und Security als Teil des Builds behandelst. Die Bandbreite reicht von einem GTA-Klon auf Google Earth bis zu einem Job-Suchsystem ohne Anwendungscode. Die Praktiken, die sie zum Erfolg gebracht haben, sind dieselben.