Si abrís Claude Code y te ponés a construir directo, ya la regaste. Hay 3 prácticas que separan apps que salen bien de las que salen rotas: separar plática de construcción, blueprint estructurado y delegación entre Claudes. Con principios para principiantes y la teoría detrás.
Abrís Claude Code. Le decís "armame X". Claude empieza a codear en segundos.
Te sentís imparable. En 3 horas tenés algo que funciona. En 3 días algo se rompe y no sabés por qué. En 3 semanas el proyecto es deuda técnica que cuesta más mantener que rehacer.
Esto pasa porque te brincaste 3 prácticas críticas que sí marcan la diferencia:
Cuando le pedís a Claude "armame el dashboard", está mezclando 4 cosas al mismo tiempo:
Si Claude hace las 4 simultáneamente, se pisa. La calidad cae.
Separá la fase de plática de la fase de construcción:
[Fase de plática — Claude #1 o sesión #1]
- Discutís qué construir
- Por qué importa
- A quién le sirve
- Casos edge
- Qué NO incluir
- Stack que tiene sentido
- Riesgos
OUTPUT: blueprint del proyecto
[Fase de construcción — Claude #2 o sesión #2 limpia]
- Recibe el blueprint
- Implementa SIN preguntar el QUÉ (ya está decidido)
- Pide aclaraciones solo del CÓMO técnicoLa diferencia: cuando la fase de construcción arranca, el QUÉ ya no está en debate. Eso libera contexto y permite enfocar en el cómo bien.
Es como construir una casa:
Si el constructor también tiene que decidir dónde van las puertas mientras pone los ladrillos, el resultado es desastre.
Un documento markdown que captura todas las decisiones de la fase de plática. No es un email largo — es estructura formal:
# Blueprint: [Nombre del proyecto]
## 1. Visión (1 párrafo)
Qué construimos y por qué importa.
## 2. Usuario objetivo
Quién es, qué problema tiene hoy, qué resuelve esto.
## 3. User stories (3-5)
Como [X] quiero [Y] para [Z].
## 4. Stack técnico
- Framework: ...
- DB: ...
- Auth: ...
- Hosting: ...
[Cada decisión con razón]
## 5. Modelo de datos
Tablas / colecciones con sus campos.
## 6. Rutas y endpoints
Listado exhaustivo.
## 7. Diseño UX
Flujo principal en 4-6 pasos.
## 8. Out of scope
Qué NO incluye este blueprint (explícito).
## 9. Tests críticos
Qué tiene que pasar para considerar "funciona".
## 10. Riesgos identificados
3-5 con su mitigación.
[... hasta 16 secciones según el caso]Es el artefacto que sobrevive a las sesiones. Tu codebase puede cambiar 10 veces; el blueprint queda como referencia.
Una herramienta como "The Architect" automatiza la generación (te entrevista, llena el template). O lo armás vos a mano con plantilla.
Ver detalle en trifecta perfecta — donde la primera pieza es exactamente este Architect.
El Claude que piensa y el Claude que construye son sesiones distintas.
Sesión 1: ARQUITECTO
- Sos arquitecto de software senior
- Tu única tarea: producir blueprint estructurado
- NO escribís código en esta sesión
[Generás blueprint.md]
Sesión 2: BUILDER
- Sos developer senior
- Input: blueprint.md
- Construí según el blueprint
- Si te falta detalle técnico, preguntás
- Si te falta detalle de producto, NO preguntás (asumís lo del blueprint)[Sesión 1]
> Sos arquitecto. Te explico la idea: [...]
[Discutís hasta tener blueprint]
> Guardá el blueprint en docs/blueprint.md
[/clear][Sesión 2 — contexto fresco]
> Sos developer. Leé docs/blueprint.md y construilo paso a paso.Si tenés Claude + Codex hack:
Cada uno con sus tokens separados.
Hay extremos:
El balance está en plática proporcional a la complejidad:
Si tu plática lleva más que 20% del tiempo total estimado, te estás trabando.
Hablás 2 horas con Claude, no sale blueprint. La plática queda en historial efímero. Cuando la sesión cierra, se perdió todo.
Regla: cada sesión de plática debe terminar con archivo guardado.
"El producto tiene auth, dashboard, API". Demasiado abstracto. Un blueprint útil tiene specificidad: "el dashboard muestra estos 7 KPIs en este orden, con estos filtros".
A veces el Builder "interpreta" el blueprint y se desvía. Forza que vuelva al blueprint:
> Antes de implementar el próximo feature, releé blueprint.md sección 6
para confirmar cómo es. Si vas a desviarte del blueprint, decímelo y
justificá ANTES de codear.Construís el feature, descubrís que algo del blueprint estaba mal. Actualizá el blueprint. Sino el blueprint queda desincronizado del código y deja de servir.
Antes de tu próxima feature, preguntate:
Si mañana otra persona del equipo entra al proyecto, ¿podrá entender qué estamos construyendo SIN preguntarme nada?
Si la respuesta es no → te falta blueprint. Si la respuesta es sí → adelante con la construcción.
Ese test, aplicado consistentemente, marca la diferencia entre proyectos que duran y proyectos que se ahogan en deuda técnica.
Si nunca hiciste esto, arrancá con la versión mínima:
Eso solo, sin herramientas especiales, ya mejora 50% la calidad del output.