La inversión del coste: dónde está el valor real
Existe una ilusión que afecta a todos los equipos que usan IA para construir: la ilusión de que la dificultad está en la construcción. Que el trabajo duro ocurre cuando el equipo técnico se sienta a implementar. Que las fases anteriores son preparación, y la construcción es el acto principal.
Esta ilusión es exactamente eso: una ilusión.
La distribución real del valor
En un proyecto bien ejecutado según esta metodología, la distribución real del esfuerzo y del valor generado es la siguiente:
| Fase | % del esfuerzo total | % del valor generado |
|---|---|---|
| Fase 1 — Problem Phase | 20-25% | 40% |
| Fase 2 — Solution Phase | 20-25% | 30% |
| Fase 3 — Context Phase | 25-30% | 20% |
| Fase 4 — AI Build Phase | 15-20% | 10% |
| Fase 5 — Market Phase | Continuo | Acumulativo |
Esta tabla incomoda a casi todo el mundo que la ve por primera vez. ¿Cómo puede ser que la fase de construcción aporte solo el 10% del valor?
La respuesta: el valor ya estaba capturado en las fases anteriores. El Problem Statement preciso, el Solution Brief con consenso organizacional, el sistema de Agentes, Reglas y Skills, ese es el valor. La construcción es la forma de materializarlo.
Lo que esto implica para la gestión
Entender esta distribución tiene una consecuencia directa: el equipo no debe optimizar la velocidad de construcción. Debe optimizar la fidelidad de lo construido al contexto definido.
Imagina un equipo que usa Claude para generar una API de predicción de inventario. El agente produce el código en 20 minutos. Es funcional, está testeado, se despliega. Pero las decisiones de naming convention no siguen las Reglas del project-context.md. Los endpoints no coinciden con los contratos definidos en el Architecture Document. Y la lógica de negocio incluye tres optimizaciones que "tenían sentido" pero que nadie había pedido.
La velocidad fue impresionante. La fidelidad fue nula. Y cada optimización no solicitada es ahora Context Debt que alguien tendrá que resolver.
Qué es: El equipo tiene el contexto listo y siente la tentación de construir lo más rápido posible. Los agentes de IA producen código a gran velocidad. La supervisión humana se reduce. Se generan funcionalidades no previstas en el contexto. El resultado parece impresionante.
Cómo detectarlo: El Build Validation Report no puede trazarse al Problem Statement. Las funcionalidades construidas no aparecen en los Story Files. Hay decisiones técnicas que "tenían sentido en ese momento".
Cómo prevenirlo: La velocidad de construcción no es un KPI. La fidelidad al contexto es el único KPI de esta fase. La construcción paralela bien gestionada acelera sin sacrificar fidelidad. La construcción paralela mal gestionada produce Context Debt a escala.
La paradoja de la eficiencia
La paradoja es que un equipo que invierte tiempo en supervisar la fidelidad durante la construcción termina más rápido que uno que construye sin supervisión. ¿Por qué? Porque el retrabajo es el verdadero asesino de la velocidad.
Un agente de IA que genera código durante 3 horas sin supervisión puede producir 10.000 líneas. Si el 20% de esas líneas viola una Regla del project-context.md, el coste de encontrar y corregir esas violaciones es mayor que el coste de supervisar en tiempo real.
La Fase 4 no es la fase de la velocidad. Es la fase de la fidelidad. Y la fidelidad, bien gestionada, produce velocidad como efecto secundario.