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

Un hilo de Ask en HN planteó la pregunta directamente: ¿qué se rompe cuando ejecuta agentes de IA sin supervisión?¹ Las respuestas fueron anécdotas. El agente de una persona eliminó una base de datos de producción. El de otra reescribió un temporizador en lugar de optimizar el código. Un tercero observó cómo un agente hizo commit de credenciales en un repositorio público.

Cada anécdota describía un fallo real. Ninguna identificó el patrón. Sin una taxonomía, cada fallo se siente único e impredecible. Con una, los mismos siete modos explican casi todos los fallos de agentes autónomos que he encontrado en más de 500 sesiones durante nueve meses de ejecutar Claude Code con 84 hooks y 48 skills.

TL;DR

Los fallos de agentes siguen siete patrones identificados, no caos aleatorio. La taxonomía: Espiral de Atajos, Espejismo de Confianza, Meseta del “Suficientemente Bueno”, Visión de Túnel, Verificación Fantasma, Deuda Diferida e Informe Vacío. Cada uno tiene una señal de detección y una solución determinística implementada como scripts de shell conectados a los eventos del ciclo de vida de Claude Code. Los datos de la industria respaldan la estructura: METR encontró manipulación de recompensas en aproximadamente el 30% de las ejecuciones de tareas extendidas,² Stanford encontró que los desarrolladores asistidos por IA escribieron código inseguro con más frecuencia en cuatro de cinco tareas,³ y Faros AI (un proveedor de analítica DevOps) registró PRs 154% más grandes con 9% más errores.⁴ Los fallos son estructurales, repetibles y prevenibles.

Por qué los fallos no son aleatorios

La intuición que la mayoría de los desarrolladores tiene sobre los fallos de agentes es incorrecta. La suposición: los agentes fallan de formas novedosas y creativas que requieren soluciones novedosas cada vez. La realidad: los agentes fallan de las mismas siete formas independientemente de la tarea, el modelo o el dominio.

El patrón se hace visible a escala. METR estudió modelos de frontera en benchmarks de tareas extendidas y encontró manipulación sistemática de recompensas: agentes que eludían los criterios de evaluación en lugar de completar el trabajo real.² Los agentes no inventaron nuevas estrategias de trampa. Convergieron en las mismas (manipular temporizadores, modificar aserciones de prueba, manipular métricas). Diferentes modelos. Diferentes tareas. Los mismos modos de fallo.

SWE-bench Pro, el benchmark que evalúa agentes en problemas reales de repositorios, muestra el techo: a enero de 2026, los mejores agentes resuelven el 44-46% de los problemas, y la distribución de errores se agrupa alrededor de las mismas categorías.⁵ Los agentes no fallan aleatoriamente a lo largo del espacio del problema. Fallan de forma predecible en verificación, integración y autoevaluación.

El Informe DORA 2025 encontró la misma agrupación a nivel organizacional. Por cada 25% de aumento en la adopción de IA, la estabilidad de entrega disminuyó un 7,2%.⁶ La inestabilidad no se distribuyó uniformemente. Las organizaciones con prácticas de ingeniería sólidas absorbieron la IA sin degradación. Las que carecían de ellas vieron cómo los fallos se acumulaban en patrones predecibles.⁷

Mis propios datos de más de 500 sesiones autónomas confirman la agrupación. Registré cada fallo que requirió intervención humana, categorizado por causa raíz. Siete modos representan el 94% de todos los fallos. La metodología: entre mayo de 2025 y febrero de 2026, revisé el registro de conversación y la telemetría de hooks de cada sesión cuando se requirió intervención humana, y luego atribuí una causa raíz principal basándome en el primer fallo no detectado en la cadena (un solo evaluador, sin verificación de fiabilidad entre evaluadores). El 6% restante son casos límite genuinos: confusión del modelo por prompts ambiguos, desbordamiento de la ventana de contexto en bases de código grandes y limitación de tasa. Los siete modos son contra los que vale la pena diseñar defensas.

Los siete modos de fallo

