Por qué esta fase existe
Hay un momento en todo proyecto de IA en que el equipo ha completado el pensamiento. El Problem Statement está validado. El Solution Brief tiene consenso organizacional. Los Agentes están definidos, las Reglas están escritas en el project-context.md y los Skills están documentados en Story Files autocontenidas.
Es en ese momento cuando llega la pregunta que lo cambia todo: ¿y ahora qué?
La respuesta es la Fase 4. Y la respuesta es, deliberadamente, casi decepcionante en su simplicidad: ahora se construye.
La trampa que esta fase desactiva
Construir no significa ejecutar sin más. Construir, en esta metodología, significa algo muy específico: producir una solución que sea reconocible como expresión fiel del Problem Statement y el Solution Brief por las personas que los produjeron.
Esa distinción (entre construir y construir fielmente) es la razón de existir de la Fase 4.
Con la llegada de la IA generativa, el coste percibido de construcción ha caído en picado. Un agente de desarrollo puede generar miles de líneas de código en minutos. Puede tomar decisiones técnicas, resolver dependencias, escribir tests. Esta capacidad es extraordinaria. Y es, exactamente por eso, extraordinariamente peligrosa si el contexto que la guía es impreciso o si el equipo humano deja de supervisar la fidelidad del output.
La Fase 4 existe para que la velocidad de construcción de la IA se convierta en un activo, no en un riesgo. Su función no es gestionar la construcción, es proteger la integridad del contexto durante ella.
La dimensión que lo complica todo
Hay una dimensión de esta fase que no aparecía en las anteriores: en proyectos reales, la construcción no ocurre en serie. Ocurre en paralelo. Múltiples desarrolladores, múltiples agentes de IA, múltiples Story Files en ejecución simultánea.
Imagina un equipo donde tres personas piden a sus agentes de IA que implementen tres módulos distintos al mismo tiempo. Cada agente produce código técnicamente correcto. Pero las convenciones de nomenclatura difieren ligeramente entre módulos. Las interfaces asumen formatos de datos incompatibles. Y nadie detecta las incoherencias hasta que intenta integrar todo.
Esta realidad introduce un conjunto de tensiones específicas que la Fase 4 aborda como tema central: cómo coordinar la construcción distribuida sin sacrificar la velocidad que la hace valiosa.
La construcción es un síntoma, no un objetivo. Construir es la consecuencia natural de haber pensado bien. No es un logro en sí mismo. Un equipo que celebra haber construido rápido sin validar el problema está celebrando en la dirección equivocada.
¿Si la Fase 4 es difícil, qué falló?
Si un equipo llega a esta fase y la construcción se siente caótica, impredecible o llena de decisiones que no estaban previstas, el problema no está en la Fase 4. Está en las fases anteriores.
Un Context Document preciso convierte la construcción en un proceso predecible. La dificultad no es señal de complejidad técnica, es señal de Context Debt acumulada en las Fases 1-3.