{"id":1219,"date":"2026-11-12T06:00:00","date_gmt":"2026-11-12T05:00:00","guid":{"rendered":"https:\/\/rosmarops.com\/es\/?p=1219"},"modified":"2026-11-11T22:37:06","modified_gmt":"2026-11-11T21:37:06","slug":"agente-de-ia-he-terminado","status":"publish","type":"post","link":"https:\/\/rosmarops.com\/es\/blog\/agente-de-ia-he-terminado\/","title":{"rendered":"El trabajo de verdad empieza cuando el agente dice \u00abhe terminado\u00bb"},"content":{"rendered":"\n

Un agente de IA te dice que ha terminado. \u00bfC\u00f3mo sabes si es verdad? Lo que he aprendido construyendo UXMachine, y unas cuantas preguntas para comprobar el trabajo de tu agente aunque no seas programador.<\/em><\/p>\n\n\n\n

Si llevas unas semanas trabajando con un agente de IA, conoces la escena. Le pides algo, trabaja un rato y al final te dice, muy seguro, que ya est\u00e1. Que ha hecho los cambios, que las pruebas pasan y que todo funciona. Y t\u00fa, que tienes otras cuarenta cosas pendientes, tienes la tentaci\u00f3n de creerle.<\/p>\n\n\n\n

En el art\u00edculo anterior habl\u00e9 del loop engineering<\/em>, la idea de dejar que un agente encadene tareas sin que t\u00fa est\u00e9s delante. Y termin\u00e9 con una idea que quiero desarrollar ahora: lo dif\u00edcil no es conseguir que el agente trabaje, sino saber qu\u00e9 ha hecho. Addy Osmani, uno de los primeros en poner nombre a esta forma de trabajar, lo resume en una frase que me apunt\u00e9: incluso con un buen verificador, \u00abterminado\u00bb es una afirmaci\u00f3n, no una prueba.<\/p>\n\n\n\n

Lo que me pas\u00f3 con UXMachine<\/h2>\n\n\n\n

A finales de octubre, un agente me entreg\u00f3 un cambio en los textos del informe de UXMachine. Las pruebas autom\u00e1ticas, esos peque\u00f1os programas que comprueban que el resto sigue funcionando, estaban todas en verde. Y en su propia descripci\u00f3n del cambio, el agente avisaba de algo importante: aquello no tocaba solo los textos, tambi\u00e9n mov\u00eda la forma de medir.<\/p>\n\n\n\n

Nadie ley\u00f3 ese aviso, y el cambio se public\u00f3. Durante unas horas, al comparar dos mediciones de la misma web, algunas reglas pod\u00edan aparecer como \u00abnuevas\u00bb aunque la web no hubiera cambiado. Lo encontr\u00f3 una revisi\u00f3n posterior, unos setenta minutos despu\u00e9s. El arreglo lleg\u00f3 con una prueba nueva que falla si vuelve a pasar. Lo cont\u00e9 en una nota de UXMachine<\/a>.<\/p>\n\n\n\n

Lo que m\u00e1s me ense\u00f1\u00f3 de aquello es que el agente no ocult\u00f3 nada. El aviso estaba en su entrega. Lo que faltaba no era un agente m\u00e1s sincero, sino algo que leyera lo que dec\u00eda.<\/strong><\/p>\n\n\n\n

El bucle de trabajo, explicado sin tecnicismos<\/h2>\n\n\n\n

En esta serie separo tres bucles, siguiendo a Ichigo. El primero es el del propio agente, que llama a herramientas y lee lo que le devuelven. Este art\u00edculo va del segundo, el bucle de trabajo, y se entiende bien con una imagen de colegio.<\/p>\n\n\n\n

Si un alumno se corrige su propio examen, saca muy buena nota. Si lo corrige otra persona, la nota se parece m\u00e1s a lo que sabe. El bucle de trabajo es eso: el agente entrega algo, alguien de fuera lo comprueba, le devuelve lo que ha fallado y el agente lo vuelve a intentar.<\/p>\n\n\n\n

Ese \u00abalguien de fuera\u00bb puede ser una prueba autom\u00e1tica, una herramienta que mide el resultado o una persona. Lo importante es que no sea el propio agente. Si quien hace la tarea es tambi\u00e9n quien la da por buena, no hay bucle de trabajo: hay un alumno que se pone nota.<\/p>\n\n\n\n

Por qu\u00e9 el agente no puede corregirse solo<\/h2>\n\n\n\n

Osmani lo dice con humor: el modelo que ha escrito el c\u00f3digo es demasiado amable cuando corrige sus propios deberes. No es mala fe. El agente tiende a creer que lo que acaba de hacer est\u00e1 bien, igual que nos pasa a nosotros con un texto reci\u00e9n escrito.<\/p>\n\n\n\n

El estudio sobre 36.487 repositorios del que habl\u00e9 en el art\u00edculo anterior recoge un nombre para el fallo m\u00e1s t\u00edpico: verifier theater<\/em>, el teatro del verificador. Son comprobaciones que aprueban sin comprobar de verdad. Que en un proceso haya un paso que se llame \u00abverificar\u00bb no quiere decir que verifique nada.<\/p>\n\n\n\n

La buena noticia es que, cuando la comprobaci\u00f3n est\u00e1 bien hecha, funciona. Mitchell Hashimoto lo cuenta en el relato de c\u00f3mo ha ido incorporando la IA a su trabajo: si le das a un agente una forma de comprobar lo que ha hecho, la mayor\u00eda de las veces corrige sus propios errores y no rompe lo que ya funcionaba.<\/p>\n\n\n\n

Cinco preguntas para saber si una comprobaci\u00f3n sirve<\/h2>\n\n\n\n

Ichigo resume en su hilo lo que separa una comprobaci\u00f3n \u00fatil de una decorativa. Lo he convertido en preguntas que puedes hacerte sobre tu propia forma de trabajar:<\/p>\n\n\n\n

    \n\n
  1. \u00bfPuede el agente tocar la comprobaci\u00f3n?<\/strong> Si puede cambiar la prueba o el criterio, antes o despu\u00e9s acabar\u00e1 aprob\u00e1ndose. La comprobaci\u00f3n tiene que estar fuera de su alcance.<\/li>\n\n\n
  2. Cuando falla, \u00bfdice qu\u00e9 ha fallado?<\/strong> \u00abLas pruebas no pasan\u00bb no sirve de mucho. \u00abEsperaba esto, ha pasado esto otro, y ha sido aqu\u00ed\u00bb permite corregir.<\/li>\n\n\n
  3. \u00bfQu\u00e9 pasa si se atasca?<\/strong> Adem\u00e1s de \u00abbien\u00bb y \u00abmal\u00bb, hace falta una tercera salida: \u00abno avanza\u00bb. Si despu\u00e9s de varios intentos no cambia nada, seguir intent\u00e1ndolo solo gasta.<\/li>\n\n\n
  4. \u00bfHay un l\u00edmite que se cumpla solo?<\/strong> Un tope de intentos o de gasto que la herramienta aplica, no uno que le pides por favor. En el estudio, solo 101 de los 256 repositorios revisados ten\u00edan alguno.<\/li>\n\n\n
  5. \u00bfQui\u00e9n dice la \u00faltima palabra?<\/strong> Un resultado en verde sigue siendo una propuesta hasta que una persona lo acepta.<\/li>\n\n<\/ol>\n\n\n\n

    Lo que has visto y lo que has supuesto<\/h2>\n\n\n\n

    La distinci\u00f3n que m\u00e1s me ha servido es esta: \u00bfesto lo he visto o lo he supuesto? \u00abLa p\u00e1gina carga\u00bb es algo que has visto. \u00abLa p\u00e1gina funciona\u00bb casi siempre es algo que supones.<\/p>\n\n\n\n

    Un agente mezcla las dos cosas sin avisar. Lo comprob\u00e9 el 1 de noviembre con cinco agentes que usaban UXMachine para medir una web. Los cinco midieron bien, y tres contaron mal el resultado: dijeron que no hab\u00eda nada importante y no mencionaron lo que no se hab\u00eda podido comprobar. Es una prueba de un d\u00eda y con cinco agentes, pero ilustra bien el problema.<\/p>\n\n\n\n

    Por eso en UXMachine intento separar las dos cosas. Cada observaci\u00f3n dice d\u00f3nde se vio y qu\u00e9 se midi\u00f3. Lo que sabe que no pudo comprobar, lo dice, en lugar de callarlo. Y que algo deje de aparecer no quiere decir que est\u00e9 resuelto: si en una de las dos mediciones no se pudo comprobar, UXMachine dice que no son comparables, no que el problema ha desaparecido. Lo expliqu\u00e9 en otra nota<\/a>.<\/p>\n\n\n\n

    Tiene un l\u00edmite que no quiero esconder: una herramienta solo puede avisar de lo que sabe que no ha comprobado. Lo que no detecta, no lo puede avisar.<\/p>\n\n\n\n

    Con las pruebas autom\u00e1ticas pasa lo mismo. A finales de septiembre, las pruebas de una parte de UXMachine pasaban en verde, pero se ejecutaban con unas herramientas que la versi\u00f3n publicada no lleva. La primera vez que alguien la hubiera usado de verdad, habr\u00eda fallado, y ninguna prueba pod\u00eda verlo. Lo vimos antes de publicar. La soluci\u00f3n fue que el programa se niegue a arrancar si encuentra algo que no sabe comprobar, en vez de dejarlo pasar en silencio. Una prueba en verde dice que algo funciona donde se ha probado, no donde se va a usar.<\/strong><\/p>\n\n\n\n

    Lo que cuesta un resultado fiable<\/h2>\n\n\n\n

    Un resultado en el que puedes confiar cuesta m\u00e1s que uno que solo parece terminado. Cuesta tiempo de comprobaci\u00f3n, vueltas de correcci\u00f3n y, a veces, empezar otra vez.<\/p>\n\n\n\n

    Ese coste casi nunca se mira. En el estudio, solo 10 de los 256 repositorios revisados apuntaban lo que costaban sus bucles. Sin ese dato es f\u00e1cil creer que el agente sale gratis, y que cuantas m\u00e1s vueltas d\u00e9, mejor.<\/p>\n\n\n\n

    Antes de dar algo por bueno<\/h2>\n\n\n\n

    No hace falta ser programador para hacerse estas cuatro preguntas cada vez que un agente dice que ha terminado:<\/p>\n\n\n\n