El agente escribe código. ¿Pero puede mantener un sistema?

Segunda entrega de la serie Después del hype: ingeniería de software con agentes. La primera fue: Por favor, no inventemos otra ingeniería esta semana.

Un agente puede implementar una función, ejecutar pruebas y cerrar una tarea. Eso ya es útil. Pero es una pregunta distinta a esta:

¿Puede conservar la coherencia de un sistema mientras cambia durante horas o días?

La diferencia parece sutil hasta que la tarea deja de ser local.

issue
  ↓
implementar
  ↓
probar
  ↓
pass

Ese flujo permite evaluar si una intervención puntual salió bien. El desarrollo real acumula otra clase de historia:

tarea A
  ↓
tarea B depende de A
  ↓
cambio de arquitectura
  ↓
tarea C modifica una suposición de A
  ↓
regresión en B
  ↓
¿sigue siendo coherente el sistema?

LoopsBench mide justamente esa diferencia

El preprint LoopsBench: From Harness Engineering to Loop Engineering in Coding Agent Evaluation intenta acercarse a este segundo escenario. Sus autores construyen 112 tareas a partir de más de 5,300 unidades de desarrollo, en ocho lenguajes y nueve dominios.

La diferencia relevante no es sólo la cantidad. Cada tarea se modela como un grafo dirigido de dependencias: algunas unidades deben completarse antes que otras, y las unidades que ya estaban resueltas se mantienen como obligaciones de regresión.

        A
      /   \
     B     C
     │    / \
     D   E   F
      \     /
         G

Resolver F no basta si rompe B. Aprobar la prueba de una unidad recién abierta tampoco basta si invalida una condición que antes ya era correcta.

Este diseño importa porque evalúa una propiedad que los resultados finales esconden: la capacidad de sostener trabajo acumulado sin perder las dependencias que ya estaban en juego.

El dato incómodo no es un veredicto contra los agentes

La configuración más fuerte evaluada en el estudio —Opus-4.7 con Claude Code y una continuación externa— completó 25% de las tareas completas. Los autores también observaron que los planes recuperaban sólo parte de las dependencias reales y que seguían ocurriendo regresiones durante la ejecución prolongada.

No usaría ese 25% para concluir que los agentes “no sirven”. Un benchmark no agota el valor de una herramienta, y el resultado depende del entorno y de la configuración evaluada.

Pero sí contradice una inferencia frecuente: si un agente puede producir buen código en una tarea aislada, entonces basta con dejarlo correr más tiempo para que produzca ingeniería de software autónoma.

No se sigue.

Un loop ayuda, pero no añade juicio por sí mismo

La intuición de Loop Engineering es buena. En lugar de una sola respuesta, el agente entra en un ciclo de trabajo, verificación y corrección:

objetivo
   ↓
trabajo
   ↓
verificación
   ↓
¿terminado?
 /        \
sí         no
           ↓
        corregir
           ↓
       verificar

Es mejor que pedir una modificación y confiar en el primer resultado. Pero continuar no equivale a comprender.

Un loop no garantiza que el agente haya descubierto todas las dependencias, que el criterio de éxito sea suficiente o que el plan inicial siga siendo correcto después de varios cambios. Tampoco puede saber, por sí solo, que una arquitectura está creciendo de forma desproporcionada respecto al problema que intenta resolver.

El modo de fallo más peligroso es aburridamente plausible:

premisa equivocada
      ↓
implementación local
      ↓
prueba insuficiente
      ↓
pass
      ↓
continuar sobre la misma premisa

El loop no necesariamente corrige ese error. Puede hacerlo más rápido y más profundo.

Human in the loop no significa aprobar cada comando

La alternativa tampoco es convertir al humano en un botón de “sí”:

agente: ¿puedo abrir este archivo?
humano: sí

agente: ¿puedo ejecutar las pruebas?
humano: sí

Eso desperdicia la autonomía que sí podemos conceder con seguridad. La división útil se parece más a esto:

repetible       verificable       ambiguo
    ↓                ↓               ↓
agente          harness         humano

La máquina puede comprobar de forma más confiable que un build pasa, que un tipo obligatorio existe o que una migración cumple un esquema. El humano sigue aportando donde faltan criterios deterministas: intención de producto, prioridades, arquitectura, riesgos y calidad de una solución más allá de la prueba inmediata.

El objetivo no es elegir entre autonomía total y supervisión constante. Es diseñar fronteras de autonomía que correspondan al riesgo y a la posibilidad real de verificar.

La consecuencia práctica

Si queremos que un agente haga más que resolver tickets aislados, no basta con aumentar el número de iteraciones. Hay que mejorar el sistema alrededor del agente:

• contratos y tipos que hagan visibles las suposiciones;
• pruebas que retengan obligaciones de regresión;
• documentación recuperable para decisiones que no están en el código;
• límites de alcance y permisos;
• revisiones para decisiones que no se pueden reducir a un pass;
• mecanismos que conviertan los errores repetidos en guardrails ejecutables.

Ese entorno no le da al modelo una inteligencia distinta. Hace que sus aciertos sean verificables y que sus errores tengan menos espacio para propagarse.

La pregunta no es si debemos usar loops. Debemos. La pregunta es qué estamos verificando dentro de ellos y quién decide cuando el problema deja de tener una respuesta determinista.