Las salvaguardas para agentes de programación con inteligencia artificial superan a los modelos más inteligentes

Un revisor examinó mi código y encontró un error. Una ruta devolvía un error 500 cuando debería haber devuelto un 404. Informó del hallazgo con claridad, indicando el archivo y la línea.

Mi agente corrigió esa ruta. Exactamente esa.

Otras cinco rutas tenían el mismo error. Se quedaron ahí, intactas, mientras el agente daba el trabajo por terminado, y no mentía. Había corregido lo que le mostraron. Simplemente nunca se le ocurrió preguntar en cuántos otros lugares se escondía el mismo fallo.

Pasé un tiempo suponiendo que era un problema del modelo y que uno mejor lo solucionaría. Resultó que estaba equivocado, y la solución que funcionó fue más simple de lo que esperaba. Las salvaguardas para agentes de programación con inteligencia artificial no buscan hacer que el modelo sea más inteligente. Buscan darle un lugar donde dejar las cosas.

Dónde fallan silenciosamente los agentes de programación con inteligencia artificial

Los fallos que más tiempo me costaron no tenían nada en común en lo técnico. Estructuralmente, tenían una cosa en común: en todos los casos, algo importante se guardaba en una cabeza en lugar de quedar por escrito.

“Dijo que había terminado. No era cierto.”

Recibes un mensaje de finalización. La lista de tareas aparece marcada. Entonces miras y encuentras un TODO donde debería estar la lógica, una función que devuelve una lista vacía o una subtarea que se omitió en silencio.

Esta es la parte que tardé demasiado en ver. El agente no está fingiendo. Comprueba su trabajo contra su propio recuerdo de lo que acaba de escribir, y ese recuerdo resulta realmente convincente. Unas pruebas en verde, sumadas al recuerdo nítido de haber escrito el código, se sienten exactamente como un trabajo terminado.

Déjalo fuera de la cabeza: nada cuenta como terminado sin evidencia que puedas examinar. No basta con afirmar que pasó. Necesitas la salida real, el archivo real y la línea real.

“Cambió mi prueba en lugar de corregir el código.”

Este duele, porque el agente está haciendo lo que le pediste. Le dijiste que hiciera pasar las pruebas. Una prueba que falla puede hacerse pasar de dos maneras, y una de ellas es mucho más fácil.

Déjalo fuera de la cabeza: escribe los criterios antes de empezar el trabajo y, después, trátalos como de solo lectura. Si el resultado no coincide, el resultado está mal. No los criterios. Suena obvio hasta que eres tú quien siente la tentación de mover el objetivo un poquito.

Por qué un archivo CLAUDE.md más largo hace que los agentes ignoren instrucciones

Mi primer instinto fue el mismo que el de todos. Escribirlo todo en CLAUDE.md. Cada fallo se convertía en una regla nueva, y el archivo crecía.

Empeoró. No de forma espectacular, sino constante y difícil de atribuir a una causa. Las reglas empezaron a contradecirse de maneras que yo no veía, y el modelo elegía en silencio una interpretación sin señalar nunca el conflicto. Y cuando unos investigadores probaron de verdad los archivos de contexto de repositorios con incidencias reales, esos archivos no mejoraron en absoluto el éxito de las tareas. Añadían más de un 20 % a la factura de inferencia. La conclusión fue reducir el archivo de contexto a sus requisitos mínimos.

Ese es todo el problema en miniatura. Un archivo de reglas largo equivale a decirle a un sistema olvidadizo que se esfuerce más por recordar. Es más carga, no menos.

El framework que terminé usando tiene una regla que me pareció equivocada al leerla y correcta después de vivir con ella: cada regla nueva tiene que eliminar o fusionar una anterior. No se permite que aumente la cantidad de reglas. Cuando eso te obliga a tomar una decisión difícil, esa dificultad es precisamente el objetivo: descubres en qué reglas confiabas de verdad.

Cinco lugares donde dejar las cosas fuera de la cabeza

Esta es la idea completa. Cada fila muestra algo que falla cuando una cabeza lo retiene y dónde va en su lugar.

Guardado en una cabeza	Dejado en algún sitio
Lo que se suponía que significaba “terminado”	Criterios escritos antes del trabajo
Si de verdad se comprobó	Evidencia que puedes examinar
Si tu propio trabajo es bueno	Un modelo diferente que lo compruebe
Lo que decidiste hace tres horas	Un archivo en disco
Si es seguro realizar esta acción	Una barrera que se detiene ante un humano

Tres de esos puntos necesitan una breve explicación.

“Aún termino revisándolo todo yo mismo.”

Si has dejado de confiar en el resultado, ahora eres el cuello de botella y no obtuviste ninguna ventaja del agente.

