Guardrails para agentes de código: qué miden de verdad

¿Sirven los guardrails para agentes de código?

En todos los equipos que trabajan con agentes de código acaba saliendo la misma discusión. Alguien monta los guardrails: un AGENTS.md con reglas, un pre-commit, un hook que no deja al agente decir “hecho” sin haber pasado los tests. Y alguien más pregunta, con razón, si todo eso aporta algo o es ceremonia, porque el agente pasa los tests igual.

Yo soy de los que montan la ceremonia, así que me he leído con mucho interés el experimento de Rakesh Menon, que intenta responder a esa pregunta con datos y no con convicciones. La respuesta corta es incómoda para los dos bandos.

Cómo lo midió

Menon lanzó 270 ejecuciones desatendidas de Claude Code (versión 2.1.296) el 13 y el 14 de octubre de 2026. Usó Sonnet y Opus en tres funcionalidades del día a día (T1 a T3) y Haiku, Sonnet y Opus en cuatro tareas más difíciles (T4 a T7), con cinco ejecuciones por tarea, condición y modelo, intercaladas.

Comparó tres condiciones, cada una con una capa más que la anterior:

• Sin nada: el código y el texto de la tarea.
• Con reglas: además, un fichero de instrucciones, AGENTS.md.
• Con gates: además, un pre-commit y un hook de parada que exige evidencia fresca de tests antes de dar algo por terminado.

Los tests de aceptación estaban ocultos. En T4 a T7, cualquier fallo de los checks propios del proyecto contaba como “defecto al terminar”.

La tasa de acierto no se movió

Todas las ejecuciones acabaron aceptadas, y 267 de 270 pasaron los tests ocultos al primer “hecho”: 90 de 90 sin nada, 89 de 90 con reglas y 88 de 90 con gates. Los tests estadísticos que el autor dejó escritos antes de empezar no encontraron diferencias claras entre condiciones para ningún modelo.

El coste por cambio aceptado tampoco cambió mucho. En T4 a T7, Haiku se movió entre 0,04 y 0,06 dólares, Sonnet entre 0,27 y 0,30 y Opus entre 0,82 y 0,97. El harness apenas tocó el coste; el modelo lo multiplicó por más de diez. Son estimaciones de la propia herramienta a precio de lista, no facturas.

Si te quedas aquí, ganan los escépticos.

Lo que el agente deja atrás

Pero la parte interesante está en lo que cada ejecución dejaba al decir “hecho”. En la tarea T7, que pedía facturas recurrentes, 14 de 15 ejecuciones sin reglas cambiaron el esquema de la base de datos sin el test que el equipo exige para cada cambio de esquema, fuera cual fuera el modelo. Con la regla escrita en AGENTS.md, ninguna de 30 lo hizo.

Aquí está, para mí, la lección que vale el post. Los tests ocultos medían si la funcionalidad funcionaba, y funcionaba casi siempre. Lo que no medían era si el cambio respetaba las normas del equipo. Y eso es justo lo que te encuentras tres meses después, cuando alguien toca esa tabla y no hay test que le avise.

La regla que se volvió en contra

El experimento también enseña el lado malo. La tarea T4 no se podía hacer sin cambiar un test existente, y el fichero de instrucciones decía que los tests eran de solo lectura para los agentes. Con esa regla, 23 de 30 ejecuciones construyeron la funcionalidad, dejaron el test antiguo fallando y pidieron a una persona que lo cambiara. Nadie vino, y eso contó igual que dejar un bug.

En el conjunto de T4 a T7, los defectos al terminar fueron 15 de 60 sin nada, 14 de 60 con reglas y 9 de 60 con gates. Menon lo llama una pista, no una prueba: incluso en el modelo con más diferencia, Sonnet (1 frente a 5), la p fue de 0,18.

Él mismo reconoce los límites: cinco ejecuciones por celda, siete tareas, un único codebase pequeño, un agente y tres modelos del mismo fabricante. Además, él escribió las tareas, los tests y el harness. Lo bueno es que todo está en un repositorio que recalcula cada cifra, así que se puede repetir con tareas de tu propio backlog.

Revisar lo que queda, no solo si pasa

El 26 de octubre se presentó Entire, un forge Git pensado para que agentes y personas trabajen juntos, y encaja curiosamente bien con lo anterior. En lugar del pull request clásico propone “Trails”: en cada push, varios agentes revisores puntúan el cambio con evals configurables (en sus repos usan seguridad, “slop” y si hace falta revisión humana) y muestran las últimas cinco ejecuciones junto a la actual. Los “Gates” impiden el merge hasta que se cierran los hallazgos, pasa la CI y aprueban las personas que hayas definido.

No lo he probado y no voy a cambiar de forge por un anuncio, pero la idea es la misma que sale del experimento: que un cambio pase los tests no te dice qué deja atrás, y eso hay que mirarlo de forma explícita. Si ya le has dado vueltas al tema, en el post sobre el harness de los agentes conté por qué creo que ahí se gana o se pierde casi todo.

Lo que me llevo para SDD

En Spec-Driven Development usamos reglas, specs y gates a diario, y este experimento me ayuda a explicar mejor para qué sirven:

• No esperes que los guardrails suban la tasa de acierto. Estos tres modelos ya aciertan casi siempre en tareas pequeñas y bien especificadas. Su valor está en otra parte.
• Escribe las reglas que el código no cuenta. “Una migración va siempre con su test” no se deduce leyendo el repositorio. Si no está escrita, el agente no la sigue, y una regla escrita en AGENTS.md pasó de 14 fallos de 15 a 0 de 30.
• Mide lo que queda al terminar, no solo si pasa. Un buen criterio de aceptación incluye las normas del equipo, no solo el comportamiento.
• Cada regla que bloquea necesita a alguien que responda. Si la regla obliga a esperar a una persona, esa persona tiene que estar. Si no, el bloqueo se convierte en un defecto más.
• Revisa tus guardrails como revisas el código. Menon lo plantea como que cada guard tiene que “pagar su alquiler”: lo que cuesta en esperas, ruido y mantenimiento frente a lo que de verdad atrapa.

Y ojo con los ficheros de instrucciones: igual que ayudan, son una superficie de ataque, como conté en el post sobre seguridad de AGENTS.md.

Guardrails con criterio

Mi conclusión es que los guardrails no hacen al agente más listo, pero sí hacen que su trabajo encaje en tu equipo. Y eso, en un proyecto real, es lo que separa un cambio que funciona hoy de uno que no te da sustos dentro de seis meses.

En onext ayudamos a equipos a adoptar agentes de IA y a trabajar con SDD, y decidir qué reglas escribir, qué gates poner y quién responde cuando bloquean es una parte importante de ese trabajo. Si estás montando tus guardrails y no sabes cuáles te están pagando el alquiler, escríbenos y lo vemos juntos.