Vibe Coding desde el móvil con Claude Code: 7 reglas

Desarrollar un proyecto entero desde el móvil suena a humo. Hasta que ves cómo lo hace alguien que lleva una década escribiendo código y descubres que el truco no está en el teléfono, sino en las reglas.

TL;DR: vibe coding desde el móvil con Claude Code

• El vibe coding desde el móvil consiste en dirigir a Claude Code con instrucciones en lenguaje natural y sin revisar el código generado, usando la app o el navegador del teléfono como única interfaz.
• Funciona porque Claude Code on the web ejecuta cada sesión en una máquina virtual aislada en la nube, así que el riesgo de un comando destructivo queda contenido.
• La diferencia entre un desastre y un proyecto que avanza son 7 reglas escritas en el CLAUDE.md: plan obligatorio, tests como red de seguridad y límites claros sobre qué no tocar.

El problema: dirigir un agente sin ver el editor

En octubre de 2025 Anthropic lanzó Claude Code on the web y la integración con la app móvil. La promesa: arrancar una tarea desde el teléfono, que el agente trabaje en una VM en la nube y seguir la conversación mientras ejecuta.

El problema real aparece cuando intentas hacer esto sin disciplina. En el móvil no hay editor, no hay diff cómodo, no hay terminal con scroll infinito. Si tu forma de trabajar depende de leer cada línea que escribe el agente, el móvil te bloquea.

La pregunta no es "¿puedo programar desde el móvil?". Es "¿qué tiene que ser cierto para que delegar a ciegas no acabe en un incendio?". Y la respuesta está en cómo configuras el agente antes de pulsar enviar.

¿Qué es el vibe coding desde el móvil?

El vibe coding desde el móvil es delegar la implementación completa de una funcionalidad a un agente de código a través del teléfono, describiendo el resultado deseado en lenguaje natural y validando por comportamiento, no por inspección del código.

Claude Code on the web es la versión que corre cada sesión en un sandbox aislado en la infraestructura de Anthropic, accesible desde claude.ai/code o la app móvil. El aislamiento es la pieza que cambia las reglas del juego: un agente que se equivoca en una VM efímera no toca tu máquina ni tu entorno local.

Esto no convierte el "no leer el código" en algo gratis. Lo convierte en una decisión deliberada, válida para side projects y prototipos, arriesgada para sistemas con usuarios reales. La frontera la pones tú.

Las 7 reglas para delegar de verdad

Estas reglas viven en el CLAUDE.md del proyecto. El agente las lee al arrancar cada sesión, también en la nube. Son el equivalente a un onboarding para un compañero que no te puede preguntar nada.

1. Plan mode obligatorio antes de tocar nada

La regla más importante. El agente debe presentar un plan y esperar tu aprobación antes de editar archivos. Desde el móvil, leer un plan de cinco puntos es viable; revisar 300 líneas de diff, no.

La documentación oficial de Claude Code recomienda plan mode cuando el cambio afecta a varios archivos o no conoces bien el código. Trabajando a ciegas, esa condición se cumple siempre. Si quieres profundizar en cómo explorar antes de actuar, el enfoque de investigar primero un repositorio antes de modificarlo encaja perfecto aquí.

2. El CLAUDE.md es la única interfaz de control

Sin editor, tu único punto de control persistente es el archivo de contexto. Ahí defines el stack, las convenciones y los límites. Un CLAUDE.md mínimo y preciso vale más que diez prompts improvisados.

# Reglas del agente
- Plan mode SIEMPRE antes de editar. Sin plan aprobado, no tocas codigo.
- Stack fijo: FastAPI + PostgreSQL. No anadas dependencias sin pedir permiso.
- Cada cambio necesita tests. Si no pasan, la tarea no se cierra.
- NUNCA toques: .env, migraciones de BD, ramas de produccion.
- Commits atomicos en formato conventional commits.

Como ya conté al hablar de que la configuración pesa más que el modelo elegido, un agente potente con instrucciones vagas rinde peor que uno modesto con reglas claras.

3. Tests automáticos como red de seguridad

Si no vas a leer el código, los tests son tu forma de leerlo. La regla: cada cambio incluye tests y el agente no cierra la tarea hasta que pasan en verde. Tú no validas el código, validas que el comportamiento esperado se cumple.

Esto cambia el contrato. En lugar de "escribe esta función", pides "esta función debe cumplir estos casos" y dejas que el agente itere hasta lograrlo.

4. Hooks que bloquean lo que no compila ni pasa el linter

Los hooks ejecutan comandos automáticamente tras cada acción del agente. Configurados bien, son un control de calidad que no depende de tu vigilancia.

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Edit|Write",
        "hooks": [{ "type": "command",
          "command": "npm run lint && npm test" }] }
    ]
  }
}

Si el linter o los tests fallan, el agente recibe el error y corrige sin que tú intervengas. Es la misma idea que desarrollé sobre automatizar checks con hooks sin tocar tu flujo, llevada al extremo del trabajo móvil.

5. Una tarea = una sesión = un PR

El alcance pequeño es innegociable. Una sesión móvil debe producir un cambio acotado y revisable: un endpoint, un bug, un componente. Nada de "refactoriza todo el módulo".

Con tareas pequeñas, si algo sale mal el blast radius es mínimo y revertir es un git revert. Con tareas enormes, un error a ciegas se vuelve imposible de auditar después.

6. Reglas de "no toques" explícitas