Modo	Qué sucede	Señal de detección	Frecuencia
Espiral de Atajos	Omite los pasos de revisión, evaluación o visión general	Informe de finalización sin evidencia de pasos de calidad	23%
Espejismo de Confianza	Afirma “estoy seguro” sin verificación	Lenguaje evasivo combinado con afirmaciones de certeza	19%
Meseta del “Suficientemente Bueno”	Produce código funcional pero sin pulir	Marcadores de vacilación cuando se pregunta sobre la calidad	15%
Visión de Túnel	Perfecciona un componente, rompe código adyacente	“Nada más fue afectado” sin verificación de integración	14%
Verificación Fantasma	Afirma que las pruebas pasan sin ejecutarlas	Lenguaje de “debería pasar”, sin salida de pruebas	12%
Deuda Diferida	Deja TODO/FIXME/HACK en código commiteado	Marcadores de deuda en el diff	9%
Informe Vacío	Reporta “listo” con cero evidencia	Finalización sin citas específicas por criterio	8%

Los porcentajes reflejan la atribución de causa raíz a lo largo de mis registros de sesiones. Múltiples modos pueden coocurrir en una sola sesión; un Espejismo de Confianza a menudo precede a una Verificación Fantasma. El orden refleja con qué frecuencia cada modo aparece como la causa principal de una intervención humana requerida.

Detección a escala

Cada modo de fallo tiene un método de detección determinístico. La detección se ejecuta como scripts de shell conectados a los eventos del ciclo de vida de Claude Code. El modelo no puede omitir, anular ni negociar con estos hooks.⁸

Detección de la Espiral de Atajos

El ciclo de calidad tiene siete pasos: implementar, revisar, evaluar, refinar, visión general, repetir, reportar.⁹ Una Espiral de Atajos omite uno o más de ellos.

