01 Por qué funciona separar en fases
Pedir «hazme una app de reservas» en una sola frase obliga a Claude a adivinar el público, las funciones, la tecnología y el alcance. Acierta en algunas cosas y en otras no, y tú descubres los fallos cuando ya hay cientos de líneas escritas. Separar el trabajo en fases hace que cada decisión se tome una vez, por escrito, antes de pasar a la siguiente.
Además ahorra cuota: las conversaciones exploratorias, que son las que más mensajes consumen, las hace el modelo más ligero, y el modelo más potente solo interviene donde su razonamiento marca la diferencia.
| Fase | Modelo | Resultado que debes guardar |
|---|---|---|
| 1. Aclarar la idea | Haiku | idea.md con respuestas a qué, para quién y por qué |
| 2. Especificar | Sonnet | spec.md con funciones, pantallas, datos y límites |
| 3. Planificar | Opus (en modo plan) | plan.md con arquitectura, dependencias y fases |
| 4. Construir | Sonnet u Opus | Código funcionando, fase a fase y probado |
02 Preparación
mkdir mi-proyecto && cd mi-proyecto
git init
claude03 Fase 1: aclara la idea con Haiku
Cambia a Haiku con /model haiku. Aquí no buscas respuestas brillantes, sino buenas preguntas que te obliguen a concretar. Responde con calma; si no sabes algo, dilo y que te proponga opciones.
Quiero construir esto: [tu idea en dos o tres frases, aunque esté incompleta]. Antes de proponer nada, entrevístame. Hazme una sola pregunta cada vez sobre el problema que resuelve, quién lo usará, cómo lo resuelven hoy, qué es imprescindible en la primera versión y qué puede esperar. Cuando tengas suficiente, resume todo en idea.md con lenguaje sencillo.04 Fase 2: convierte la idea en una especificación con Sonnet
Cambia a /model sonnet y limpia el contexto con /clear: la especificación debe salir del archivo, no de la charla anterior. Este paso detecta huecos que no habías visto, como qué pasa si un usuario cancela o quién puede ver qué datos.
Lee idea.md. Redacta spec.md con: objetivo y usuarios, lista de funciones de la primera versión priorizadas, pantallas o pasos principales, datos que se guardan, integraciones externas, requisitos de privacidad y lo que queda explícitamente fuera. Señala con [DUDA] todo lo que no puedas deducir y pregúntamelo al final, no lo inventes.05 Fase 3: pide el plan técnico a Opus
Con /model opus y el modo plan activo (/plan), Claude investiga y propone sin tocar archivos. Otra opción es /model opusplan, que usa Opus mientras planifica y cambia solo a Sonnet al ejecutar. Lee el plan entero: es el momento más barato para cambiar de opinión.
Lee spec.md. Propón un plan técnico en plan.md: tecnología recomendada con el motivo y una alternativa más sencilla, estructura de carpetas, dependencias, modelo de datos y fases de construcción. Cada fase debe acabar en algo que yo pueda probar en el navegador y tener sus criterios de aceptación. Prioriza lo simple y fácil de mantener sobre lo espectacular.06 Fase 4: construye por fases
Vuelve a Sonnet para ejecutar. Si tu plan te da margen y el proyecto es complejo, puedes quedarte en Opus. Lo importante es avanzar fase a fase y comprobar cada una antes de seguir.
Lee plan.md y ejecuta solo la fase [número]. Antes de empezar, dime qué archivos vas a crear o modificar. Al terminar, ejecuta las pruebas o arranca el proyecto, comprueba los criterios de aceptación y dime exactamente cómo lo pruebo yo. Si tienes que tomar una decisión que no está en el plan, pregúntame.-
1
Prueba tú mismo
Abre el proyecto y sigue las instrucciones de prueba. No pases a la siguiente fase con algo a medias.
-
2
Guarda el punto
Pide un commit con un mensaje que explique qué se ha añadido.
-
3
Actualiza el plan
Marca la fase como hecha en plan.md y anota cualquier cambio de rumbo.
-
4
Limpia el contexto
Usa /clear antes de la siguiente fase: el plan y el código ya contienen todo lo necesario.
07 Errores que conviene evitar
- ✓Saltarse la especificación porque «ya lo tengo claro»: las dudas aparecen igual, pero más tarde y más caras.
- ✓Pedir todas las fases de golpe: si algo falla en la segunda, todo lo demás se construye sobre un error.
- ✓Aceptar un plan con tecnología que nadie de tu equipo podrá mantener.
- ✓Guardar claves de API en el código: pide desde el principio un archivo .env fuera de Git.
- ✓Publicar sin revisar seguridad: antes de abrirlo a clientes, pide una revisión específica de permisos y datos.
Preguntas frecuentes
No para seguir el proceso, pero sí para valorar riesgos cuando el proyecto vaya a manejar datos reales o pagos. En ese punto conviene una revisión profesional.
Haz la fase 3 con Sonnet y esfuerzo alto. El resultado será algo menos profundo, pero el método sigue funcionando.
Porque las conversaciones se olvidan y se compactan. Los archivos sobreviven a /clear, a nuevas sesiones y a otros modelos, y te permiten retomar el proyecto días después.
Sí. El mismo flujo funciona para una web corporativa, un script de automatización o un informe técnico: aclarar, especificar, planificar y ejecutar.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.