Un devops diseña un arnés local para atar en corto a los agentes de código
El diseño fija el entorno con mise, verifica con scripts binarios y calcula un manifiesto SHA-256 de los tests para impedir que el agente se apruebe a sí mismo.
Un ingeniero que firma como Brilliant_Willow1311 ha publicado en un foro de devops el diseño de un arnés de línea de comandos para meter agentes de código en su equipo sin que se le vaya de las manos. Parte de tres restricciones nada negociables: un techo de tokens por desarrollador y mes, un equipo hostil a los diffs generados sin verificar y un gobierno humano estricto, con dos aprobaciones por merge request, commits atómicos que inspecciona una persona y cero generación automática de PRs. De momento es un diseño y una ronda de preguntas: no hay repositorio ni demo pública.
El stack sobre el que trabaja no ayuda: repositorios distribuidos, backend Java y código de despliegue Ansible compartido sobre infraestructura on-premise. Ahí el agente se topa con tres fallos que el autor describe con precisión. El primero es la validación circular: el modelo implementa una suposición de negocio equivocada y, acto seguido, genera un test cargado de mocks que confirma esa misma suposición. La suite se pone verde y todo el mundo respira tranquilo. El segundo es la pérdida de fricción: sin compilador ni linter que se quejen en cada paso, es fácil aceptar un diff limpio y bien escrito que viola invariantes de dominio que nadie ha documentado. El tercero es la podredumbre de contratos entre repos: un parche local en el servicio A compila, pero rompe un consumidor de Kafka o una expectativa de la librería compartida de Ansible.
Anillos deterministas
La respuesta del autor es no dejar que el modelo sea su propio juez. El arnés envuelve git, mise y opencode y hace de supervisor externo. mise fija las versiones de los SDK de Java, los linters de Ansible, las utilidades de Kafka y las variables de autenticación, y todas las órdenes del agente pasan por mise exec para que se ejecuten contra los mismos binarios. La verificación no recurre a un LLM que opine: son scripts Python versionados, cada uno comprobando un único invariante y con contrato binario, cero o uno, sin gastar tokens en evaluar.
El control anti-trampas es la parte interesante. Antes de arrancar, el arnés calcula un manifiesto SHA-256 de los directorios de test; al terminar, lo recalcula y revierte cualquier cambio en un fichero de test que no se haya autorizado con un flag explícito. También intercepta los diffs y aborta si el agente toca fuera del alcance declarado: descriptores de build como pom.xml o build.gradle, pipelines de CI o ficheros de infraestructura compartida. Para el presupuesto de tokens poda la salida con RTK (rust token killer) como plugin de opencode, y si el agente no consigue pasar mise run test en tres intentos, el bucle se corta.
Al hilo le quedan tres preguntas abiertas. Si un modelo ajusta el rumbo con solo códigos de salida y fragmentos cortos, sin explicaciones en lenguaje natural. Cómo validar en local la compatibilidad con consumidores de otros repos sin disparar builds de integración lentos. Y si a un equipo quemado por el hype le convence más el relato de la seguridad determinista que el de la velocidad del desarrollador.
Lo que hace útil el hilo no es el arnés concreto, sino el enfoque: en lugar de pedirle al modelo que se porte bien, se le pone delante un entorno donde puede fallar de forma medible. El autor todavía pide casos límite y puntos ciegos, así que el diseño puede moverse; lo que ya está claro es dónde pone él la frontera entre lo que decide una máquina y lo que decide una persona.
