Building a 200k LOC Production App via Vibe Coding from a Phone

A developer conducted an experiment to test if "vibe coding" could handle a high-complexity project, building a professional mobile vibe-coding tool called Vibe Remote (now available free on the App Store). The tool allows coding on the go without configuring Tailscale—users scan a QR code and start coding from their phone.

Tech Stack & Development Process

The project uses a multi-platform architecture: CLI, web (https://vibe-remote.com), backend in Go, and native iOS/macOS in Swift. It features global nodes, secure custom protocols, and TUI interfaces.

The constraint was simple: build the tool using the tool. After the first version could communicate, the developer stopped using their laptop entirely. Over 95% of the code was written by messaging Claude Code through the app while out living life.

Daily Workflow & Solutions

The daily routine involved stacking 5-10 modification points across multiple parallel sessions at home, then telling the AI to call a custom deploy-to-iphone skill to push the build. While the AI worked, the developer would watch short dramas. At the park, they'd batch iOS changes for home deployment, but for the Go backend and SSR site, they'd tell the AI to restart the local server.

To solve the "I can't see my local changes at the park" problem, they had the AI build a built-in browser and a proxy tunnel into the app itself, allowing preview of localhost:3000 from the home machine directly on the phone via a secure protocol.

Code Volume & Velocity

• Total Lines: ~200,000 (140k Go, 60k Swift)
• Velocity Curve: In the first 3 weeks, 150k lines were produced. Speed dropped from 10k lines/day to 1k, then to 100-300 lines of surgical fixes per day during polish phase.
• Exhaustion: The "fine-tuning" phase was more tiring than the initial build, requiring constant verification of tiny UX details with high mental load from "QA-ing" via chat.

Key Lessons Learned

The DRY Problem

Once the project gets huge, the AI fails to retrieve existing implementations and starts duplicating logic. The fix: treat claude.md instructions like "Legal Statutes" and explicitly prompt: "We did a similar logic for Feature X; go find it, abstract it, and reuse it. Do not reimplement." Without this, you get "zombie code" where fixing a bug in one place leaves it in duplicate implementations.

The TDD Trap

Initially using strict TDD flow (Unit + E2E tests) with every test describing a functional branch, failing first, then passing. While Opus 4.6 is great at this, E2E tests became a bottleneck—waiting for full E2E suite runs killed efficiency. The developer eventually nuked E2Es in favor of high-density Unit Tests to keep the "Vibe" fast.

Ditch "Superpower" Tools

The developer uninstalled "Superpower" extensions, finding that for 95% of tasks, raw natural language in multiple sessions is better. They only use a "Plan Mode" when the AI gets stuck, with this prompt: "You've tried this a few times and failed. Summarize the feedback, research the industry best practice, and give me a one-shot execution plan." Small, precise demands in multiple parallel threads are more effective for detail-oriented iterations than one giant, complex prompt.

Stop Worrying about Git Worktrees

Many advocate for separate worktrees per agent, but the developer disagrees. They ran up to 40+ agents on the same branch simultaneously, finding it works as long as you trust the AI.