{"id":1221,"date":"2026-11-11T10:33:48","date_gmt":"2026-11-11T09:33:48","guid":{"rendered":"https:\/\/rosmarops.com\/es\/?p=1221"},"modified":"2026-11-11T10:33:49","modified_gmt":"2026-11-11T09:33:49","slug":"agentes-de-ia-errores-repetidos","status":"publish","type":"post","link":"https:\/\/rosmarops.com\/es\/blog\/agentes-de-ia-errores-repetidos\/","title":{"rendered":"La IA no aprende de sus errores. Tu sistema deber\u00eda hacerlo."},"content":{"rendered":"\n

Tu agente no recuerda que ayer se equivoc\u00f3. Si quieres que no vuelva a pasar, quien tiene que cambiar es el sistema en el que trabaja. C\u00f3mo convertir un error repetido en un cambio que se quede, y por qu\u00e9 escribirlo en un fichero no siempre basta.<\/em><\/p>\n\n\n\n

Hay una sensaci\u00f3n que conoce cualquiera que trabaje con agentes de IA. Le corriges un error, te da las gracias, lo arregla. Al d\u00eda siguiente, en otra sesi\u00f3n, vuelve a cometer exactamente el mismo. Y t\u00fa vuelves a explic\u00e1rselo, con un poco menos de paciencia que la primera vez.<\/p>\n\n\n\n

No es mala fe ni falta de inteligencia. Es que no se acuerda. Cada conversaci\u00f3n empieza casi de cero, y lo que t\u00fa aprendiste ayer no lo aprendi\u00f3 \u00e9l. Si quieres que el error no vuelva, la memoria tiene que estar fuera del agente: en el sistema en el que trabaja.<\/p>\n\n\n\n

En UXMachine aprend\u00ed esto a principios de septiembre. La \u00fanica comprobaci\u00f3n obligatoria antes de juntar un cambio era que el c\u00f3digo estuviera bien escrito, sin errores de sintaxis. El 2 de septiembre, las pruebas fallaron en las diez ramas en las que trabajaban los agentes ese d\u00eda, y no bloque\u00f3 nada, porque nadie hab\u00eda dicho que fallar las pruebas impidiera juntar. Se cambiaron dos cosas. Ahora un cambio solo entra con todas las pruebas en verde, comprobadas sobre la versi\u00f3n real. Y cada control tiene que demostrar, con un fallo hecho a prop\u00f3sito, que de verdad se pone en rojo cuando debe.<\/p>\n\n\n\n

El tercer bucle<\/h2>\n\n\n\n

En esta serie separo tres bucles. El del agente, que dura segundos: llama a una herramienta, lee lo que le devuelve y sigue. El de trabajo, del que habl\u00e9 en el art\u00edculo anterior: alguien de fuera comprueba el resultado y se lo devuelve si falla. Y el del sistema, que dura d\u00edas o semanas: cuando un fallo se repite, se convierte en un cambio permanente.<\/p>\n\n\n\n

Una forma sencilla de verlo: el bucle de trabajo es corregir el examen; el bucle del sistema es cambiar c\u00f3mo se prepara el siguiente. El primero arregla lo que el agente acaba de hacer. El segundo arregla lo que hace que se equivoque. Es el \u00fanico de los tres que consigue que la semana que viene sea m\u00e1s barata que esta.<\/strong><\/p>\n\n\n\n

La idea de Hashimoto: que no vuelva a pasar<\/h2>\n\n\n\n

Mitchell Hashimoto le ha puesto nombre a esta costumbre: harness engineering<\/em>, que podr\u00edamos traducir como la ingenier\u00eda del arn\u00e9s. Cada vez que un agente comete un error, dedicas un rato a dise\u00f1ar una soluci\u00f3n para que no lo vuelva a cometer nunca.<\/p>\n\n\n\n

Cuenta dos maneras de hacerlo:<\/p>\n\n\n\n

    \n\n
  1. Escribirlo.<\/strong> A\u00f1ade una l\u00ednea al fichero de instrucciones que el agente lee al empezar cada sesi\u00f3n, el AGENTS.md. En uno de los suyos, dice, cada l\u00ednea sale de un mal comportamiento del agente, y casi todos desaparecieron.<\/li>\n\n\n
  2. Darle una herramienta.<\/strong> Por ejemplo, un peque\u00f1o programa que hace capturas de pantalla o que pasa solo las pruebas que importan. Y despu\u00e9s lo anota en el AGENTS.md para que el agente sepa que existe.<\/li>\n\n<\/ol>\n\n\n\n

    Una regla escrita es un deseo<\/h2>\n\n\n\n

    Aqu\u00ed conviene no ser demasiado optimista. Escribir una l\u00ednea en un fichero de instrucciones es lo m\u00e1s f\u00e1cil, y no siempre lo m\u00e1s eficaz.<\/p>\n\n\n\n

    Un estudio publicado en febrero, Evaluating AGENTS.md<\/em>, lo midi\u00f3 con varios agentes y modelos. Los ficheros de instrucciones, en general, no aumentaron las tareas resueltas, y encarecieron cada tarea m\u00e1s de un 20 % de media. Los agentes s\u00ed segu\u00edan las instrucciones; lo que no ayudaba eran las descripciones generales del proyecto. La conclusi\u00f3n de los autores es prudente: esos ficheros sirven para dejar por escrito lo que tu proyecto hace distinto de lo habitual, y todo lo dem\u00e1s conviene medirlo antes de darlo por bueno.<\/p>\n\n\n\n

    Ichigo lo resume con una imagen que me gusta mucho. \u00abNo toques las migraciones\u00bb, escrito en un fichero de texto, es un deseo: el agente lo leer\u00e1 y casi siempre lo cumplir\u00e1. Una regla que le quita el permiso de tocarlas es un muro: lo cumplir\u00e1 aunque se le olvide. Por eso propone este orden cuando algo falla:<\/p>\n\n\n\n

      \n\n
    1. Primero, la estructura:<\/strong> que el error no se pueda cometer.<\/li>\n\n\n
    2. Despu\u00e9s, una comprobaci\u00f3n autom\u00e1tica<\/strong> que lo detecte siempre.<\/li>\n\n\n
    3. Texto en las instrucciones,<\/strong> solo donde de verdad hace falta criterio.<\/li>\n\n\n
    4. Y una persona que revisa,<\/strong> al final.<\/li>\n\n<\/ol>\n\n\n\n

      La raz\u00f3n es casi contable. Una l\u00ednea en las instrucciones se paga en cada sesi\u00f3n, y el agente puede pasarla por alto. Una comprobaci\u00f3n autom\u00e1tica, una vez hecha, no cuesta nada.<\/p>\n\n\n\n

      Arreglarlo donde se produce, no donde se ve<\/h2>\n\n\n\n

      Hay un error de enfoque muy habitual: arreglar el fallo justo donde se ha visto. En la Gu\u00eda AI-First<\/a> lo escrib\u00ed as\u00ed: si algo vuelve despu\u00e9s de arreglarlo, es que se arregl\u00f3 donde se observ\u00f3, no donde se produce. Y \u00abun fallo arreglado donde se observ\u00f3 est\u00e1 escondido, no arreglado\u00bb.<\/p>\n\n\n\n

      La gu\u00eda propone una pregunta sencilla antes de dar algo por cerrado: si esto mismo apareciera en otro sitio, \u00bflo parar\u00eda algo? Si la respuesta es no, todav\u00eda no est\u00e1 terminado.<\/p>\n\n\n\n

      Y hay un contrapeso que tambi\u00e9n est\u00e1 en la gu\u00eda: un control que nunca se ha puesto en rojo, o no est\u00e1 probado, o sobra. Por eso cada comprobaci\u00f3n nueva deber\u00eda demostrar, al menos una vez, que detecta el fallo para el que existe.<\/p>\n\n\n\n

      De los prompts a una forma de trabajar<\/h2>\n\n\n\n

      Al principio pensaba que el truco estaba en pedir mejor. Ahora creo que est\u00e1 en decidir antes.<\/p>\n\n\n\n

      En la gu\u00eda, cada encargo dice \u00abqu\u00e9 se hace, qu\u00e9 no se toca, c\u00f3mo se comprueba y cu\u00e1ndo se para\u00bb. Y antes de empezar, una l\u00ednea: \u00ab\u00bfqu\u00e9 tendr\u00eda que pasar para que lo dejara?\u00bb. Lo dem\u00e1s sale de ah\u00ed:<\/p>\n\n\n\n