Back to blog
I Vibe Coding a 200k LOC production app entirely from my phone
2026-03-26

I Vibe Coding a 200k LOC production app entirely from my phone

Zhu
ZhuVibe Remote Creator

I built a 200k LOC production-grade startup project entirely on my phone via "Vibe Coding." No IDE, no laptop, just Claude Code and a stroller.

I wanted to see if "Vibe Coding" could actually handle a high-complexity project—not just a Todo list, but something with A-round startup quality. The goal: build a professional mobile vibe-coding tool (Vibe Remote, now on App Store) that lets you code on the go without configuring Tailscale. Just scan a QR code and start coding from your phone.

The Tech Stack:

  • Architecture: Multi-platform CLI, Web (SSR), Backend (Go), Native iOS/macOS (Swift).
  • Scale: Global nodes, secure custom protocols, TUI interfaces.
  • The Constraint: The experiment was simple: Build the tool using the tool. Once I had the very first version that could communicate, I stopped using my laptop entirely. From that point on, over 95% of the code was written by messaging Claude Code through the app itself while I was out living my life.

My daily routine looked like this: At home, I’d stack 5-10 modification points across multiple parallel sessions. Once done, I’d tell the AI to call a custom deploy-to-iphone skill to push the build. While the AI worked, I’d be in the living room watching short dramas (CDramas).

When I was at the park pushing a stroller, I’d batch all iOS changes for home deployment, but for the Go backend and SSR site, I’d just tell the AI to restart the local server. To solve the "I can't see my local changes at the park" problem, I had the AI build a built-in browser and a proxy tunnel into the app itself. This way, I could preview localhost:3000 from my home machine directly on my phone via my own secure protocol.

The Code Volume & Velocity:

  • Total Lines: ~200,000 (140k Go, 60k Swift).
  • The Velocity Curve: In the first 3 weeks, we churned out 150k lines. But as the product matured, speed dropped. It went from 10k lines/day to 1k, and finally to just 100-300 lines of surgical fixes per day during the polish phase.
  • The Exhaustion: Honestly, the "fine-tuning" phase is more tiring than the initial build. You have to verify tiny UX details constantly, and the mental load of "QA-ing" via chat is real.

Key Hard-Earned Lessons:

  1. The DRY (Don't Repeat Yourself) Problem: This is the biggest trap. Once the project gets huge, the AI fails to retrieve existing implementations and starts duplicating logic.

    • The Fix: I started treating my .md instructions like "Legal Statutes." I also began explicitly prompting: "We did a similar logic for Feature X; go find it, abstract it, and reuse it. Do not reimplement." If you don't do this, you'll end up with "zombie code" where you fix a bug in one place but it persists in the duplicate implementation.

  2. The TDD Trap: Initially, I forced a strict TDD flow (Unit + E2E tests). Every test had to describe a functional branch, fail first, and then pass. While Opus 4.6 is great at this, E2E tests eventually became a bottleneck. Waiting for a full E2E suite to run while I’m trying to iterate fast was killing my efficiency. I’d finish two episodes of a show and the tests were still running. I eventually nuked the E2Es in favor of high-density Unit Tests to keep the "Vibe" fast.

  3. Ditch the "Superpower" Tools: I actually uninstalled "Superpower" extensions. For 95% of tasks, raw natural language in multiple sessions is better. I only use a "Plan Mode" when the AI gets stuck.

    • The "Plan" 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 much more effective for detail-oriented iterations than one giant, complex prompt.

  4. Stop Worrying about Git Worktrees: Many people advocate for separate worktrees per agent. I disagree. I ran up to 40+ agents on the same branch simultaneously. As long as you trust the AI, they rarely collide. It allows for better integrated verification.

The app itself evolved because I was using it. I noticed I needed to browse local files, so I built a file explorer. I needed better Git diffs and tree views, so we added them. I hated the ChatGPT-style sidebar for switching between 40 active sessions—it's not intuitive on mobile. So, I "insanely" designed a three-row scrolling tab system (like a terminal on steroids) specifically for mobile multi-tasking.

Vibe coding isn't just for prototypes. If you build the right "skills" (deployment, proxying, testing), you can genuinely build a high-tier commercial product while living your life.

It’s not just another Claude wrapper; it’s designed for the "park-bench engineer." Check out Vibe Remote on the App Store if you want to see what 200k lines of "stroller-pushed" code looks like.