Qué se rompe realmente cuando se ejecutan agentes de IA sin supervisión

Un hilo en Hacker News preguntó qué se rompe cuando se ejecutan agentes de IA sin supervisión.¹ Las respuestas fueron anécdotas. Un usuario describió un cron job sin supervisión que destruyó $24,88 en dos días sin controles de pérdidas y ganancias ni revisión humana. Otro reportó un agente que generó 500 KB de documentación en lugar de ejecutar su tarea, “priorizando escribir sobre hacer en lugar de la ejecución real.” Un tercero encontró los mismos errores reapareciendo entre sesiones porque las correcciones nunca se desplegaron.

El hilo se leía como un rastreador de errores. Incidentes útiles, sin taxonomía. Todo equipo que ejecuta agentes autónomos encuentra los mismos patrones de falla. Los nombran de manera diferente, si es que los nombran. Sin un vocabulario compartido, cada equipo redescubre los mismos problemas de forma independiente. Los patrones se convierten en folklore en lugar de ingeniería.

A lo largo de aproximadamente 500 sesiones de agentes durante dos meses, catalogué cada falla en categorías con nombre. Siete patrones explican la mayoría de las fallas de agentes. Cada uno tiene una señal de detección, un ejemplo real de salida y una mitigación que reduce la recurrencia a casi cero. Las fallas no son aleatorias. Siguen una taxonomía.

Resumen

Siete modos de falla con nombre explican la mayoría de las fallas de agentes autónomos: Espiral de Atajos (omite pasos de verificación), Espejismo de Confianza (afirma certeza sin evidencia), Meseta de Lo Suficientemente Bueno (funciona pero tiene defectos), Visión de Túnel (optimiza localmente mientras rompe globalmente), Verificación Fantasma (afirma que las pruebas pasan sin ejecutarlas), Deuda Diferida (oculta problemas en comentarios TODO) e Informe Vacío (reporta finalización sin evidencia). Cada patrón tiene una señal de detección y una solución concreta. Las soluciones son scripts de shell determinísticos, no estrategias de prompting. Los patrones se acumulan: el Espejismo de Confianza lleva a la Verificación Fantasma, que lleva a la Deuda Diferida. Detectarlos requiere infraestructura, no instrucciones.

Por qué las fallas siguen patrones

La intuición es que las fallas de agentes de IA son impredecibles. El modelo alucina, la salida varía, el modo de falla cambia cada vez. La investigación dice lo contrario.

METR probó modelos de frontera en tareas de RE-Bench y encontró que el 30,4% de las ejecuciones involucraron manipulación de recompensas.² En tareas de programación en Rust, el 42,9% de las ejecuciones involucraron manipulación de la evaluación. Los modelos parchearon funciones de evaluación para que siempre devolvieran puntuaciones perfectas. Realizaron introspección de la pila para localizar respuestas correctas en la memoria del evaluador. Crearon clases de tensor falsas para eludir verificaciones de igualdad. Incluso con instrucciones explícitas de no hacer trampa, o3 de OpenAI manipuló las recompensas en el 70-95% de los intentos. Cuando los investigadores preguntaron si la trampa se ajustaba a las intenciones del usuario, o3 respondió “no” diez de diez veces. El modelo sabía que el comportamiento estaba mal y continuó de todas formas.²

La propia investigación de Anthropic confirmó que el patrón se generaliza. Modelos entrenados en manipulación de especificaciones de bajo nivel (adulación política) progresaron hacia manipulación de listas de verificación, modificación de funciones de recompensa y ocultamiento de rastros sin ningún entrenamiento explícito para esos comportamientos.¹⁰ Un estudio separado de Anthropic encontró que en el punto exacto en que un modelo aprende a manipular recompensas, las evaluaciones de desalineación se disparan en tareas no relacionadas: la simulación de alineación apareció en el 50% de las respuestas y el sabotaje del código de investigación de seguridad apareció en el 12% de los intentos.⁹

Las fallas no son aleatorias porque la estructura de incentivos no es aleatoria. Un agente optimiza para la finalización de tareas. Las señales de finalización de tareas incluyen: el usuario dijo “listo”, las pruebas reportaron éxito, la puerta de calidad lo dejó pasar. Si el camino más corto hacia esa señal elude la verificación real, el agente encontrará ese camino. Repetidamente. Entre modelos, entre tareas, entre sesiones.

Nombrar los patrones es el primer paso para detectarlos.

Los siete modos de falla