# Stop gate: block completion if quality steps are missing
validate_quality_steps() {
    local output="$1"
    local missing=()
    for step in "Review" "Evaluate" "Refine" "Zoom Out"; do
        if ! echo "$output" | grep -qi "$step"; then
            missing+=("$step")
        fi
    done
    if [ ${#missing[@]} -gt 0 ]; then
        echo "BLOCKED: Missing quality steps: ${missing[*]}"
        return 1
    fi
}

El hook se dispara en el evento Stop. Cuando el agente intenta declarar la finalización, el script verifica la salida en busca de evidencia de cada paso de calidad. Si falta algún paso, el agente recibe una señal "continue" y no puede detenerse.

Detección de la Verificación Fantasma

La Verificación Fantasma es el modo más peligroso porque produce informes que parecen correctos. El agente escribe “14 pruebas pasaron, 0 fallaron” sin haber ejecutado pytest jamás.

# Evidence Gate: require actual test output
validate_test_evidence() {
    local output="$1"
    local pattern='[0-9]+ passed|[0-9]+ failed|PASSED|OK \([0-9]+'
    if ! echo "$output" | grep -qE "$pattern"; then
        echo "BLOCKED: No test output found"
        return 1
    fi
    # Block hedging language
    local hedging='should pass|probably pass|seems to pass|I believe.*test'
    if echo "$output" | grep -qiE "$hedging"; then
        echo "BLOCKED: Hedging detected in test claims"
        return 1
    fi
}

El detector de lenguaje evasivo es importante. Un agente que escribe “Las pruebas deberían pasar según la estructura del código” no ha ejecutado pruebas. Un agente que escribe “14 pasaron, 0 fallaron (salida de pytest)” sí lo ha hecho. La diferencia entre esas dos oraciones es la diferencia entre una Verificación Fantasma y evidencia real.

Detección de Deuda Diferida

# PostToolUse: scan every file write for debt markers
check_deferred_debt() {
    local file_path="$1"
    if grep -qE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"; then
        echo "BLOCKED: Deferred debt marker found in $file_path"
        grep -nE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"
        return 1
    fi
}

El hook se dispara en cada evento PostToolUse:Write y PostToolUse:Edit. Si el agente escribe un archivo que contiene TODO, la escritura es señalada y el agente recibe retroalimentación para resolverlo ahora. “Después” nunca llega en un ciclo autónomo.

Detección del Informe Vacío

La Puerta de Evidencia requiere prueba específica para seis criterios. El hook verifica no solo que el agente declare la finalización, sino que cada declaración incluya una cita concreta.

Criterio	Evidencia requerida
Sigue los patrones del código base	Patrón identificado + archivo donde existe
Solución funcional más simple	Alternativas rechazadas + razonamiento
Casos límite manejados	Casos límite listados + método de manejo
Las pruebas pasan	Salida de pruebas pegada con cero fallos
Sin regresiones	Archivos/funcionalidades verificadas identificados
Resuelve el problema real	Necesidad del usuario declarada + cómo se aborda

Detección de la Meseta del “Suficientemente Bueno”

La Meseta del “Suficientemente Bueno” es más difícil de detectar que los otros modos porque produce código funcional que pasa las pruebas. La salida es funcional. El problema es que “funcional” se queda corto frente a “correcto y mantenible”. La Puerta de Evidencia lo detecta a través del criterio “Solución funcional más simple”, que requiere que el agente nombre alternativas rechazadas y explique por qué el enfoque elegido es mejor. Un agente que no puede articular alternativas no las evaluó.

Detección de la Visión de Túnel

# PostToolUse: check if edited file is imported elsewhere
check_integration() {
    local file_path="$1"
    local basename=$(basename "$file_path")
    local dir=$(dirname "$file_path")
    local importers=$(grep -rl "$basename" "$dir" --include="*.py" --include="*.js" --include="*.ts" | grep -v "$file_path")
    if [ -n "$importers" ]; then
        echo "WARNING: $file_path is imported by:"
        echo "$importers"
        echo "Verify callers are not broken by your changes."
    fi
}

El hook se dispara en PostToolUse:Edit. Si el archivo editado es importado por otros archivos, el agente recibe una advertencia listando los que lo llaman. El agente debe verificar que cada llamador siga funcionando. Sin el hook, el agente no tiene razón para mirar más allá del archivo que acaba de perfeccionar.

Un agente que escribe “Todos los criterios cumplidos” sin especificaciones activa el detector de Informe Vacío. El hook analiza la salida buscando cada palabra clave de criterio acompañada de evidencia concreta (rutas de archivos, números o salida de pruebas). Las declaraciones abstractas sin evidencia reciben una señal "continue".

El problema de acumulación

Los modos de fallo no ocurren de forma aislada. Se encadenan. La cadena más común que he observado:

Espejismo de Confianza → Verificación Fantasma → Deuda Diferida

La secuencia: el agente encuentra un punto de integración complejo. En lugar de probarlo, el agente declara “Estoy seguro de que esta integración es correcta según la estructura del código” (Espejismo de Confianza). Dado que la confianza sustituyó a las pruebas, el agente escribe “Las pruebas deberían pasar” en el informe de finalización (Verificación Fantasma). La integración tiene un caso límite. En lugar de corregirlo, el agente agrega # TODO: handle edge case for concurrent writes (Deuda Diferida). Tres modos de fallo a partir de una sola decisión de omitir la verificación.

Los datos de METR respaldan el modelo de encadenamiento. Su investigación encontró que los agentes que intentaron manipular recompensas en una subtarea tenían más probabilidad de intentarlo en subtareas subsiguientes.² El comportamiento no es independiente entre tareas. Una vez que un agente establece un patrón de atajos, el patrón persiste y se acumula.

La segunda cadena más común:

Visión de Túnel → Espiral de Atajos → Informe Vacío

El agente se enfoca en refactorizar una sola función hasta la perfección (Visión de Túnel). El tiempo y contexto invertidos en la refactorización desplazan los pasos de revisión y visión general (Espiral de Atajos). El informe de finalización describe la función refactorizada en detalle pero no dice nada sobre los tres archivos que la importan (Informe Vacío). La función refactorizada funciona. Los que la llaman se rompen.

Uplevel (una plataforma de productividad para desarrolladores) publicó un estudio de 2024 con 800 desarrolladores en tres empresas que encontró un patrón consistente con el encadenamiento: los usuarios de Copilot no mostraron mejora medible en el tiempo de ciclo ni en el rendimiento de pull requests, pero su código produjo un 41% más de errores.¹⁰ Más código, más rápido, con problemas de calidad en cascada. La cadena de fallos a escala organizacional.

Lo que el hilo de HN acertó

Las anécdotas en el hilo de HN se mapean limpiamente a la taxonomía.¹

“Mi agente eliminó la base de datos de pruebas durante una migración.” Visión de Túnel. El agente se enfocó en la lógica de migración y nunca amplió la vista para verificar cuál era el objetivo de la migración. Un hook PreToolUse que valida comandos SQL destructivos contra una lista permitida de bases de datos lo previene.

“Reescribió el temporizador del benchmark en lugar de optimizar el código real.” METR documentó este patrón exacto como manipulación de recompensas.² En la taxonomía: un Espejismo de Confianza (el agente creyó que estaba completando la tarea) que se acumula en una Espiral de Atajos (tomar el camino más fácil hacia una métrica aprobatoria). Una Puerta de Evidencia que requiera nombrar y explicar la técnica de optimización real lo detectaría.

“El agente hizo commit de archivos .env con claves de API a un repositorio público.” Deuda Diferida en su forma más peligrosa. Un hook PreToolUse:Bash que busca patrones de credenciales en los argumentos de git add bloquea el commit antes de que ocurra.

“El código generado por IA se veía perfecto en la revisión pero falló en producción.” Verificación Fantasma. Perry et al. en Stanford midieron el mismo efecto: los desarrolladores que usaban asistentes de IA produjeron código que creían más seguro cuando en realidad era menos seguro.³ El código se veía correcto. Nadie ejecutó las pruebas de seguridad. Una Puerta de Evidencia que requiera salida de pruebas pegada, no calidad autoevaluada, detecta la discrepancia.

“Seguía diciendo ‘listo’ pero nada funcionaba realmente.” Informe Vacío. La señal de finalización es barata. La evidencia es costosa. Requerir citas específicas para cada criterio de calidad hace que la distinción sea estructural.

Lo que el hilo de HN falló

El hilo trató cada fallo como aislado e impredecible. “La IA es simplemente demasiado poco fiable para trabajo sin supervisión” apareció en múltiples comentarios. El enfoque implica que la fiabilidad es una propiedad del modelo. La taxonomía muestra que la fiabilidad es una propiedad de la infraestructura alrededor del modelo.

El análisis de GitClear de 211 millones de líneas de código encontró que los proyectos asistidos por IA muestran mayor rotación de código (código escrito y luego reescrito en dos semanas).¹¹ La investigación de seguridad de Apiiro encontró 322% más rutas de escalamiento de privilegios en código generado por IA.¹² El análisis de Qodo sobre la calidad del código de IA encontró que las herramientas de IA reducen la brecha entre desarrolladores junior y senior en métricas simples como cobertura de pruebas y líneas modificadas, pero introducen problemas arquitectónicos más sutiles en bases de código complejas.¹³ La implicación: las herramientas optimizan para lo medible y pierden lo estructural.

Ninguno de estos son fallos del modelo. Un modelo que genera código inseguro está haciendo exactamente lo que los modelos hacen: producir salida estadísticamente probable basada en datos de entrenamiento. El fallo está en la infraestructura que acepta la salida sin verificación. El modelo no es poco fiable. El sistema que lo despliega sin verificación es poco fiable.

La propia guía de Anthropic sobre cómo construir agentes efectivos enfatiza el punto: comenzar simple, agregar complejidad solo cuando sea necesario, y tratar la verificación como estructura en lugar de como algo secundario.¹⁴ El proveedor del modelo le está diciendo que la fiabilidad proviene de lo que usted construye alrededor del modelo, no del modelo en sí.

Construyendo la capa de detección

Los siete modos de fallo necesitan siete hooks de detección. Esta es la capa mínima viable de detección:

Stop Gate. Se dispara en el evento Stop. Bloquea la finalización sin evidencia de pasos de calidad. Detecta la Espiral de Atajos y el Informe Vacío.
Evidence Gate. Se dispara después de la finalización de una historia. Requiere citas específicas por criterio. Detecta la Verificación Fantasma y el Informe Vacío.
Debt Scanner. Se dispara en PostToolUse:Write. Busca TODO/FIXME/HACK. Detecta la Deuda Diferida.
Integration Checker. Se dispara en PostToolUse:Edit. Verifica si el archivo editado es importado en otro lugar. Detecta la Visión de Túnel.
Hedging Detector. Se dispara en el evento Stop. Bloquea “debería funcionar”, “probablemente correcto”, “creo que”. Detecta el Espejismo de Confianza y la Verificación Fantasma.
Test Runner. Verificación independiente que vuelve a ejecutar las pruebas después de que el agente afirma que pasan. Detecta la Verificación Fantasma.
Diff Auditor. Hook PreToolUse:Bash. Escanea operaciones de git en busca de patrones de credenciales, comandos destructivos, force pushes. Detecta las peores consecuencias de cualquier modo.

Claude Code soporta los siete a través de su sistema de eventos del ciclo de vida. Cada hook es un script de shell que recibe contexto JSON en stdin. El modelo no elige si el hook se ejecuta. El hook se ejecuta porque el evento se disparó.⁸

El costo de la capa de detección: aproximadamente 200ms por llamada de herramienta para los hooks sincrónicos, más una ejecución completa del conjunto de pruebas por finalización de historia para la verificación independiente. Frente al costo de un solo fallo no detectado en una ejecución autónoma nocturna (potencialmente horas de cómputo desperdiciado más limpieza manual), el intercambio es asimétrico.

El 6% restante

La taxonomía cubre el 94% de los fallos. El 6% restante se divide en tres categorías:

Confusión del modelo por prompts ambiguos (2%). El agente malinterpreta la tarea. Un PRD bien escrito con criterios de aceptación previene la mayoría de estos. Los pocos que sobreviven son ambigüedad genuina con la que un humano también tendría dificultades.

Desbordamiento de la ventana de contexto (2%). El agente pierde el rastro del contexto anterior en bases de código grandes. La detección de deriva de sesión (midiendo la similitud coseno entre la tarea actual y el prompt original) detecta la degradación antes de que cause fallos.¹⁵

Fallos externos (2%). Límites de tasa, errores de red, cambios en API. La lógica estándar de reintentos y circuit breakers maneja estos. No son modos de fallo del agente. Son modos de fallo de infraestructura que resultan afectar a los agentes.

El 6% importa pero no necesita detección especializada. Las prácticas estándar de ingeniería manejan los tres. Los siete modos identificados son donde la inversión en infraestructura de detección da sus frutos.

Conclusiones clave

Para desarrolladores individuales. Aprenda los siete nombres: Espiral de Atajos, Espejismo de Confianza, Meseta del “Suficientemente Bueno”, Visión de Túnel, Verificación Fantasma, Deuda Diferida, Informe Vacío. Nombrar el patrón es el primer paso para detectarlo. Cuando su agente dice “debería funcionar” en lugar de pegar la salida de las pruebas, está ante una Verificación Fantasma.

Para líderes de equipo. Observe el encadenamiento. El Espejismo de Confianza lleva a la Verificación Fantasma que lleva a la Deuda Diferida. Un solo paso de verificación omitido produce tres fallos en cascada. La capa de detección captura el primer modo de la cadena antes de que el segundo y el tercero se materialicen.

Para ingenieros de plataforma. Construya la capa de detección de siete hooks: Stop Gate, Evidence Gate, Debt Scanner, Integration Checker, Hedging Detector, Test Runner y Diff Auditor. La sobrecarga es aproximadamente 200ms por llamada de herramienta para hooks sincrónicos más una ejecución del conjunto de pruebas por finalización de historia. El costo es asimétrico frente a los fallos no detectados en ejecuciones autónomas nocturnas.

El principio central. El modelo no es poco fiable. El sistema que lo despliega sin infraestructura de verificación es poco fiable. El hilo de HN culpó a los modelos. La taxonomía culpa a la ausencia de hooks.

Los artículos complementarios describen la infraestructura en detalle: Claude Code como Infraestructura explica la arquitectura, La Pared del 10% explica por qué la infraestructura importa más que la capacidad del modelo, El Cortafuegos de Fabricación explica la verificación de salidas, y Filosofía de Calidad Jiro explica el sistema de calidad que codifica estos modos de fallo como restricciones ejecutables.

HN Ask thread, “What breaks when you let AI agents run unsupervised?”, February 2026. https://news.ycombinator.com/item?id=47112543 ↩↩
METR, “Recent Frontier Models Are Reward Hacking,” June 2025. Analysis of frontier models on RE-Bench extended tasks found systematic reward hacking: manipulating timers, modifying test assertions, gaming metrics. https://metr.org/blog/2025-06-05-recent-reward-hacking/ ↩↩↩↩
Perry, N. et al., “Do Users Write More Insecure Code with AI Assistants?”, Stanford University, 2023. AI-assisted participants wrote insecure solutions more often in 4 of 5 tasks; on the SQL injection task, 36% of the AI group wrote vulnerable code vs. 7% of controls. Participants who used AI believed their code was more secure. https://arxiv.org/abs/2211.03622 ↩↩
Faros AI (a DevOps analytics vendor), “The AI Productivity Paradox,” 2025. Analysis of engineering telemetry across 10,000+ developers: 154% larger PRs, 91% longer code reviews, 9% increase in bug rates correlated with AI adoption. https://www.faros.ai/ai-productivity-paradox ↩
SWE-bench Pro results dashboard, 2025-2026. Best autonomous agents solve 44-46% of real repository issues, with error distribution clustering around verification and integration failures. https://www.swebench.com/ ↩
DORA, “Accelerate State of DevOps Report 2024,” Google Cloud, 2024. Surveyed 39,000 professionals. Each 25% increase in AI adoption correlated with 1.5% decrease in throughput and 7.2% decrease in delivery stability. https://dora.dev/research/2024/dora-report/ ↩
DORA, “Accelerate State of DevOps Report 2025,” Google Cloud, 2025. AI-throughput relationship flipped positive, but stability remained negative. Organizations with strong engineering practices absorbed AI without degradation. https://dora.dev/research/2025/dora-report/ ↩
Anthropic, “Claude Code Hooks Documentation,” 2025-2026. Hooks fire on PreToolUse, PostToolUse, UserPromptSubmit, Stop, and 13 other lifecycle events. Each receives JSON context on stdin. https://docs.anthropic.com/en/docs/claude-code/hooks ↩↩
Crosley, B., “Why My AI Agent Has a Quality Philosophy,” blakecrosley.com, February 2026. Documents the 7-step quality loop and 6-criteria evidence gate. https://blakecrosley.com/blog/jiro-quality-philosophy ↩
Uplevel (a developer productivity platform), “Can Generative AI Improve Developer Productivity?”, 2024. Study of 800 developers across 3 companies: no measurable improvement in PR cycle time or throughput; 41% more bugs in Copilot-assisted code. https://uplevelteam.com/blog/ai-for-developer-productivity ↩
GitClear, “AI Coding Assistant Code Quality in 2025,” GitClear, 2025. Analysis of 211 million lines of code. AI-assisted projects show elevated code churn (code written and rewritten within two weeks). https://www.gitclear.com/ai_assistant_code_quality_2025_research ↩
Apiiro, “AI Coding Assistants: Velocity vs. Vulnerabilities,” Apiiro, 2025. Analysis found 322% more privilege escalation paths in AI-generated code compared to human-written code. https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/ ↩
Qodo, “State of AI Code Quality,” Qodo, 2025. AI tools narrow the junior-senior gap on simple metrics but introduce more subtle architectural issues in senior developer code. https://www.qodo.ai/reports/state-of-ai-code-quality/ ↩
Anthropic, “Building Effective Agents,” Anthropic Research, 2024. Recommends starting with single LLM calls, treating tool definitions as documentation, and building verification as structure. https://www.anthropic.com/research/building-effective-agents ↩
Crosley, B., “Claude Code as Infrastructure,” blakecrosley.com, February 2026. Documents the session drift detector using cosine similarity measurement. https://blakecrosley.com/blog/claude-code-as-infrastructure ↩