El agente necesita saber qué territorio está prohibido. Secretos, archivos .env, migraciones de base de datos, ramas de producción y configuración de CI. Cualquier acción sobre esas zonas exige confirmación expresa.

Esta regla convierte "delegación total" en "delegación con límites", que es lo único sostenible. El agente es autónomo dentro de un perímetro que tú dibujas.

7. Confía, pero pide resúmenes en lenguaje natural

No leer el código no significa no entender qué pasó. Pide al agente que, al terminar, explique en tres frases qué cambió y por qué. Ese resumen es lo que revisas desde el móvil.

Si el resumen no tiene sentido o contradice lo que pediste, ahí es cuando abres el portátil. El resumen es el sensor que te avisa de cuándo dejar de confiar.

Caso real: arreglar un bug desde el tren

En escenarios reales, este flujo brilla en situaciones concretas. Imagina un side project, un blog personal o una API pequeña, con un bug reportado mientras estás fuera de casa.

Abres la app, describes el síntoma: "el endpoint /posts devuelve 500 cuando el parámetro tag está vacío". El agente entra en plan mode, propone reproducir el error con un test, corregir la validación y verificar. Apruebas. Trabaja en la VM, los hooks ejecutan el linter y la suite, el resumen final confirma el fix.

Tú nunca leíste el código. Leíste el plan, el resumen y el verde de los tests. Para un proyecto de bajo riesgo, eso es suficiente. Para el sistema de facturación de tu trabajo, no: ahí el código se revisa, sí o sí.

En Producción

El salto del side project al trabajo serio cambia varias cosas. Conviene tenerlas claras antes de delegar a ciegas en algo que importa.

• Coste: Claude Code on the web está incluido en los planes Pro y Max de Claude, que rondan los 17 a 100 € al mes según el nivel. El consumo móvil no añade un coste aparte, pero las sesiones largas agotan los límites de uso igual que en escritorio.
• Manejo de errores: los hooks y los tests son tu control sólido de errores. Sin ellos, delegar a ciegas es apostar. Con ellos, un fallo se detecta antes de llegar al merge.
• Límites del modelo: el agente en la nube no ve tu entorno local ni servicios privados salvo que los expongas. Tareas que dependen de infraestructura interna no son candidatas para el móvil.
• Qué cambia frente al tutorial: en producción real el "no leer el código" desaparece. El flujo móvil sirve para arrancar, planificar y avanzar; la revisión humana del diff sigue siendo obligatoria antes de tocar algo con usuarios.

Una capa de contexto bien diseñada ayuda a que las sesiones cortas no pierdan el hilo. Si trabajas en proyectos de varios días, vale la pena entender las tres capas de memoria que evitan el vertedero de contexto en Claude Code.

Errores comunes y depuración

Error: el agente edita archivos sin presentar plan. Causa: la regla de plan mode está como sugerencia, no como obligación. Solución: redacta la regla en imperativo y mayúsculas ("SIEMPRE", "NUNCA"), y activa plan mode también desde la sesión.

Error: los tests pasan pero el comportamiento es incorrecto. Causa: el agente escribió tests que validan su propia implementación errónea. Solución: define tú los casos de prueba críticos en el prompt o en el CLAUDE.md, no dejes que el agente decida qué probar.

Error: la sesión móvil se queda sin contexto a mitad de tarea. Causa: tarea demasiado grande para una sola sesión. Solución: aplica la regla 5, parte el trabajo en cambios pequeños e independientes.

Error: el agente toca un archivo de configuración sensible. Causa: la lista de "no toques" no incluía ese archivo. Solución: amplía la regla 6 y, en proyectos con secretos, apóyate en el aislamiento del sandbox como segunda barrera.

Preguntas frecuentes

¿Es seguro programar desde el móvil sin leer el código?

Es razonable para side projects y prototipos de bajo riesgo, gracias al sandbox aislado de Claude Code on the web. Para sistemas con usuarios reales, el código debe revisarse antes del merge: el móvil sirve para avanzar, no para saltarse el control humano.

¿Necesito una app de terceros para usar Claude Code en el móvil?

No. La app oficial de Claude y claude.ai/code permiten lanzar y seguir sesiones desde el teléfono. La interfaz es básica, una terminal en el navegador, pero suficiente para leer planes y resúmenes. Las apps de terceros añaden UI más cómoda, no capacidades nuevas.

¿Qué modelo conviene usar para trabajar a ciegas?

Para planificación y tareas complejas, un modelo de razonamiento alto reduce errores que no vas a detectar leyendo. Vale la pena revisar cuándo subir el nivel de razonamiento en Claude Code y cuándo no, porque más esfuerzo también significa más coste y latencia.

Conclusión

Hemos visto que el vibe coding desde el móvil no es magia ni humo: es la consecuencia de mover el control del editor al CLAUDE.md. Las 7 reglas, plan obligatorio, archivo de contexto como interfaz, tests, hooks, alcance pequeño, zonas prohibidas y resúmenes en lenguaje natural, son lo que separa delegar de abdicar.

La clave está en entender qué proyectos toleran este flujo. Un side project y un sistema en producción no juegan con las mismas cartas, y confundirlos es el error caro. El móvil te da velocidad para arrancar y avanzar; la revisión humana sigue siendo el freno que decides cuándo soltar.

¿Has probado a delegar una tarea completa a Claude Code desde el móvil? Cuéntame qué reglas te funcionaron en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo veré cómo encadenar varias de estas sesiones móviles en un flujo de trabajo diario sin perder el control.