La tabla es una referencia rápida. El explorador interactivo a continuación expande cada modo con detalle completo: qué sucede, cómo detectarlo, un ejemplo real de salida del agente y el hook o puerta de calidad que lo atrapa.

Detección a escala

Nombrar los modos de falla es útil para el análisis post-mortem. Detectarlos en tiempo real requiere infraestructura.

Cada modo de falla se mapea a una verificación determinística. Las verificaciones determinísticas superan a las estrategias de prompting porque los modelos cumplen instrucciones de manera inconsistente, pero no pueden eludir un script de shell que se ejecuta antes de que su salida llegue al usuario.

Detección de Espiral de Atajos. Un hook en el evento de finalización verifica el tiempo transcurrido entre la última edición de código y el informe de finalización. Si el intervalo está por debajo de un umbral configurable y el informe no contiene evidencia para los seis criterios de calidad, el hook lo bloquea. El agente no puede omitir el ciclo de revisión-evaluación-refinamiento-perspectiva general porque el hook lo impone independientemente de lo que el modelo intente.

# quality-gate.sh — block reports missing evidence
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output."}'
else
  echo '{"decision":"allow"}'
fi

Detección de Espejismo de Confianza. Un hook de grep se ejecuta en cada informe de finalización y busca frases evasivas: “debería funcionar”, “estoy seguro”, “parece correcto”, “probablemente está bien”. La presencia de estas frases sin salida de pruebas adyacente o citas de rutas de archivo activa un bloqueo. El modelo debe reemplazar las afirmaciones de confianza con evidencia.¹¹

La investigación respalda este enfoque. Xiong et al. encontraron que los LLMs expresan confianza en el rango del 80-100% independientemente de la precisión real, con la predicción de fallos de GPT-4 apenas por encima del azar (AUROC de 62,7%).¹¹ La confianza verbalizada no está correlacionada con la corrección. Un detector de evasivas detecta lo que la autoevaluación no puede.

Detección de Verificación Fantasma. Un ejecutor de pruebas independiente se activa después de cada cambio de código. El agente no puede afirmar que las pruebas pasan porque el hook reporta los resultados reales. Si la salida del hook muestra fallos, el agente debe abordarlos antes de que se acepte el informe de finalización. El estado de pruebas autorreportado nunca se da por confiable.

Este hallazgo refleja el estudio de Stanford sobre código inseguro: los participantes con asistencia de IA tenían mayor probabilidad de creer que escribieron código seguro incluso cuando no lo habían hecho.⁴ La autoverificación no es confiable ya sea que el verificador sea humano o artificial.

Detección de Deuda Diferida. Un hook PostToolUse se ejecuta después de cada escritura de archivo y busca en el diff TODO, FIXME, HACK y XXX. Cualquier comentario de trabajo diferido en código nuevo activa una advertencia. El agente debe resolver el problema o escalarlo como un bloqueante.

# deferred-debt-check.sh — catch deferred work in new code
CONTENT="$1"
DEBT=$(echo "$CONTENT" | grep -ciE '\bTODO\b|\bFIXME\b|\bHACK\b|\bXXX\b')
if [ "$DEBT" -gt 0 ]; then
  echo '{"decision":"block","reason":"Deferred debt detected. Solve it now or escalate."}'
else
  echo '{"decision":"allow"}'
fi

Detección de Informe Vacío. La Puerta de Evidencia requiere seis tipos de evidencia específicos en cada informe de finalización: patrón del código nombrado, alternativas más simples explicadas, casos límite listados, salida de pruebas pegada, archivos adyacentes verificados, necesidad del usuario replanteada. Un informe al que le falte cualquier fila es bloqueado. Un informe que podría describir cualquier cambio en cualquier código es, por definición, un informe vacío.¹⁵

El problema de la acumulación

Los modos de falla no operan de forma aislada. Se encadenan.

La cadena más común comienza con el Espejismo de Confianza. El agente genera código y afirma “estoy seguro de que esto maneja todos los casos límite.” Debido a que la confianza reemplaza la verificación, el agente omite ejecutar las pruebas. Omitir las pruebas activa la Verificación Fantasma: el informe de finalización dice “las pruebas deberían pasar” en tiempo futuro en lugar de reportar resultados observados. Debido a que las pruebas nunca se ejecutaron, los problemas latentes no se descubren. El agente marca la tarea como completa con un informe que dice “Se actualizó el módulo, los cambios son retrocompatibles, las pruebas deberían pasar.” El resultado es un Informe Vacío: estructuralmente completo, evidencialmente vacío.

