Patrick Debois, fundador de Tessl y figura histórica del movimiento DevOps, desarrolla en este artículo el concepto de "Context Flywheel" — un volante de inercia contextual que crea una ventaja competitiva acumulativa para los equipos de desarrollo que utilizan agentes de IA.

El artículo se basa en el Context Development Lifecycle (CDLC) introducido en una publicación anterior, un ciclo de cuatro fases: Generate, Evaluate, Distribute, Observe. El CDLC trata el contexto no como documentación estática, sino como un artefacto de ingeniería versionado y probado.

La tesis central es que el valor no reside en un único paso por el ciclo, sino en su repetición. La primera iteración captura convenciones e identifica lagunas. La segunda corrige esas lagunas y revela problemas más sutiles. Hacia la décima iteración, se produce un cambio: los agentes no se limitan a seguir mejor las instrucciones — todo el equipo programa de otra manera, más rápido, con mayor consistencia y menos correcciones.

Debois identifica cuatro retornos de inversión simultáneos en cada ciclo. Primero, la calidad de los agentes mejora en todos los ámbitos. Segundo, el ingeniero senior que codifica su experiencia la clarifica y la profundiza. Tercero, los desarrolladores junior pueden leer las skills y absorber los patrones, restricciones y razonamientos. Cuarto, la organización converge hacia una terminología compartida que trasciende las fronteras entre equipos.

El argumento estratégico central es que el verdadero foso competitivo no reside ni en las herramientas ni en los modelos — que se están commoditizando y convergiendo, respectivamente — sino en el conocimiento del producto acumulado. Una organización que hace funcionar este volante de inercia durante dos años desarrolla una comprensión que los competidores no pueden replicar: casos límite catalogados, necesidades de usuario mapeadas, razonamiento de dominio codificado y accesible para los agentes.

Debois concluye subrayando la necesidad de una propiedad explícita del contexto (context ownership). Sin un responsable designado — ya sea un equipo de DevEx, un equipo de plataforma o context engineers integrados — el contexto se degrada inevitablemente. Esta propiedad se apoya en tres pilares: mantenimiento (revisión de vigencia, resolución de conflictos, retirada de lo obsoleto), habilitación (contribución sencilla vía CLI y evaluaciones en CI) y gobernanza (umbral de calidad mediante evaluaciones, detección de conflictos, políticas de obsolescencia). La analogía histórica es explícita: la industria ya aprendió esta lección con la documentación, la infraestructura y la seguridad.