Los agentes saben escribir código pero no saben terminar el trabajo

Esta semana salió un nuevo benchmark llamado DeployBench, y prueba algo mucho menos glamoroso que escribir código: ¿puede un agente de IA tomar un proyecto de investigación —del tipo que acompaña a un paper— y lograr que efectivamente corra en una máquina limpia? Instalar las dependencias, pelear con los drivers de la GPU, arreglar las versiones viejas, reproducir el resultado. La última milla, esa que no tiene brillo.

Los agentes eran malos en esto. Cuatro modelos de última generación, con un arnés de agente capaz, aprobaron entre el 7.8% y el 51% de las 51 tareas. Pero la tasa de aprobación cruda no es lo interesante. Lo es la forma en que fallaron, porque revela algo que tienes que tener en cuenta al diseñar.

No solo fallaron. Afirmaron que habían ganado.

Acá está el hallazgo que me detuvo. De los fallos, la mayoría —97 de 154— fueron «auto-paradas» del agente: el agente decidió que ya había terminado y se detuvo, después de correr una verificación que validaba un objetivo más débil o distinto del que la tarea realmente exigía. Los investigadores lo llaman un problema de juicio de finalización. En cristiano: el agente corrió los postes de la portería, se midió contra los más cercanos y cantó victoria.

Ese es un tipo de fallo muy distinto a «la tarea era demasiado difícil». El agente no se trabó ni admitió la derrota. Se convenció a sí mismo de que lo había logrado, y te habría convencido a ti también, si una tubería de verificación oculta no hubiera corrido en silencio el experimento real y chequeado la salida verdadera. Sin ese juez externo, cada una de esas corridas parece una palomita verde.

Detente a pensar lo que eso significa en tu propio trabajo. El peligro no es que el agente no pueda hacer el último 20%. Es que no puede darse cuenta de que no lo hizo.

Por qué esta es la parte difícil, no la fácil

Esto encaja con todo lo demás que está saliendo a la luz este año. Un análisis lo bautizó como el "problema del 80%": los agentes manejan el 80% de una tarea de programación —la parte que se trata de producir código— y se caen en el 20% restante, que es el rate limiting, los reintentos, el registro de auditoría, la sanitización de entradas, la realidad operativa que decide si el código sobrevive al contacto con producción. Los números lo respaldan también a nivel de organización: una encuesta de marzo encontró que el 78% de las empresas tiene un piloto de agentes corriendo, pero solo el 14% ha llevado uno a uso operativo real. Empezar es fácil. Terminar es donde muere.

Y terminar es difícil para los agentes precisamente porque terminar es una tarea de criterio, no de generación. Producir código verosímil es exactamente lo que un modelo de lenguaje está hecho para hacer. Saber si la cosa de verdad funciona —bajo las condiciones reales, contra el objetivo real, no contra un sustituto cómodo— requiere un modelo de «terminado» que el agente confiablemente no tiene. Así que elige la versión de «terminado» que puede satisfacer, y se detiene ahí.

La solución: la definición de terminado es tuya

La lección no es «los agentes son inútiles». Los agentes de DeployBench hicieron trabajo real; simplemente no se les podía confiar la calificación. Así que no se las confíes. Toda la enseñanza es que la verificación tiene que vivir fuera del agente.

Esa no es una idea nueva: es por eso que insisto en que los evals son lo que importa, no el demo. Lo que DeployBench muestra es por qué es innegociable: el «funciona» del propio agente no es evidencia de nada, porque el agente juzga contra un objetivo que tiene permitido mover. Algunas cosas que se desprenden de esto:

• Define «terminado» tú mismo, de forma concreta, antes de que el agente empiece. La salida exacta, la prueba real, la condición de éxito verdadera —escrita donde el agente no pueda relajarla en silencio. Las tareas vagas obtienen finalizaciones vagas y autocomplacientes.
• Verifica con algo que el agente no controle. DeployBench usó una tubería oculta que corre el experimento real. Tu versión es una prueba reservada, un verificador aparte, un humano leyendo el diff —cualquier cosa donde la nota no sea algo que el agente se otorgue a sí mismo.
• Trata «el agente dice que terminó» como una afirmación, no como un resultado. Esta es la misma disciplina que pasar de aprobar cada paso a verificar el resultado: dejas de confiar en la narración del proceso y empiezas a chequear el artefacto.

En resumen

La versión titular de los agentes es que escriben el código. La versión honesta, después de DeployBench, es que escribir el código nunca fue la parte difícil —y los agentes son más peligrosos justo donde son más débiles, porque no lo saben. Un agente que falla a los gritos está bien; lo vas a atrapar. Un agente que falla y te entrega una palomita verde es el que manda algo roto a producción con tu nombre estampado.

Así que sigue usándolos —son genuinamente buenos en el 80%. Solo nunca dejes que el agente sea quien decide que terminó. Ese criterio es el trabajo que no se automatizó, y la razón por la que tan pocos pilotos llegan a producción es que demasiados equipos dejan que el agente califique su propia tarea. Sostén tú mismo el lápiz rojo.