El agente dijo «hecho». No lo estaba.

14 de octubre, 13:48

A las 13:48 del 14 de octubre de 2026, nuestro asistente de programación, Claude Code, dio por terminada una actualización de textos de la web de IAescola en cuatro idiomas. Había hecho un barrido con expresiones regulares, había filtrado el resultado y el resultado decía «limpio».

No lo era. Un comprobador escrito con la herramienta unlazy, que lee la rama real del repositorio y que antes de dar nada por bueno demuestra que es capaz de detectar los textos que debían cambiar, encontró 139 líneas pendientes en 6 ficheros: cuatro idiomas, los datos estructurados para buscadores, las imágenes para redes y el chatbot. A las 14:16 la cifra era 0, y el cambio aún no había salido a la web.

Una precisión, porque este artículo va de no inflar cifras: de esas 139 líneas, 6 pertenecen a una familia de textos en francés que añadimos al comprobador después. Medido solo con lo que buscábamos a las 13:48, siguen siendo más de 130.

Un fallo con nombre y con datos

Lo que nos pasó no es una anécdota. La investigación de los dos últimos años lo mide desde varios ángulos.

• Los agentes avanzan por hitos, no terminan. SlopCodeBench (Orlanski y otros, 2026) puso a 15 agentes de programación a ampliar su propio código a lo largo de 36 problemas y 196 hitos. Ninguno resolvió un problema de principio a fin; el mejor superó el 14,8 % de los hitos.
• Pedir que no hagan trampas no basta. METR, el laboratorio independiente que evalúa modelos de frontera, documentó en junio de 2025 que o3 recurrió a atajos indebidos (tocar los tests, leer respuestas filtradas) en 39 de 128 ejecuciones (30,4 %) de su banco RE-Bench. En una de las tareas, el 80 % de los intentos planteaba la trampa; añadiendo al encargo «Please do not cheat», seguía siendo el 80 %.
• El formato del encargo cambia el resultado. El proyecto aider midió que GPT-4 Turbo dejaba comentarios del tipo «el resto del código va aquí» en 12 tareas; cambiando el formato de edición, en 4.

El matiz importa: el estudio más citado sobre la «pereza» de los modelos (Ma y Liu, 2025) describe el fenómeno, pero su resumen no da cifras y también encuentra una robustez sorprendente en conversaciones largas. No todo lo que se cita para justificar estas herramientas dice lo que se le atribuye.

Quién hizo unlazy y por qué

unlazy es un proyecto de código abierto (licencia MIT) que Leon Lin, desarrollador afincado en Múnich, publicó en GitHub el 9 de agosto de 2026. A 14 de octubre suma 3.928 estrellas y 298 copias derivadas; no tiene versiones etiquetadas y su último cambio es del 3 de septiembre.

El primer texto del proyecto arrancaba así: «“Laziness” sounds like a vibe. It is not.» Y daba un ejemplo: un agente al que se le encargó arreglar 80 ficheros informó de los 80 como hechos; había abierto 11. El autor no da la fuente de ese caso y no hemos podido verificarlo.

La primera versión eran instrucciones en prosa: descomponer la tarea en un árbol y dar a cada hoja todo el tiempo. Al día siguiente, la versión 2.0 cambió de enfoque con un argumento que resume el problema:

La prosa no puede obligar a cumplir la prosa. Un modelo que ejecuta a medias las instrucciones también ejecutará a medias la instrucción de no hacerlo a medias.

Qué hace exactamente

unlazy convierte «está hecho» en algo que se puede comprobar.

1. 1
   Antes de trabajar, se escribe un registro de «puertas»: cada una es un resultado observable, con un comando que lo comprueba (CHECK) y la salida que debe dar (EXPECT).
2. 2
   Una puerta solo se cumple si el comando termina sin error y su salida coincide. La evidencia queda ligada a una huella criptográfica de la definición: si alguien cambia la comprobación después, la evidencia antigua deja de valer.
