{"id":72,"date":"2026-11-11T10:34:11","date_gmt":"2026-11-11T09:34:11","guid":{"rendered":"https:\/\/rosmarops.com\/ca\/?p=72"},"modified":"2026-11-11T10:34:12","modified_gmt":"2026-11-11T09:34:12","slug":"agents-dia-errors-repetits","status":"publish","type":"post","link":"https:\/\/rosmarops.com\/ca\/blog\/agents-dia-errors-repetits\/","title":{"rendered":"La IA no apr\u00e8n dels seus errors. El teu sistema n’hauria d’aprendre."},"content":{"rendered":"\n

El teu agent no recorda que ahir es va equivocar. Si vols que no torni a passar, qui ha de canviar \u00e9s el sistema en qu\u00e8 treballa. Com convertir un error repetit en un canvi que es quedi, i per qu\u00e8 escriure-ho en un fitxer no sempre n’hi ha prou.<\/em><\/p>\n\n\n\n

Hi ha una sensaci\u00f3 que coneix qualsevol que treballi amb agents d’IA. Li corregeixes un error, et dona les gr\u00e0cies, l’arregla. L’endem\u00e0, en una altra sessi\u00f3, torna a cometre exactament el mateix. I tu li tornes a explicar, amb una mica menys de paci\u00e8ncia que la primera vegada.<\/p>\n\n\n\n

No \u00e9s mala fe ni falta d’intel\u00b7lig\u00e8ncia. \u00c9s que no se’n recorda. Cada conversa comen\u00e7a gaireb\u00e9 de zero, i el que tu vas aprendre ahir no ho va aprendre ell. Si vols que l’error no torni, la mem\u00f2ria ha de ser fora de l’agent: en el sistema en qu\u00e8 treballa.<\/p>\n\n\n\n

A UXMachine ho vaig aprendre a principis de setembre. L’\u00fanica comprovaci\u00f3 obligat\u00f2ria abans d’ajuntar un canvi era que el codi estigu\u00e9s ben escrit, sense errors de sintaxi. El 2 de setembre, les proves van fallar a les deu branques en qu\u00e8 treballaven els agents aquell dia, i no va bloquejar res, perqu\u00e8 ning\u00fa no havia dit que fallar les proves imped\u00eds ajuntar. Es van canviar dues coses. Ara un canvi nom\u00e9s entra amb totes les proves en verd, comprovades sobre la versi\u00f3 real. I cada control ha de demostrar, amb un error fet expressament, que de deb\u00f2 es posa en vermell quan toca.<\/p>\n\n\n\n

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

En aquesta s\u00e8rie separo tres bucles. El de l’agent, que dura segons: crida una eina, llegeix el que li torna i continua. El de treball, del qual vaig parlar a l’article anterior: alg\u00fa de fora comprova el resultat i l’hi torna si falla. I el del sistema, que dura dies o setmanes: quan un error es repeteix, es converteix en un canvi permanent.<\/p>\n\n\n\n

Una manera senzilla de veure-ho: el bucle de treball \u00e9s corregir l’examen; el bucle del sistema \u00e9s canviar com es prepara el seg\u00fcent. El primer arregla el que l’agent acaba de fer. El segon arregla el que fa que s’equivoqui. \u00c9s l’\u00fanic dels tres que aconsegueix que la setmana vinent sigui m\u00e9s barata que aquesta.<\/strong><\/p>\n\n\n\n

La idea de Hashimoto: que no torni a passar<\/h2>\n\n\n\n

Mitchell Hashimoto ha posat nom a aquest costum: harness engineering<\/em>, que podr\u00edem traduir com l’enginyeria de l’arn\u00e8s. Cada vegada que un agent comet un error, dediques una estona a dissenyar una soluci\u00f3 perqu\u00e8 no el torni a cometre mai m\u00e9s.<\/p>\n\n\n\n

Explica dues maneres de fer-ho:<\/p>\n\n\n\n

    \n\n
  1. Escriure-ho.<\/strong> Afegeix una l\u00ednia al fitxer d’instruccions que l’agent llegeix en comen\u00e7ar cada sessi\u00f3, l’AGENTS.md. En un dels seus, diu, cada l\u00ednia surt d’un mal comportament de l’agent, i gaireb\u00e9 tots van desapar\u00e8ixer.<\/li>\n\n\n
  2. Donar-li una eina.<\/strong> Per exemple, un petit programa que fa captures de pantalla o que passa nom\u00e9s les proves que importen. I despr\u00e9s l’anota a l’AGENTS.md perqu\u00e8 l’agent s\u00e0piga que existeix.<\/li>\n\n<\/ol>\n\n\n\n

    Una regla escrita \u00e9s un desig<\/h2>\n\n\n\n

    Aqu\u00ed conv\u00e9 no ser massa optimista. Escriure una l\u00ednia en un fitxer d’instruccions \u00e9s el m\u00e9s f\u00e0cil, i no sempre el m\u00e9s efica\u00e7.<\/p>\n\n\n\n

    Un estudi publicat al febrer, Evaluating AGENTS.md<\/em>, ho va mesurar amb diversos agents i models. Els fitxers d’instruccions, en general, no van augmentar les tasques resoltes, i van encarir cada tasca m\u00e9s d’un 20 % de mitjana. Els agents s\u00ed que seguien les instruccions; el que no ajudava eren les descripcions generals del projecte. La conclusi\u00f3 dels autors \u00e9s prudent: aquests fitxers serveixen per deixar per escrit el que el teu projecte fa diferent del que \u00e9s habitual, i tota la resta conv\u00e9 mesurar-la abans de donar-la per bona.<\/p>\n\n\n\n

    Ichigo ho resumeix amb una imatge que m’agrada molt. \u00abNo toquis les migracions\u00bb, escrit en un fitxer de text, \u00e9s un desig: l’agent ho llegir\u00e0 i gaireb\u00e9 sempre ho complir\u00e0. Una regla que li treu el perm\u00eds de tocar-les \u00e9s un mur: ho complir\u00e0 encara que se li oblidi. Per aix\u00f2 proposa aquest ordre quan alguna cosa falla:<\/p>\n\n\n\n

      \n\n
    1. Primer, l’estructura:<\/strong> que l’error no es pugui cometre.<\/li>\n\n\n
    2. Despr\u00e9s, una comprovaci\u00f3 autom\u00e0tica<\/strong> que el detecti sempre.<\/li>\n\n\n
    3. Text a les instruccions,<\/strong> nom\u00e9s on de deb\u00f2 cal criteri.<\/li>\n\n\n
    4. I una persona que revisa,<\/strong> al final.<\/li>\n\n<\/ol>\n\n\n\n

      La ra\u00f3 \u00e9s gaireb\u00e9 comptable. Una l\u00ednia a les instruccions es paga a cada sessi\u00f3, i l’agent la pot passar per alt. Una comprovaci\u00f3 autom\u00e0tica, un cop feta, no costa res.<\/p>\n\n\n\n

      Arreglar-ho on es produeix, no on es veu<\/h2>\n\n\n\n

      Hi ha un error d’enfocament molt habitual: arreglar l’error just on s’ha vist. A la Guia AI-First<\/a> ho vaig escriure aix\u00ed: si una cosa torna despr\u00e9s d’arreglar-la, \u00e9s que es va arreglar on es va observar, no on es produeix. I \u00abun error arreglat on es va observar est\u00e0 amagat, no arreglat\u00bb.<\/p>\n\n\n\n

      La guia proposa una pregunta senzilla abans de donar una cosa per tancada: si aix\u00f2 mateix aparegu\u00e9s en un altre lloc, ho aturaria alguna cosa? Si la resposta \u00e9s no, encara no est\u00e0 acabat.<\/p>\n\n\n\n

      I hi ha un contrap\u00e8s que tamb\u00e9 \u00e9s a la guia: un control que mai no s’ha posat en vermell, o no est\u00e0 provat, o sobra. Per aix\u00f2 cada comprovaci\u00f3 nova hauria de demostrar, almenys una vegada, que detecta l’error per al qual existeix.<\/p>\n\n\n\n

      Dels prompts a una manera de treballar<\/h2>\n\n\n\n

      Al principi pensava que el truc era demanar millor. Ara crec que \u00e9s decidir abans.<\/p>\n\n\n\n

      A la guia, cada enc\u00e0rrec diu \u00abqu\u00e8 es fa, qu\u00e8 no es toca, com es comprova i quan s’atura\u00bb. I abans de comen\u00e7ar, una l\u00ednia: \u00abqu\u00e8 hauria de passar perqu\u00e8 ho deix\u00e9s?\u00bb. La resta en surt:<\/p>\n\n\n\n