L’agent va dir «fet». No ho estava.

14 d’octubre, 13.48 h

A les 13.48 del 14 d’octubre de 2026, el nostre assistent de programació, Claude Code, va donar per acabada una actualització de textos de la web d’IAescola en quatre idiomes. Havia fet un escombratge amb expressions regulars, n’havia filtrat el resultat i el resultat deia «net».

No ho era. Un comprovador escrit amb l’eina unlazy, que llegeix la branca real del repositori i que, abans de donar res per bo, demostra que és capaç de detectar els textos que havien de canviar, en va trobar 139 línies pendents en 6 fitxers: quatre idiomes, les dades estructurades per a cercadors, les imatges per a xarxes i el xatbot. A les 14.16 h la xifra era 0, i el canvi encara no havia sortit a la web.

Una precisió, perquè aquest article va de no inflar xifres: d’aquestes 139 línies, 6 pertanyen a una família de textos en francès que vam afegir al comprovador després. Mesurat només amb el que buscàvem a les 13.48, en continuen sent més de 130.

Una fallada amb nom i amb dades

El que ens va passar no és una anècdota. La recerca dels dos últims anys ho mesura des de diversos angles.

• Els agents avancen per fites, no acaben. SlopCodeBench (Orlanski i altres, 2026) va posar 15 agents de programació a ampliar el seu propi codi al llarg de 36 problemes i 196 fites. Cap no va resoldre un problema de principi a fi; el millor va superar el 14,8 % de les fites.
• Demanar-los que no facin trampes no n’hi ha prou. METR, el laboratori independent que avalua models de frontera, va documentar el juny de 2025 que o3 va recórrer a dreceres indegudes (tocar els tests, llegir respostes filtrades) en 39 de 128 execucions (30,4 %) del seu banc RE-Bench. En una de les tasques, el 80 % dels intents plantejava la trampa; afegint a l’encàrrec «Please do not cheat», continuava sent el 80 %.
• El format de l’encàrrec canvia el resultat. El projecte aider va mesurar que GPT-4 Turbo deixava comentaris del tipus «la resta del codi va aquí» en 12 tasques; canviant el format d’edició, en 4.

El matís importa: l’estudi més citat sobre la «mandra» dels models (Ma i Liu, 2025) descriu el fenomen, però el seu resum no dona xifres i també hi troba una robustesa sorprenent en converses llargues. No tot el que se cita per justificar aquestes eines diu el que se li atribueix.

Qui va fer unlazy i per què

unlazy és un projecte de codi obert (llicència MIT) que Leon Lin, desenvolupador establert a Munic, va publicar a GitHub el 9 d’agost de 2026. A 14 d’octubre suma 3.928 estrelles i 298 còpies derivades; no té versions etiquetades i el seu últim canvi és del 3 de setembre.

El primer text del projecte començava així: «“Laziness” sounds like a vibe. It is not.» I posava un exemple: un agent a qui es va encarregar arreglar 80 fitxers els va donar tots 80 per fets; n’havia obert 11. L’autor no dona la font d’aquest cas i no l’hem pogut verificar.

La primera versió eren instruccions en prosa: descompondre la tasca en un arbre i donar a cada fulla tot el temps. L’endemà, la versió 2.0 va canviar d’enfocament amb un argument que resumeix el problema:

La prosa no pot obligar a complir la prosa. Un model que executa a mitges les instruccions també executarà a mitges la instrucció de no fer-ho a mitges.

Què fa exactament

unlazy converteix «està fet» en una cosa que es pot comprovar.

1. 1
   Abans de treballar, s’escriu un registre de «portes»: cadascuna és un resultat observable, amb una ordre que el comprova (CHECK) i la sortida que ha de donar (EXPECT).
2. 2
   Una porta només es compleix si l’ordre acaba sense error i la sortida coincideix. L’evidència queda lligada a una empremta criptogràfica de la definició: si algú canvia la comprovació després, l’evidència antiga deixa de valer.
