Construeixo amb agents d’IA una eina per fer servir els agents d’IA amb més cura. Aquesta setmana els seus errors van ser els mateixos que RosmarOps busca en els teus. Així hem convertit cadascun en una peça permanent del sistema.
RosmarOps existeix perquè vegis què poden fer els teus agents d’IA sense preguntar-te. I el construeixo, gairebé sencer, amb agents d’IA.
Aquesta setmana aquesta paradoxa va fer una segona volta. Vaig publicar dues versions en dos dies, la 0.10.1 i la 0.10.2, per arreglar errors que cap prova havia vist. Els va trobar el meu propi ordinador, que té 48 projectes i gairebé tots els agents que RosmarOps coneix. En mirar-los de prop vaig veure que els errors de RosmarOps eren els mateixos que RosmarOps busca en els teus agents: llistes que deixen de coincidir, permisos que ningú sap qui va decidir, errors que callen i un «he acabat» que ningú comprova des de fora.
Arreglar-los era el fàcil. El que vull explicar és què fem perquè no tornin.
Harness engineering, en una frase
Mitchell Hashimoto va posar nom a un costum: cada vegada que un agent comet un error, dediques temps a construir alguna cosa perquè no el pugui tornar a cometre. Al conjunt d’aquestes peces al voltant de l’agent l’anomena harness, l’arnès.
Ichigo hi afegeix un ordre que he adoptat tal qual. Quan alguna cosa falla, la solució es busca en aquest ordre:
- Estructura: que l’error sigui impossible de cometre.
- Una comprovació automàtica que el cacï sempre.
- Text a les instruccions, només on de debò cal criteri.
- Una persona que revisa, al final.
Una línia a les instruccions és un desig: l’agent la llegirà i gairebé sempre la complirà. Una prova automàtica és un mur: es compleix encara que se li oblidi.
Sis dimonis i la seva peça
1. El text que no hi cabia.
- Què va passar: quan Codex té permís per fer servir moltes aplicacions de l’escriptori, l’avís les enumera totes. Al meu ordinador, el títol superava els 200 caràcters que admet l’espai, i el programa descartava la revisió sencera.
- La peça (comprovació): una prova que llegeix del mateix format cada límit de llargada i de quantitat, i comprova que el programa els respecta encara que les dades els superin. Avui cobreix les llistes i els textos de l’espai. A la propera versió, els límits sortiran directament del format, perquè cap camp nou quedi fora.
2. Les llistes que van deixar de coincidir.
- Què va passar: el programa sabia dir «aquest agent el detecto, però no el puc puntuar» per a l’app d’Antigravity, però aquest motiu no era a la llista que accepta l’informe. Al meu ordinador, l’informe no s’escrivia. Va passar tres vegades en una setmana, amb tres llistes diferents.
- La peça (comprovació): una prova de paritat que compara 15 llistes del codi amb les del format i falla si una es queda enrere. Ja és a la 0.10.2.
3. Les proves que miraven un altre camí.
- Què va passar: les proves de la nota de fàbrica muntaven el mapa d’agents a mà, per un camí diferent del que fa servir el programa de debò. Estaven en verd perquè provaven una altra cosa. Així es va escapar la regla que faltava als ajustos de Cline, que deixava la meva revisió sense nota.
- La peça (estructura): una sola manera de muntar el mapa, la mateixa per a les proves i per al programa, sobre un ordinador de prova complet amb tots els agents i rutes de Windows. Va arribar amb la 0.10.3.
4. L’«he acabat» sense comprovar.
- Què va passar: tot estava en verd i al meu ordinador no funcionava. Una prova en verd diu que una cosa funciona on s’ha provat, no on es farà servir.
- La peça (comprovació i persona):
- La 0.10.2 no es va publicar fins que la vaig passar al meu ordinador i va sortir amb nota i al meu espai.
- Abans de publicar-la la va revisar un agent que no havia escrit aquell codi, i la va aprovar amb cinc condicions que s’havien de complir.
- El pas següent és que la màquina faci aquesta prova sola: un Windows net que, abans de cada llançament, munta el que deixen els agents en instal·lar-se, executa la versió nova i comprova que acaba, que hi ha nota i que l’enviament a l’espai funciona. Si falla, la versió no surt.
5. El silenci.
- Què va passar: durant dies, el programa llençava revisions i només ho apuntava en una finestra que es tancava sola.
- La peça (comprovació): cap error es queda només al registre. O apareix a l’informe, o la revisió s’atura i ho diu. La 0.10.2 ja apunta al registre d’enviaments cada revisió que no s’ha pogut enviar, i per què. La regla completa, amb una prova que busca al codi errors que només es registren, forma part del pla.
6. Les presses amb bona intenció.
- Què va passar: un agent va afegir un canvi al format de dades sense demanar permís. Tenia raó en el fons, i tot i així es va saltar una regla. Jo mateix vaig moure una hora al servidor i vaig deixar el meu espai llegint dades del dia anterior.
- La peça (instrucció i persona): qualsevol canvi de format s’atura i espera la meva signatura. Avui és la peça més feble, perquè és una instrucció. El pas següent és convertir-la en comprovació.
L’arnès complet: cinc fases
Una revisió d’enginyeria feta per un agent que no havia escrit el codi, comparant el projecte amb les pràctiques de referència de la indústria, va deixar el pla en cinc fases. Cadascuna tanca una classe d’error, no un error solt:
- Un sol camí. Les proves munten el mapa igual que el programa real, sobre l’ordinador complet. És la 0.10.3.
- Una versió trencada no es publica. La prova a Windows abans de cada llançament, i un procediment per retirar una versió si calgués.
- Un registre únic d’agents. Avui, afegir un agent toca uns 18 llocs en 12 fitxers. Amb el registre, l’agent número 15 no podrà trencar els altres 14.
- Robustesa davant d’ordinadors reals. Fitxers mal escrits, rutes llarguíssimes, codificacions estranyes. El pitjor que pot passar és que alguna cosa surti com a «no llegit», mai com a net.
- Procés i mètriques. Cada canvi amb la seva revisió independent, cada versió amb el que inclou, i una mesura de quantes versions cal retirar i quant es triga a arreglar-les.
Quan hi siguin les cinc, una altra revisió independent auditarà el codi sencer.
El que me n’emporto
A la meva guia AI-First ho vaig escriure així: un error arreglat on s’observa està amagat, no arreglat. Aquesta setmana ho he comprovat al meu propi producte. Cada error d’un agent era una pregunta sobre el sistema on treballa: si demà torna a passar en un altre lloc, alguna cosa l’atura?
La feina no és aconseguir un agent que no s’equivoqui. És construir un arnès on els seus errors no et puguin arribar dues vegades.
Si fas servir RosmarOps
Actualitza a la 0.10.3. Si el teu espai feia dies que no rebia revisions, o et mostrava xifres diferents de les del teu informe, passa el programa una vegada i s’hauria de posar al dia. La teva nota pot canviar, perquè ara veu coses que abans se li escapaven.
Fonts: Mitchell Hashimoto, «My AI Adoption Journey» (5 de febrer de 2026); fil d’Ichigo a X (5 de novembre de 2026); Albert Garcia Pujadas, Guia AI-First (en castellà); notes de les versions 0.10.1, 0.10.2 i 0.10.3 al repositori de RosmarOps.
Escrit amb l’ajuda d’assistents d’IA. L’experiència, els errors i la decisió de publicar són meus.