Erstellen einer 200.000-Zeilen-Produktions-App per Vibe Coding von einem Telefon aus

Ein Entwickler führte ein Experiment durch, um zu testen, ob "Vibe Coding" ein hochkomplexes Projekt bewältigen kann, und baute dabei ein professionelles mobiles Vibe-Coding-Tool namens Vibe Remote (jetzt kostenlos im App Store erhältlich). Das Tool ermöglicht es, unterwegs zu programmieren, ohne Tailscale konfigurieren zu müssen – Benutzer scannen einen QR-Code und beginnen direkt vom Handy aus mit dem Coden.
Tech-Stack & Entwicklungsprozess
Das Projekt verwendet eine Multi-Plattform-Architektur: CLI, Web (https://vibe-remote.com), Backend in Go und native iOS/macOS in Swift. Es bietet globale Nodes, sichere benutzerdefinierte Protokolle und TUI-Oberflächen.
Die Einschränkung war einfach: Baue das Tool mit dem Tool selbst. Nachdem die erste Version kommunizieren konnte, hörte der Entwickler komplett auf, seinen Laptop zu benutzen. Über 95 % des Codes wurden durch das Senden von Nachrichten an Claude Code über die App geschrieben, während der Entwickler unterwegs war und sein Leben lebte.
Täglicher Workflow & Lösungen
Die tägliche Routine bestand darin, 5–10 Änderungspunkte über mehrere parallele Sitzungen zu Hause zu stapeln und dann der KI zu sagen, dass sie eine benutzerdefinierte deploy-to-iphone-Fähigkeit aufrufen soll, um den Build zu pushen. Während die KI arbeitete, schaute der Entwickler kurze Dramen. Im Park batched er iOS-Änderungen für das Deployment zu Hause, aber für das Go-Backend und die SSR-Site sagte er der KI, den lokalen Server neu zu starten.
Um das Problem "Ich kann meine lokalen Änderungen im Park nicht sehen" zu lösen, ließ er die KI einen eingebauten Browser und einen Proxy-Tunnel in die App selbst bauen, was eine Vorschau von localhost:3000 vom Heimrechner direkt auf dem Handy über ein sicheres Protokoll ermöglichte.
Codeumfang & Geschwindigkeit
- Gesamtzahl der Zeilen: ~200.000 (140k Go, 60k Swift)
- Geschwindigkeitskurve: In den ersten 3 Wochen wurden 150k Zeilen produziert. Die Geschwindigkeit sank von 10k Zeilen/Tag auf 1k, dann auf 100–300 Zeilen präziser Fixes pro Tag während der Feinschliffphase.
- Erschöpfung: Die "Feinabstimmungs"-Phase war anstrengender als der anfängliche Build, da ständig winzige UX-Details überprüft werden mussten und die mentale Belastung durch das "QA-ing" über Chat hoch war.
Wichtige Erkenntnisse
Das DRY-Problem
Sobald das Projekt riesig wird, kann die KI bestehende Implementierungen nicht mehr abrufen und beginnt, Logik zu duplizieren. Die Lösung: Behandle claude.md-Anweisungen wie "Gesetzestexte" und fordere explizit: "Wir haben eine ähnliche Logik für Feature X gemacht; finde sie, abstrahiere sie und verwende sie wieder. Implementiere sie nicht neu." Ohne dies erhältst du "Zombie-Code", bei dem die Behebung eines Fehlers an einer Stelle ihn in duplizierten Implementierungen belässt.
Die TDD-Falle
Anfangs wurde ein strenger TDD-Flow (Unit- + E2E-Tests) verwendet, wobei jeder Test einen Funktionszweig beschrieb, zuerst scheiterte und dann bestand. Während Opus 4.6 darin großartig ist, wurden E2E-Tests zu einem Engpass – das Warten auf vollständige E2E-Suite-Läufe tötete die Effizienz. Der Entwickler entfernte schließlich die E2Es zugunsten von hochdichten Unit-Tests, um den "Vibe" schnell zu halten.
Verzichte auf "Superpower"-Tools
Der Entwickler deinstallierte "Superpower"-Erweiterungen und stellte fest, dass für 95 % der Aufgaben reine natürliche Sprache in mehreren Sitzungen besser ist. Er verwendet nur einen "Plan-Modus", wenn die KI steckenbleibt, mit diesem Prompt: "Du hast dies ein paar Mal versucht und bist gescheitert. Fasse das Feedback zusammen, recherchiere die beste Branchenpraxis und gib mir einen One-Shot-Ausführungsplan." Kleine, präzise Anforderungen in mehreren parallelen Threads sind effektiver für detailorientierte Iterationen als ein riesiger, komplexer Prompt.
Hör auf, dir über Git-Worktrees Sorgen zu machen
Viele befürworten separate Worktrees pro Agent, aber der Entwickler ist anderer Meinung. Er lief bis zu 40+ Agents gleichzeitig auf demselben Branch und stellte fest, dass es funktioniert, solange man der KI vertraut.
📖 Lies die vollständige Source: r/ClaudeAI
👀 Siehe auch

RunLobster KI-Agent erstellt funktionale Dashboards aus natürlichen Sprachanfragen.
Ein Entwickler berichtet, dass RunLobster als Reaktion auf einen einzigen Befehl in natürlicher Sprache ein vollständiges Dashboard mit Stripe-Integration und Authentifizierung erstellt und bereitgestellt hat, womit in Minuten erledigt wurde, was normalerweise Tage dauern würde.

Benutzer erstellt HTML-Konverter für Claude-Chat-Exporte mithilfe von Claude selbst
Ein Nicht-Programmierer nutzte Claude, um einen Konverter zu erstellen, der Claudes native JSON-Chat-Exporte in lesbares HTML mit farbcodierten Nachrichten, klappbaren Konversationen und Organisation nach Datum und Uhrzeit umwandelt.

Ausführen von OpenClaw AI-Tools auf einem Low-End-Laptop ohne GPU
Ein Nutzer hat OpenClaw AI-Tools erfolgreich auf einem einfachen Laptop ohne dedizierte GPU ausgeführt und seinen Einrichtungsprozess in einem YouTube-Tutorial geteilt.

Wie man Claude AI als Denkpartner statt als Suchmaschine nutzt
Ein Reddit-Nutzer erklärt, dass die Behandlung von Claude wie Google sein Potenzial einschränkt. Stattdessen sollten Nutzer in einen Dialog treten, Kontext über Ziele und Versuche geben und Claude nutzen, um ihr eigenes Denken zu testen.