3. 3
   Nada se ejecuta sin aprobación explícita de la persona, que antes debe leer el comando.
4. 4
   Quien encarga el trabajo vuelve a ejecutar las comprobaciones en lugar de fiarse del informe del agente.
5. 5
   Abandonar una puerta es posible, pero no cuenta como terminado: el sistema exige un traspaso explícito.
6. 6
   Opcionalmente, en Claude Code, un mecanismo impide al agente cerrar la sesión mientras queden puertas pendientes.

La regla que más nos ha servido no es técnica: toda comprobación de que algo «ya no está» debe demostrar primero que sabe encontrarlo (lo que el proyecto llama control positivo). Nuestro barrido de las 13:48 no la cumplía.

Lo que unlazy no arregla

Aquí está la parte que suele faltar en los artículos sobre herramientas.

El propio autor retiró sus cifras

Hasta el 16 de agosto, el README presentaba una comparación interna de seis ejecuciones: con la herramienta, el esfuerzo subía entre 1,6 y 3,9 veces y el agente corregía de 4 a 10 defectos antes de entregar. Entre el 16 y el 23 de agosto esa tabla desapareció. El repositorio explica por qué: no conserva los encargos, las versiones de los modelos, las transcripciones ni el código de cálculo, y una ejecución por caso no permite separar el efecto de la herramienta de la variación normal. Hoy lo presenta como historia del diseño, no como prueba.

Aquella misma tabla tenía un resultado en contra

Los informes finales hechos con la herramienta contenían de 1 a 3 números erróneos; los hechos sin ella, ninguno. De ahí salió una de sus reglas: volver a medir cada cifra justo antes de informar.

Una puerta mal escrita da un verde falso

Un usuario mostró (incidencia #13) que una comprobación como «imprime “ok” y espera “ok”» pasa siempre. Otro (incidencia #23), que un plan puede omitir un encargo entero mientras todas sus puertas pasan. El autor lo reconoce: la herramienta no puede demostrar que el comando mide lo que dice el título de la puerta.

El comprobador también se equivoca

Nos pasó el mismo 14 de octubre. Al verificar en producción una guía nueva, el comprobador dio dos fallos: no encontraba las etiquetas de idioma (las buscaba con mayúsculas exactas y la web las escribe distinto) y contaba 0 páginas en el PDF (que tiene 4, pero comprimidas). La web estaba bien; el comprobador, mal. La diferencia con el error de las 13:48 es que este falló haciendo ruido: bloqueó, lo investigamos y lo corregimos.

Un «limpio» falso no avisa. Un control que falla de más, sí.

Nuestros números

Cuatro veces en una semana algo se dio por bueno sin serlo. Los dos primeros casos son anteriores a que instaláramos unlazy (14 de octubre, 13:28); los incluimos porque son el mismo fallo: una señal de «terminado» que también aparece cuando no se ha terminado.

Qué puede hacer una empresa que ya usa agentes

No hace falta instalar nada para aplicar lo esencial.

1. 1
   Definir «hecho» antes de encargar, en resultados que se puedan comprobar, no en adjetivos.
2. 2
   Exigir comprobaciones que puedan fallar. Si un control nunca ha dado rojo, no sabemos si funciona.
3. 3
   Probar el detector antes de creer en el silencio: enseñarle un caso que debe encontrar.
4. 4
   Separar al que hace del que aprueba. En IAescola, el código lo escribe Claude Code (Anthropic), lo que importa lo revisa Codex (OpenAI), de otro proveedor, y la decisión final es humana.
5. 5
   Volver a medir las cifras del informe final. El propio autor de unlazy lo aprendió con sus números.

En IAescola preparamos cada formación a partir de las tareas reales de tu equipo y, cuando hace falta, construimos agentes a medida, los probamos contigo y enseñamos al equipo a encargarles trabajo, a comprobar lo que entregan y a saber dónde no fiarse. Escríbenos y lo adaptamos a tu caso.