La calidad de un agente de programación suele disminuir no porque el modelo se haya vuelto menos capaz, sino porque el proyecto carece de un sistema operativo claro que regule qué lee el agente, qué hace y cómo se revisan sus cambios. Cuando el trabajo se extiende durante semanas y miles de modificaciones, el agente puede volver a descubrir los mismos archivos, contradecir una decisión anterior, adivinar el comando de prueba o dejar de escribir pruebas si no se le imponen estos pasos.
En la sexta parte de la serie «Operar sistemas LLM en producción», Stack Overflow Blog propone construir una capa organizativa alrededor del modelo que incluya una constitución breve del proyecto, límites de autonomía, contexto multinivel, memoria persistente, un comité de revisión y un hook que se ejecute después de cada modificación. Al ejecutar varios agentes sobre el mismo repositorio, se añaden un mapa de propiedad de los archivos y registros compartidos de solicitudes y decisiones.
El problema está en el arnés operativo, no solo en el modelo
El artículo define el agente como el modelo más las instrucciones, las herramientas, las políticas de contexto, los hooks, el aislamiento, los subagentes y los mecanismos de supervisión. Cita un resultado general de la referencia Terminal-Bench 2.0, en la que LangChain llevó a un agente de fuera de los 30 primeros puestos a los 5 primeros cambiando únicamente el arnés operativo: la puntuación aumentó del 52,8 % al 66,5 %, es decir, 13,7 puntos, manteniendo el mismo modelo.
La conclusión práctica es que unas herramientas incompletas, unas reglas ambiguas o un contexto saturado pueden ser la causa del fallo más susceptible de tratamiento. A diferencia del modelo, el equipo de desarrollo puede modificar esta capa y adaptarla a su repositorio.
Seis elementos para un agente único disciplinado
- Constitución del proyecto: un archivo como CLAUDE.md o AGENTS.md define el ciclo de trabajo: planificación, documentación, implementación, pruebas, revisión y, después, commit. Debe incluir criterios de calidad y límites para el uso de paquetes de proveedores, y mantenerse breve porque se lee en cada sesión.
- Límites de autonomía: se permite al agente realizar operaciones reversibles, como leer, editar, probar y crear commits, mientras que las operaciones de push, despliegue y aplicación de cambios de infraestructura requieren aprobación. Deben verificarse las semánticas de coincidencia de comandos para que reglas amplias, como npm:*, no permitan desplegar accidentalmente.
- Contexto multinivel: el CONTEXT.md raíz incluye el mapa del proyecto y la forma de ejecutarlo y probarlo, mientras que el archivo de cada módulo explica su responsabilidad, sus archivos y sus dependencias. DECISIONS.md registra las decisiones, sus motivos y las alternativas rechazadas. El contexto obsoleto se considera un error que debe corregirse en el propio cambio.
- Memoria persistente: el material propone archivos de memoria separados para cada hecho, un índice breve y un archivo graph.jsonl que vincule módulos y decisiones mediante relaciones como depende de o sustituye.
- Comité de revisión desde múltiples perspectivas: los subagentes revisan el cambio desde los puntos de vista del producto, la ingeniería, la infraestructura, la seguridad y las pruebas. Solo debe bloquearse el cambio ante un impedimento o un problema grave con un nivel de confianza elevado.
- Hook posterior a la modificación: PostToolUse se ejecuta después de cada Edit, Write o MultiEdit, y emite una lista que recuerda actualizar el contexto, la memoria y el registro de decisiones en el propio cambio, en lugar de reescribir los archivos silenciosamente.
Al ejecutar una flota de agentes
Aparece un nuevo problema cuando varios agentes trabajan en el mismo repositorio: modificar los mismos archivos o revertir las decisiones de otros. El artículo no propone depender de conversaciones directas entre ellos, sino de un estado compartido, escrito y auditable, que incluya un mapa de propiedad de las rutas, registros CLAIM y RELEASE, un registro de progreso y una rama independiente para cada tarea con integración humana.
Estas solicitudes no constituyen un bloqueo real: dos agentes pueden leer el mismo estado y reclamar la misma ruta al mismo tiempo. Cuando se necesita un aislamiento efectivo, el artículo recomienda un mecanismo atómico, como una rama de Git con un nombre único o una escritura condicional en un almacén de coordinación.
¿Por qué importa este enfoque?
El cambio real consiste en trasladar el foco de la capacidad del agente para escribir una función a la capacidad del sistema que lo rodea para mantenerlo orientado y sujeto a revisión a lo largo del tiempo. El registro de decisiones cumple una función contractual, no solo documental: las decisiones antiguas no se modifican, sino que se añaden nuevas decisiones que las sustituyen, con una explicación del motivo y de las alternativas rechazadas. Así, el historial del diseño permanece visible y puede vincularse a comprobaciones automáticas, como impedir determinadas importaciones.
Este enfoque sigue siendo una guía organizativa, no una garantía de la corrección de las salidas. El artículo también reconoce que las solicitudes basadas en archivos son consultivas cuando las colisiones son simultáneas, y que la revisión humana sigue siendo el punto de control durante la integración, el push y el despliegue. La conclusión del material es que contener el modelo y construir rastros auditables pueden tener más impacto en la fiabilidad del trabajo prolongado que esperar a un modelo más inteligente.