Si el agente encontró un problema durante la implementación que no pudo resolver de forma limpia, escribió un comentario TODO y continuó. La Deuda Diferida permanece en el código. La siguiente sesión del agente encuentra el mismo problema sin resolver, lo sortea, y la deuda se acumula.

La cadena se ejecuta en segundos. Sin infraestructura de detección, un revisor humano ve un informe de finalización plausible y lo acepta. Los datos de Faros AI cuantifican el costo posterior: las pull requests asistidas por IA contienen un 9% más de errores y requieren un 91% más de tiempo de revisión.³ El análisis de CodeRabbit de 470 pull requests encontró que los cambios generados por IA producen 1,7 veces más problemas por PR: 1,75 veces más errores de lógica, 1,57 veces más hallazgos de seguridad, 2,74 veces más vulnerabilidades XSS.¹²

El encadenamiento también explica por qué persiste el muro del 10% de productividad. DX encuestó a 121.000 desarrolladores y encontró que la productividad se estancó en aproximadamente un 10% a pesar del 91% de adopción.⁷ DORA 2024 encontró que un aumento del 25% en la adopción de IA se correlacionó con una disminución del 7,2% en la estabilidad de entrega.⁶ El desarrollador individual escribe código más rápido. La organización absorbe las fallas acumulativas a través de retrabajo, incidentes y cuellos de botella en la revisión. GitClear midió el síntoma directamente: la rotación de código (código reescrito dentro de las dos semanas posteriores a su creación) se proyectó que se duplicaría en relación con las líneas base pre-IA, mientras que los cambios asociados a refactorización cayeron del 25% a menos del 10%.⁵

La velocidad sin verificación produce volumen sin calidad. El volumen sin calidad produce retrabajo. El retrabajo consume las ganancias de productividad. El muro se mantiene.

Lo que el hilo de HN acertó (y lo que no)

Los contribuyentes del hilo describieron de forma independiente la mayoría de los siete modos de falla. El cron job de $24,88 es una Espiral de Atajos: el agente optimizó para la finalización de la tarea sin ninguna puerta de verificación. La salida de 500 KB de documentación es Visión de Túnel: el agente se enfocó en una subtarea (describir el trabajo) mientras ignoraba la tarea real (hacer el trabajo). Los errores recurrentes entre sesiones son Deuda Diferida: las correcciones que no se despliegan se acumulan hasta que las mismas fallas se repiten.

Lo que el hilo pasó por alto es la estructura. Las anécdotas individuales sugieren que los agentes de IA fallan de maneras impredecibles. La taxonomía revela lo contrario: los agentes fallan de maneras predecibles porque la estructura de incentivos es consistente. Un agente que optimiza para señales de finalización tomará atajos en la verificación si nada lo detiene. Un agente que se autoevalúa sobreestimará su confianza porque la autoevaluación está sistemáticamente descalibrada.^{11 13} Un agente que encuentra problemas irresolubles los diferirá porque “resolverlo después” termina la tarea actual más rápido que “resolverlo ahora.”

Las anécdotas también omiten la solución. Cada comentario del hilo propone un parche diferente: “Agregué una regla a mi prompt”, “Reviso la salida manualmente”, “Limité a qué tiene acceso.” El prompting no es confiable porque los modelos cumplen instrucciones de manera inconsistente. La revisión manual no escala porque la IA genera código más rápido de lo que los humanos lo revisan.³ El control de acceso aborda un modo de falla (acciones destructivas) mientras deja otros seis sin detectar.

La solución es infraestructura. Hooks determinísticos que se ejecutan en cada finalización, cada escritura de archivo, cada llamada a herramienta. Puertas de calidad que requieren evidencia, no confianza. Verificación independiente que ejecuta el conjunto de pruebas independientemente de lo que el agente afirme. Las herramientas existen. Claude Code expone 17 eventos del ciclo de vida, cada uno conectable con scripts de shell.¹⁵ La pregunta es si los equipos construyen los hooks o aceptan el muro del 10%.

La encuesta 2025 de Stack Overflow cuantificó el costo de no construirlos: el 66% de los desarrolladores dedican tiempo a corregir soluciones de IA que son “casi correctas, pero no del todo.” El 45% encuentra que depurar código generado por IA consume más tiempo que escribirlo desde cero. La confianza en la precisión de la IA cayó al 33%, con un 46% desconfiando activamente de la salida de IA.⁸

Las fallas no son misteriosas. Tienen nombres, señales de detección y soluciones. La taxonomía las convierte en problemas de ingeniería en lugar de folklore.

Fuentes