3. 3
   No s’executa res sense aprovació explícita de la persona, que abans ha de llegir l’ordre.
4. 4
   Qui encarrega la feina torna a executar les comprovacions en lloc de refiar-se de l’informe de l’agent.
5. 5
   Abandonar una porta és possible, però no compta com a acabat: el sistema exigeix un traspàs explícit.
6. 6
   Opcionalment, a Claude Code, un mecanisme impedeix a l’agent tancar la sessió mentre quedin portes pendents.

La regla que més ens ha servit no és tècnica: tota comprovació que una cosa «ja no hi és» ha de demostrar primer que la sap trobar (el que el projecte anomena control positiu). El nostre escombratge de les 13.48 no la complia.

El que unlazy no arregla

Aquesta és la part que sol faltar als articles sobre eines.

El mateix autor va retirar les seves xifres

Fins al 16 d’agost, el README presentava una comparació interna de sis execucions: amb l’eina, l’esforç pujava entre 1,6 i 3,9 vegades i l’agent corregia de 4 a 10 defectes abans de lliurar. Entre el 16 i el 23 d’agost la taula va desaparèixer. El repositori n’explica el motiu: no conserva els encàrrecs, les versions dels models, les transcripcions ni el codi de càlcul, i una execució per cas no permet separar l’efecte de l’eina de la variació normal. Avui ho presenta com a història del disseny, no com a prova.

Aquella mateixa taula tenia un resultat en contra

Els informes finals fets amb l’eina contenien d’1 a 3 números erronis; els fets sense, cap. D’aquí va sortir una de les seves regles: tornar a mesurar cada xifra just abans d’informar.

Una porta mal escrita dona un verd fals

Un usuari va mostrar (incidència #13) que una comprovació com «imprimeix “ok” i espera “ok”» passa sempre. Un altre (incidència #23), que un pla pot ometre un encàrrec sencer mentre totes les seves portes passen. L’autor ho reconeix: l’eina no pot demostrar que l’ordre mesura el que diu el títol de la porta.

El comprovador també s’equivoca

Ens va passar el mateix 14 d’octubre. En verificar en producció una guia nova, el comprovador va donar dues fallades: no trobava les etiquetes d’idioma (les buscava amb majúscules exactes i la web les escriu diferent) i comptava 0 pàgines al PDF (que en té 4, però comprimides). La web estava bé; el comprovador, malament. La diferència amb l’error de les 13.48 és que aquest va fallar fent soroll: va bloquejar, ho vam investigar i ho vam corregir.

Un «net» fals no avisa. Un control que falla de més, sí.

Els nostres números

Quatre vegades en una setmana es va donar per bo una cosa que no ho era. Els dos primers casos són anteriors a la instal·lació d’unlazy (14 d’octubre, 13.28 h); els incloem perquè són la mateixa fallada: un senyal d’«acabat» que també apareix quan no s’ha acabat.

Què pot fer una empresa que ja fa servir agents

No cal instal·lar res per aplicar-ne l’essencial.

1. 1
   Definir «fet» abans d’encarregar, en resultats que es puguin comprovar, no en adjectius.
2. 2
   Exigir comprovacions que puguin fallar. Si un control no ha donat mai vermell, no sabem si funciona.
3. 3
   Provar el detector abans de creure el silenci: ensenyar-li un cas que ha de trobar.
4. 4
   Separar qui fa la feina de qui l’aprova. A IAescola, el codi l’escriu Claude Code (Anthropic), el que importa el revisa Codex (OpenAI), d’un altre proveïdor, i la decisió final és humana.
5. 5
   Tornar a mesurar les xifres de l’informe final. El mateix autor d’unlazy ho va aprendre amb els seus números.

A IAescola preparem cada formació a partir de les tasques reals del teu equip i, quan cal, construïm agents a mida, els provem amb tu i ensenyem l’equip a encarregar-los feina, a comprovar el que lliuren i a saber on no refiar-se’n. Escriu-nos i ho adaptem al teu cas.