Cómo funciona Codex: un harness ligero en lugar de un agente pesado
CodexИИ-агентыархитектура ПО
Codex se apoya en una capa ligera
Lo más interesante es que Codex no está concebido como un agente monolítico, sino como un modelo acompañado por un harness relativamente ligero. En «Building Codex with Tibo Sottiaux», publicado por Pragmatic Engineer, se destacan un Codex CLI abierto en Rust, el soporte para modelos de distintos proveedores y una capa encargada de la seguridad, la fiabilidad y la eficiencia.
En el momento de la publicación, el CLI era abierto y el producto no dependía de un único proveedor de modelos. La elección de Rust parece una apuesta por el rendimiento, la portabilidad y un comportamiento predecible en una herramienta local. El código abierto también reduce la desconfianza hacia un agente que puede acceder al repositorio y ejecutar comandos.
La idea más potente del artículo no es el lenguaje de implementación. El harness evoluciona con los modelos y se vuelve más fino cuando estos mejoran al planificar, elegir herramientas y mantener el foco en la tarea. Los flujos de agente codificados de forma rígida pasan rápidamente de ser una red de seguridad a convertirse en un techo para un modelo más capaz.
Sin embargo, ligero no significa sencillo. Hay que comprimir el contexto sin perder el estado de trabajo y normalizar el comportamiento de distintos modelos dentro de un ciclo común. Añadir una interfaz conversacional complica aún más el panorama: la ejecución de código, el diálogo y el trabajo autónomo del agente deben coexistir sin conflictos.
Según el artículo, el equipo utiliza Codex para mucho más que generar fragmentos de código. Entre sus usos están la revisión, el mantenimiento y la re-arquitectura. Es una señal importante: el producto se diseña en torno a todo el proceso de ingeniería, no solo a una demostración llamativa de autocompletado.
Qué cambia para la arquitectura de agentes
La conclusión práctica es que los frameworks pesados para agentes empiezan a ceder terreno ante un harness compacto y resistente. Cuanto más capaz es el modelo, más caros resultan los niveles innecesarios de planificación, enrutamiento y roles definidos de antemano.
- La lógica se desplaza al modelo. El harness conserva el control de las herramientas, la seguridad y la recuperación ante fallos, pero no intenta dictar cada paso.
- El enfoque multimodelo exige disciplina. La libertad de elegir proveedor añade complejidad de integración: una interfaz común no implica un comportamiento idéntico.
- El contexto pasa a ser parte de la arquitectura. La calidad del agente depende no solo del modelo, sino también del estado que sobrevive a cada ciclo.
No es una receta universal, sino un cambio útil de prioridades: menos magia en la orquestación y más atención a los límites de acceso, al estado y a los fallos. La frontera entre un harness útil y una supervisión innecesaria del modelo es ahora el principal riesgo arquitectónico.