Esfuerzo
El esfuerzo del Context Phase depende de la complejidad de la solución definida en la Fase 2. La relación es proporcional: soluciones más complejas requieren más Agentes, más Reglas y más Skills, y por tanto más profundidad en el diseño, la validación y la iteración.
Esfuerzo por complejidad
| Escenario | Actividades requeridas | Profundidad |
|---|---|---|
| Solución acotada (Q1-2) | Reglas base + 4-5 Agentes + PRD + Architecture Document + 10-20 Skills. 1-2 ciclos de validación. | Las Reglas cubren decisiones obvias. La cadena de Agentes es estándar. Los Skills son directos y autocontenidos. |
| Solución media (Q2-3) | Reglas completas + Agentes calibrados + 20-50 Skills. Múltiples validaciones. QA activo en cada eslabón de la cadena. | Las Reglas requieren calibración por niveles. Los Agentes necesitan límites cuidadosamente definidos. Cada Skill requiere verificación de autocontención. |
| Solución compleja (Q3-4) | Reglas extensas + Agentes especializados + 50+ Skills. Validación iterada con stakeholders. QA en cada eslabón. | Las Reglas cubren integración entre subsistemas. Los Agentes tienen protocolos ante gaps complejos. Los Skills incluyen dependencias cruzadas que requieren secuenciación rigurosa. |
La referencia a cuadrantes (Q1-Q4) corresponde a la evaluación de complejidad del Solution Brief de la Fase 2: Q1 es la más simple (baja complejidad técnica + baja organizacional), Q4 es la más compleja.
La proporción que importa
Si el esfuerzo invertido en Context Phase supera al esfuerzo de construcción, estás sobre-especificando. Las Reglas son demasiado detalladas, los Skills demasiado prescriptivos y los Agentes no tienen espacio para usar criterio.
Si el esfuerzo es inferior a un tercio del esfuerzo de construcción, hay Reglas implícitas y Skills incompletos. Los Agentes rellenarán gaps con invención, produciendo outputs seguros, plausibles y erróneos.
La proporción óptima es que el esfuerzo de Context Phase represente entre un tercio y la mitad del esfuerzo total de construcción. Un sistema de contexto riguroso hace que la construcción sea predecible y fluida.
Distribución del esfuerzo
Entender cómo se distribuye el esfuerzo entre las actividades de la Fase 3 ayuda a planificar y detectar desequilibrios. El error más común es dedicar la mayor parte del esfuerzo a la generación de documentos e insuficiente a la validación.
La proporción óptima: el Context Phase debería representar entre un tercio y la mitad del esfuerzo total de construcción. Un sistema de contexto riguroso hace que la construcción sea predecible y fluida. Menos de un tercio significa Reglas implícitas y Skills incompletos. Más del mismo equivale a sobre-especificación.
| Actividad | Proporción del esfuerzo | Qué determina la profundidad |
|---|---|---|
| Establecer Reglas | 15-20% | Número de decisiones globales en el Solution Brief. Más restricciones implican más Reglas por hacer explícitas. |
| Diseñar Cadena de Agentes | 10-15% | Número de roles especializados necesarios. La mayoría de proyectos usan la cadena estándar de 5 Agentes. |
| Generar PRD | 15-25% | Número de casos de uso y complejidad del Solution Brief. Más casos de uso implican un PRD más extenso. |
| Generar Architecture | 15-25% | Número de decisiones técnicas. Más integraciones y más componentes de IA implican más ADRs. |
| Descomponer en Skills | 20-25% | Número de Skills. Un Skill bien especificado requiere definir objetivo, contexto específico, criterios de aceptación, dependencias y restricciones. |
| Validar a través de Outputs | 10-20% | Número de ciclos de validación. La primera pasada rara vez tiene éxito. Presupuestar 2-3 iteraciones. |
Señales de esfuerzo insuficiente
- Los Agentes hacen preguntas frecuentes durante la ejecución de Skills: los Skills no contienen suficiente contexto.
- Los outputs son inconsistentes entre Agentes: las Reglas no cubren suficiente terreno.
- El QA Agent señala muchos problemas por Skill: el sistema de contexto tiene gaps sistemáticos.
- Los stakeholders rechazan outputs como "no es lo que discutimos": la cadena de trazabilidad tiene roturas.
- El equipo descubre decisiones no documentadas durante la construcción: hay Reglas implícitas.
Señales de esfuerzo excesivo
- El project-context.md supera 10 páginas: probablemente estás especificando decisiones que deberían delegarse (Nivel 1-2).
- Los Skills incluyen pseudocódigo o detalles paso a paso de implementación: estás haciendo el trabajo del Agente en vez de definir qué se necesita hacer.
- Los ciclos de validación producen outputs "perfectos" en la primera pasada: si nada necesita ajuste, el sistema de contexto probablemente está sobre-especificado.
- Los Agentes producen output rígido y mecánico: el anti-patrón Over-Context.
- El equipo debate decisiones de Nivel 1-2 durante horas: las decisiones de delegación no deberían consumir esfuerzo significativo.
Composición del equipo durante la Fase 3
| Rol | Dedicación | Qué hace |
|---|---|---|
| Context Engineer | Dedicación completa (líder) | Diseña Reglas, Agentes, Skills. Ejecuta ciclos de validación. Es dueño del Decision Log. |
| Tech Lead | Dedicación alta | Valida decisiones de arquitectura. Revisa el output del Architect Agent. Asegura viabilidad técnica. |
| Product Lead | Dedicación parcial | Valida el PRD. Participa en validación de outputs. Asegura fidelidad al Solution Brief. |
| Representantes de stakeholders | Bajo demanda | Participan en validación de outputs (Paso 5). Su reconocimiento es el criterio del Gate Review. |
El Context Engineer es el rol con dedicación completa. Los demás contribuyen en momentos específicos. La participación externa más crítica es la validación de stakeholders en el Paso 5, que es lo que determina si el Gate Review se aprueba.
La Fase 1 (Problem Phase) requiere un esfuerzo centrado en investigación: entrevistas, síntesis y validación. La Fase 2 (Solution Phase) requiere esfuerzo de alineamiento: iteraciones con stakeholders hasta alcanzar consenso real. La Fase 3 (Context Phase) requiere esfuerzo de diseño de sistemas: Reglas, Agentes y Skills que traduzcan fielmente el Problem Statement y el Solution Brief. Las tres fases de descubrimiento y diseño juntas concentran la mayor parte del esfuerzo intelectual del proyecto, y esto es por diseño. Cuanto más esfuerzo se invierte en entender y estructurar, menos retrabajo se produce durante la construcción.