Qué es AI Build Phase y qué no es
Lo que ES
La Fase 4 es cinco cosas muy específicas:
Un proceso de materialización del contexto. Todo lo que se construye en esta fase es la expresión física de un sistema de Agentes, Reglas y Skills que ya existe. No es creación, es traducción. Cuando un agente de IA genera código en esta fase, está traduciendo un Skill en implementación, no inventando funcionalidades.
Una actividad de supervisión de fidelidad distribuida. Cuando múltiples personas construyen en paralelo, el trabajo de supervisión no puede concentrarse en una sola persona. Se distribuye según un modelo de gobernanza que esta fase define. Cada nivel de la jerarquía tiene exactamente la visibilidad y capacidad de decisión que su rol justifica.
Un proceso de gestión de gaps con visibilidad compartida. Por bien diseñado que esté el contexto, la construcción revela ambigüedades. En un equipo distribuido, los gaps deben ser visibles para todos, no solo para quien los descubre. Un gap oculto en un track puede invalidar el trabajo de otro track sin que nadie lo sepa.
Un proceso de coordinación activa del Decision Log. Cuando varios desarrolladores operan en paralelo, el Decision Log deja de ser un registro individual y se convierte en el mecanismo de coordinación central del equipo. Cada decisión se clasifica por su impacto: local, cruzado entre tracks, o global.
Un proceso iterativo por Story Files con grafo de dependencias explícito. No se construye todo a la vez, pero tampoco necesariamente en serie. El grafo de dependencias determina qué puede construirse en paralelo y qué debe esperar.
Lo que NO es
No es diseño libre. Las decisiones de diseño se tomaron en la Fase 3. Si durante la construcción emerge una decisión de diseño que no estaba en el contexto, no se toma unilateralmente, ni individualmente ni por consenso del equipo técnico. Se escala.
Imagina que un desarrollador, al implementar un módulo de alertas con IA, decide que sería mejor usar WebSockets en vez del polling especificado en el Architecture Document. Puede tener razón. Pero esa decisión afecta a otros módulos que esperan polling. No es una decisión de construcción, es una decisión de arquitectura que debe resolverse antes de continuar.
No es un proceso de descubrimiento. Si durante la construcción el equipo descubre que el problema está mal definido, no es un problema de construcción. Es un problema de contexto que debe resolverse, potencialmente regresando a una fase anterior.
No es una oportunidad de mejora no solicitada. Los agentes de IA tienden a añadir funcionalidades que parecen útiles. Esto no es un comportamiento aceptable. Todo output no trazable al contexto es Context Debt. En construcción paralela, una funcionalidad no solicitada en un track puede introducir dependencias en otro track sin que nadie lo detecte.
Un agente de IA implementa un endpoint de búsqueda para un sistema de inventario. El Skill pedía búsqueda por nombre. El agente añade búsqueda por código de barras, búsqueda difusa y autocompletado. Las tres funcionalidades son útiles. Ninguna estaba en el Skill. Y la búsqueda difusa requiere una dependencia que entra en conflicto con una Regla del project-context.md. La "mejora" es ahora un problema.
No es la fase más importante. Si la Fase 4 es difícil, algo falló antes. Un Context Document preciso convierte la construcción en un proceso predecible. La dificultad es señal de Context Debt, no de complejidad técnica.