Construyendo una Aplicación de Producción de 200k LOC mediante Vibe Coding desde un Teléfono

Un desarrollador realizó un experimento para probar si la "codificación por vibración" podía manejar un proyecto de alta complejidad, construyendo una herramienta profesional de codificación por vibración para móviles llamada Vibe Remote (ahora disponible gratis en la App Store). La herramienta permite codificar sobre la marcha sin configurar Tailscale: los usuarios escanean un código QR y comienzan a codificar desde su teléfono.
Stack Tecnológico y Proceso de Desarrollo
El proyecto utiliza una arquitectura multiplataforma: CLI, web (https://vibe-remote.com), backend en Go, y aplicaciones nativas para iOS/macOS en Swift. Incluye nodos globales, protocolos personalizados seguros e interfaces TUI.
La restricción era simple: construir la herramienta usando la herramienta. Después de que la primera versión pudiera comunicarse, el desarrollador dejó de usar su portátil por completo. Más del 95% del código fue escrito enviando mensajes a Claude Code a través de la aplicación mientras vivía su vida fuera de casa.
Flujo de Trabajo Diario y Soluciones
La rutina diaria implicaba acumular 5-10 puntos de modificación en múltiples sesiones paralelas en casa, luego pedirle a la IA que llamara a una habilidad personalizada deploy-to-iphone para enviar la compilación. Mientras la IA trabajaba, el desarrollador veía dramas cortos. En el parque, agrupaba los cambios de iOS para implementarlos en casa, pero para el backend en Go y el sitio SSR, le pedía a la IA que reiniciara el servidor local.
Para resolver el problema de "no puedo ver mis cambios locales en el parque", hicieron que la IA construyera un navegador integrado y un túnel proxy dentro de la aplicación misma, permitiendo previsualizar localhost:3000 desde la máquina de casa directamente en el teléfono a través de un protocolo seguro.
Volumen y Velocidad del Código
- Líneas Totales: ~200.000 (140k Go, 60k Swift)
- Curva de Velocidad: En las primeras 3 semanas, se produjeron 150k líneas. La velocidad cayó de 10k líneas/día a 1k, luego a 100-300 líneas de correcciones quirúrgicas por día durante la fase de pulido.
- Agotamiento: La fase de "ajuste fino" fue más agotadora que la construcción inicial, requiriendo verificación constante de pequeños detalles de UX con alta carga mental por "control de calidad" a través del chat.
Lecciones Clave Aprendidas
El Problema DRY
Una vez que el proyecto se vuelve enorme, la IA falla al recuperar implementaciones existentes y comienza a duplicar lógica. La solución: tratar las instrucciones de claude.md como "Estatutos Legales" y pedir explícitamente: "Hicimos una lógica similar para la Característica X; ve a buscarla, abstraela y reutilízala. No la reimplementes". Sin esto, obtienes "código zombie" donde arreglar un error en un lugar lo deja en implementaciones duplicadas.
La Trampa del TDD
Inicialmente usando un flujo TDD estricto (pruebas Unitarias + E2E) con cada prueba describiendo una rama funcional, fallando primero, luego pasando. Aunque Opus 4.6 es excelente en esto, las pruebas E2E se convirtieron en un cuello de botella: esperar las ejecuciones completas del conjunto E2E mataba la eficiencia. El desarrollador eventualmente eliminó las E2E en favor de Pruebas Unitarias de alta densidad para mantener la "Vibración" rápida.
Abandona las Herramientas "Superpoderosas"
El desarrollador desinstaló extensiones "Superpoderosas", encontrando que para el 95% de las tareas, el lenguaje natural puro en múltiples sesiones es mejor. Solo usan un "Modo Plan" cuando la IA se atasca, con este mensaje: "Has intentado esto varias veces y fallaste. Resume la retroalimentación, investiga la mejor práctica de la industria y dame un plan de ejecución de una sola vez". Demandas pequeñas y precisas en múltiples hilos paralelos son más efectivas para iteraciones orientadas a detalles que un mensaje gigante y complejo.
Deja de Preocuparte por los Worktrees de Git
Muchos abogan por worktrees separados por agente, pero el desarrollador no está de acuerdo. Ejecutaron hasta 40+ agentes en la misma rama simultáneamente, encontrando que funciona siempre que confíes en la IA.
📖 Lee la fuente completa: r/ClaudeAI
👀 Ver también

Claude como único profesor de arte: Resultados de la primera semana y sorpresas en la crítica
Un desarrollador utilizó a Claude como su único profesor para retratos a lápiz de colores. La crítica de Claude ignoró la mezcla de tonos de piel y señaló el boceto inicial de cinco minutos como la raíz del problema.

Arquitectura OpenClaw: Construyendo un Motor de Distribución Persistente Impulsado por IA
La arquitectura de OpenClaw, que presenta un enfoque impulsado por un daemon con pequeñas herramientas componibles, recetas declarativas y una capa de memoria, permite flujos de trabajo de automatización continuos y eficientes.

Usuario de Reddit reporta mejores resultados con Claude después de cambiar el enfoque de los prompts.
Un desarrollador pasó días luchando con múltiples herramientas de IA antes de encontrar éxito con Claude al cambiar de indicaciones estilo motor de búsqueda a conversaciones de ida y vuelta con contexto específico sobre por qué los enfoques no funcionaban.

No desarrollador crea aplicación web Sleep Sound Mixer usando Claude AI
Un usuario sin conocimientos de programación utilizó Claude AI para crear una aplicación web completamente funcional de Mezclador de Sonidos para Dormir en una sola sesión. La aplicación permite mezclar seis sonidos ambientales con controles de volumen individuales a través de una interfaz de navegador limpia y minimalista.