Por qué tu agente nunca se detiene Image: AI generated

El alarde del 24/7

“Tengo un agente corriendo 24 horas.”

Es una frase que se ve a menudo en X. Como si cuanto más tiempo corre el agente, más trabajo hiciera. Como si una persona fuera más productiva por no dormir.

Pero ante esta frase lo que surge no es admiración, sino una duda.

"¿Por qué todavía no ha terminado?"

Un sistema que puede detenerse es un sistema sano

Le encargué a un agente escribir tests para 527 funciones. El resultado:

Agente autónomo:  declaró "ya está hecho" tras completar 40 / 527
Bucle CLI:        terminó tras completar 527 / 527

El bucle CLI tardó 1 hora. No 24 horas. Procesa una función, la verifica, si pasa avanza a la siguiente, y cuando todo termina se detiene. Lo esencial de este bucle no es la velocidad, sino que la condición de terminación está definida mecánicamente.

TODO → escribir test → medir cobertura → PASS/DONE → siguiente → ... → todo completo → detenerse

finite. measurable. monotonic. Por eso converge. Por eso se detiene.

Poder detenerse no es una debilidad. Significa que está sano.

Tres razones por las que no se detiene

Que un agente corra durante mucho tiempo suele deberse a una de tres causas.

1. El verificador es débil

"looks good"
"seems better"
"more scalable"
"clean architecture"

Estos no son criterios de convergencia. Son juicios subjetivos. go test devuelve pass/fail, pero ¿quién dictamina la “clean architecture”? ¿Otro LLM? Eso es como preguntarle a un amigo borracho “¿estoy borracho?”.

La evidencia empírica lo respalda. Los jueces LLM para evaluar código se sesgan incluso ante variaciones superficiales de código semánticamente equivalente, inflando o recortando injustamente la puntuación (Moon et al. 2025), y los modelos ceden su propia respuesta para mostrarse conformes en el 58,19 % de los casos (SycEval, Fanous et al. 2025). “looks good” no guarda relación con la corrección. Además, un criterio débil no se queda en no detenerse: cuando la medición se convierte en objetivo, la medición se corrompe (ley de Goodhart; Manheim & Garrabrant 2018), y los modelos de razonamiento competentes, en lugar de resolver la tarea de frente, hackean el propio procedimiento de verificación (Bondarenko et al. 2025).

Sin criterio de convergencia, no hay final.

2. No hay límites de tarea

"mejora el codebase"
"haz la arquitectura más limpia"
"sigue optimizando"

Son tareas sin condición de terminación. Incluso un desarrollador humano vaga sin fin con objetivos así. Para un agente no es distinto. “Mejorar” es una dirección, no un destino.

3. La entropía supera la velocidad de corrección

Es el patrón más común y más insidioso.

El agente, al hacer correcciones, añade abstracciones. Introduce indirecciones. Crea generalizaciones innecesarias. El código parece “ir mejorando”, pero en realidad la nueva entropía aumenta más rápido de lo que el verificador la elimina.

la abstracción creada hoy → se elimina de nuevo mañana → se vuelve a añadir pasado mañana

Esto es optimización no monótona (non-monotonic optimization). Parece avanzar, pero está en el mismo sitio. Parece una máquina de movimiento perpetuo, pero solo consume energía. En este caso, la energía son tokens.

Estudios empíricos a gran escala captan este drift. La adopción de Cursor elevó la velocidad a corto plazo, pero las advertencias del análisis estático y la complejidad del código aumentaron de forma sostenida, y esa acumulación fue la causa principal de la desaceleración a largo plazo (He et al. 2025, 807 repositorios de código abierto). De más de 300 000 commits escritos por IA, el 22,7 % de los problemas introducidos sobrevivió como deuda técnica hasta la versión más reciente (Liu et al. 2026). La corrección no alcanza a la entropía.

No es un problema de búsqueda, sino de satisfacción de restricciones

Aquí se revela una diferencia fundamental de perspectiva.

“Si dejas correr el agente más tiempo sale un mejor resultado” es ver la ingeniería de software como un problema de búsqueda (search problem). La expectativa de que, al explorar mucho un espacio amplio, se encontrará una mejor solución.

Pero la ingeniería de software es, en esencia, un problema de satisfacción de restricciones (constraint satisfaction problem).

  • Los tipos deben coincidir
  • Los tests deben pasar
  • La cobertura debe cumplirse
  • El esquema debe coincidir
  • Hay que respetar las reglas del linter