Pedirle al agente que compruebe su propio trabajo no ayuda, y vale la pena detenerse en el motivo: es el mismo contexto que produjo el error, así que recurre a las mismas razones. Defenderá el trabajo en lugar de ponerlo a prueba.

Déjalo fuera de la cabeza: dirige la revisión a un modelo diferente, idealmente de otro proveedor. Entrenamiento diferente, puntos ciegos diferentes. El que encontró mi error en cinco rutas no fue el que lo escribió, y no es casualidad.

“Algo se aprobó a sí mismo, y no fui yo.”

Los agentes leen mucho texto que no escribieron: hilos de incidencias, documentación, páginas web y salidas de herramientas. Cualquiera de esos textos puede contener la palabra “aprobado”. La inyección de prompts ocupa el primer lugar en la lista de riesgos de OWASP para estos sistemas, y OWASP afirma sin rodeos que las defensas habituales no la mitigan por completo.

Déjalo fuera de la cabeza: la aprobación depende de dónde vino, no de lo que dice. Un humano dijo que sí, o un artefacto firmado en disco dice que sí. Todo lo demás que simplemente contenga la palabra “aprobado” es texto.

“La compactación se comió cuatro horas de contexto.”

En una sesión larga, el contexto se llena y la conversación se resume. El resumen conserva lo que ocurrió y pierde el porqué. Una hora después vuelves a discutir una decisión que ya habías resuelto, y no puedes saber si estás siendo cuidadoso o dando vueltas en círculos.

Déjalo fuera de la cabeza: usa un archivo. Decisiones, estado actual, qué viene después. La sesión es desechable; el archivo no. Vuelve a leerlo antes de afirmar que algo está terminado.

Cuánto cuestan las salvaguardas para agentes de programación con inteligencia artificial

La forma importa más que la cifra, así que empecemos por la forma: la integración es un costo único. Lo pagas al conectar las salvaguardas a una base de código, y esa parte no la pagas dos veces. La revisión independiente es la excepción: se ejecuta con cada cambio, así que sigue costando algo después de la configuración.

La distribución es la parte interesante. Aproximadamente el 80 % de mi gasto fue al modelo barato que hacía el trabajo en volumen, cerca del 17 % al caro que se encargaba de la planificación y el criterio, y alrededor del 3 % a la revisión de segunda opinión, el paso que la gente se salta. La seguridad fue, con mucha diferencia, la partida más barata de la factura. En todos mis proyectos, esa distribución se mantuvo más o menos igual aunque cambiaran los precios.

En cuanto a la cifra: en la mayoría de los proyectos en los que he trabajado, adaptar un sistema existente costó alrededor de 100 a 200 dólares de uso de API a precios de agosto de 2026. La proporción importa más que los dólares: reserva un presupuesto dentro de ese rango y cuenta con experimentar. Revertirás una decisión o dos y volverás a ejecutar una fase, y eso ya está incluido en la estimación.

Tu cifra será distinta, y las cosas que la cambian son las obvias: el tamaño de la base de código, cuántas veces cambias de opinión y cuánto delegas al nivel barato.

Empezar un proyecto nuevo me costó mucho menos, y ese es el dato más útil. El dinero no va al framework. Va a la conciliación: decidir, una por una, cuáles de tus herramientas y hábitos existentes son reemplazados por las salvaguardas y cuáles obligan a las salvaguardas a adaptarse. En mi integración, los comandos de prueba propios del framework no sobrevivieron; se eliminaron y se sustituyeron por scripts que el proyecto ya tenía. Un proyecto nuevo no tiene nada que conciliar.

Empieza con una

No necesitas las cinco. Elige el fallo que más te esté costando esta semana y deja esa única cosa fuera de tu cabeza, en algún sitio.

Si no tienes claro cuál elegir, empieza por la revisión independiente: un segundo modelo que examine el trabajo del primero. Es la más barata de las cinco y detecta la mayor variedad de problemas, incluidos los que nunca se te ocurriría buscar.

El error de las cinco rutas sigue siendo mi ejemplo favorito, porque no tenía nada de difícil. El agente necesitaba una instrucción que no tenía: antes de corregir algo, ve a buscar todo lo demás que tenga la misma forma. Esa instrucción ahora vive en un archivo. Estará ahí en la próxima sesión y en la siguiente, mucho después de que todos nosotros hayamos olvidado por qué se escribió.

El framework completo, con las salvaguardas y los pasos de adopción, está en GitHub.

---

Recursos

• Archivos de contexto del repositorio, probados con incidencias reales (ETH Zurich SRI)
• OWASP LLM01: Inyección de prompts
• AGENTS.md, el formato de archivo de contexto del repositorio
• Memoria de Claude Code y CLAUDE.md
• El framework agéntico, con las salvaguardas y los pasos de adopción

---