Construindo um Aplicativo de Produção de 200k LOC via Vibe Coding a partir de um Celular

Um desenvolvedor conduziu um experimento para testar se o "vibe coding" poderia lidar com um projeto de alta complexidade, construindo uma ferramenta profissional móvel de vibe coding chamada Vibe Remote (agora disponível gratuitamente na App Store). A ferramenta permite programar em movimento sem configurar Tailscale — os usuários escaneiam um código QR e começam a programar do seu celular.

Stack Tecnológica & Processo de Desenvolvimento

O projeto usa uma arquitetura multiplataforma: CLI, web (https://vibe-remote.com), backend em Go e iOS/macOS nativo em Swift. Possui nós globais, protocolos personalizados seguros e interfaces TUI.

A restrição era simples: construir a ferramenta usando a própria ferramenta. Após a primeira versão poder se comunicar, o desenvolvedor parou completamente de usar seu laptop. Mais de 95% do código foi escrito enviando mensagens ao Claude Code através do aplicativo enquanto vivia a vida lá fora.

Fluxo de Trabalho Diário & Soluções

A rotina diária envolvia empilhar 5-10 pontos de modificação em múltiplas sessões paralelas em casa, então pedir à IA para chamar uma habilidade personalizada deploy-to-iphone para enviar a build. Enquanto a IA trabalhava, o desenvolvedor assistia dramas curtos. No parque, ele agrupava mudanças no iOS para implantação em casa, mas para o backend Go e site SSR, ele pedia à IA para reiniciar o servidor local.

Para resolver o problema "não consigo ver minhas alterações locais no parque", ele fez a IA construir um navegador embutido e um túnel proxy dentro do próprio aplicativo, permitindo visualizar localhost:3000 da máquina de casa diretamente no celular através de um protocolo seguro.

Volume de Código & Velocidade

• Total de Linhas: ~200.000 (140k Go, 60k Swift)
• Curva de Velocidade: Nas primeiras 3 semanas, 150k linhas foram produzidas. A velocidade caiu de 10k linhas/dia para 1k, depois para 100-300 linhas de correções cirúrgicas por dia durante a fase de polimento.
• Exaustão: A fase de "ajuste fino" foi mais cansativa que a construção inicial, exigindo verificação constante de pequenos detalhes de UX com alta carga mental de "QA" via chat.

Principais Lições Aprendidas

O Problema DRY

Quando o projeto fica enorme, a IA falha em recuperar implementações existentes e começa a duplicar lógica. A solução: tratar instruções do claude.md como "Estatutos Legais" e pedir explicitamente: "Fizemos uma lógica similar para o Recurso X; vá encontrá-la, abstraia e reutilize. Não reimplemente." Sem isso, você obtém "código zumbi" onde corrigir um bug em um lugar o deixa em implementações duplicadas.

A Armadilha do TDD

Inicialmente usando fluxo TDD rigoroso (testes Unitários + E2E) com cada teste descrevendo um ramo funcional, falhando primeiro, depois passando. Embora o Opus 4.6 seja ótimo nisso, testes E2E se tornaram um gargalo — esperar execuções completas da suíte E2E matou a eficiência. O desenvolvedor eventualmente eliminou os E2Es em favor de Testes Unitários de alta densidade para manter o "Vibe" rápido.

Abandone Ferramentas "Superpoderosas"

O desenvolvedor desinstalou extensões "Superpoderosas", descobrindo que para 95% das tarefas, linguagem natural pura em múltiplas sessões é melhor. Eles só usam um "Modo Plano" quando a IA fica travada, com este prompt: "Você tentou isso algumas vezes e falhou. Resuma o feedback, pesquise a melhor prática da indústria e me dê um plano de execução único." Pequenas demandas precisas em múltiplas threads paralelas são mais eficazes para iterações orientadas a detalhes do que um prompt gigante e complexo.

Pare de se Preocupar com Worktrees do Git

Muitos defendem worktrees separados por agente, mas o desenvolvedor discorda. Eles executaram até 40+ agentes no mesmo branch simultaneamente, descobrindo que funciona contanto que você confie na IA.