Cuando se satisfacen todas estas restricciones, se acabó. No hay que “explorar más”. Definir las restricciones, satisfacerlas y detenerse. Eso es todo.

El código ya es un dominio verificable por máquina (machine-checkable domain). Compilador, type-checker, tests, cobertura, linter, validación de esquema: todos ellos son verificadores deterministas. Si existen estos verificadores, ¿por qué hacer que el agente explore sin fin?

La investigación sobre aprendizaje apunta en la misma dirección. Usar verificadores deterministas como los tests unitarios como recompensa —recompensa verificable (verifiable reward)— mejora la corrección del código frente a la generación abierta (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). El verificador no es una herramienta para estrechar la búsqueda. Es la prueba de que, de entrada, este problema no es de búsqueda sino de satisfacción.

Las condiciones de un buen bucle

Un buen bucle de agente se cierra en cinco etapas:

1. Definir la tarea      — qué hay que lograr (objetivo dictaminable mecánicamente)
2. Limitar el alcance    — una unidad a la vez (función, endpoint, archivo)
3. Verificación simbólica — herramienta determinista dictamina pass/fail
4. Convergencia          — si pasa, a la siguiente; si falla, reintentar con feedback
5. Terminación           — si no quedan elementos, detenerse

En esta estructura el LLM solo se ocupa del paso 3 (generación). Todo lo demás lo hace la máquina. En particular, lo esencial es que “el final” lo decide la máquina. Si dejas que el LLM juzgue la terminación, escucharás “ya está hecho” en el 40/527.

Los experimentos apuntan en la misma dirección. Acoplar autocrítica (self-critique) a un LLM hace que el rendimiento en tareas de razonamiento y planificación incluso se desplome, y solo mejora notablemente al acoplar un verificador externo sólido (Stechly et al. 2024). La autocorrección intrínseca sin feedback externo fracasa o, a veces, empeora tras corregir (Huang et al. 2023). Hay una razón para no dejar la terminación en manos del LLM.

El creative writing y el código son distintos

Hay una excepción. No todos los dominios son así.

Escritura, marketing, diseño: en estos dominios el verificador es débil. “¿Es buena esta frase?” no se puede dictaminar mecánicamente. En dominios así, una exploración larga puede tener sentido. El agente genera varias variantes y la persona elige.

Pero el código es distinto. El código ya es un mundo lleno de verificadores deterministas. En este mundo, vagar (wandering) durante mucho tiempo no es exploración, sino deriva (drift).

La pregunta

¿Cuántas horas lleva corriendo tu agente ahora mismo?

¿Está convergiendo o está a la deriva?

¿Puede detenerse?

Si puede detenerse, ¿por qué todavía no se ha detenido?

Artículos relacionados

Lecturas adicionales (externas)

  • Designing agentic loops — Simon Willison. Solo con criterios de éxito claros y una suite de tests que pase puede un bucle de agente verificarse a sí mismo y detenerse — el complemento constructivo de este artículo.
  • Building Effective Agents — Anthropic. La razón por la que la codificación es ideal para los agentes es que la solución se puede verificar mediante tests automatizados — el verificador determinista se convierte en señal de parada.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. La decisión de diseño clave no es un mejor modelo, sino una condición de terminación medible, y advierte sobre el “confidence laundering” en que una salida fluida oculta la no convergencia.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. La fiabilidad no viene del modelo, sino del harness de herramientas deterministas (computational controls) — se distingue del control inferencial basado en IA.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. “Cuando la medición se convierte en objetivo, deja de ser una buena medición” — una síntesis técnica del mecanismo por el que se hace gaming del proxy al usar un verificador débil como recompensa.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. A medida que se acumulan los tokens de entrada, la salida se degrada — la causa mecánica de que un bucle que añade, elimina y vuelve a añadir no sea autocorrección sino autorrefuerzo.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. La IA amplifica el rigor existente — con poco rigor acelera el caos, una mirada práctica al fenómeno de la entropía adelantando a la corrección.

Fuentes

Dictamen de terminación · límites de la autoverificación

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · falta de fiabilidad de la autocrítica

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Drift · aumento de la complejidad del código de IA

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Recompensa verificable · generación de código basada en verificadores

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward hacking · gaming de especificación

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)