Dins del bucle: com funciona un agent d'IA

Què ens diu la filtració del codi de Claude Code sobre construir agents d'IA que funcionen en producció
01.04.2026 — Liquid Team — 7 min read

El 31 de març, algú va descobrir que el codi font complet de Claude Code era allà, al registre de npm, esperant que qualsevol el mirés. No va caldre cap exploit: algú es va oblidar d'afegir *.map al .npmignore, i els sourcemaps del bundle incloïen el codi original sense tocar. 785KB de TypeScript. System prompts, feature flags internes, noms en clau de models no anunciats, l'arquitectura sencera d'un dels agents de codi més usats del moment. Tot a la vista.

El que fa interessant la filtració no són els xafarderies (que també), sinó el que revela sobre com es construeix un agent que funciona de debò. Perquè Claude Code no és un wrapper bonic sobre una API. És un sistema amb més de quaranta eines, orquestració multi-agent, memòria persistent entre sessions, i diferents modes d'operació segons el context. Val la pena obrir el capó i mirar-hi.

El model no actua. El bucle sí.

Un model de llenguatge fa una cosa: donat un input, genera text. És útil, de vegades sorprenentment útil, però té un límit que no es pot esquivar amb més paràmetres: tot el que sap fer cap en una sola resposta. Si la tasca és executar codi, llegir l'error, corregir, tornar a executar i verificar, el model només pot descriure com ho faria. No pot fer-ho.

Els agents trenquen aquesta limitació amb una idea que és gairebé decebedorament simple: ficar el model en un bucle. En lloc d'una resposta, el model rep el context actual, decideix què fer, executa una acció sobre el món real, observa el resultat, i torna a començar. Repetir fins que la tasca estigui feta (o fins que alguna cosa es trenqui de forma interessant).

Això dona al model una cosa que en mode pregunta-resposta no té: la capacitat de reaccionar. Pot fallar, llegir l'error, ajustar. Pot explorar un codebase que no ha vist mai abans de tocar-lo. Pot mantenir un fil coherent al llarg de desenes de passos intermedis. El patró és vell —els programadors el reconeixeran com un REPL amb esteroides—, però aplicat a un LLM canvia radicalment el que es pot aconseguir.

I com actua sobre el món? A través d'eines: funcions que el model pot invocar generant una crida estructurada amb els paràmetres que vol usar. El model no executa codi, mai. Decideix què executar i amb quins arguments, i el runtime fa la feina bruta. La selecció d'eines disponibles és el que defineix quin tipus de problemes pot abordar l'agent, i aquí és on Claude Code es posa interessant. Té les òbvies —executar comandes de shell, llegir i escriure fitxers, cercar al codi— però també eines per analitzar l'estructura semàntica d'un projecte o llançar subagents i delegar-los feina. I no estan totes actives sempre: es filtren per context, permisos i configuració de l'usuari.

La memòria és el problema difícil

Aquí hi ha un detall que sol passar per alt: el model no recorda res entre crides. Zero. Cada vegada que el bucle fa una volta, el model rep tot el context des de zero: la instrucció original, l'historial d'accions, els resultats obtinguts. És com un cirurgià brillant amb amnèsia anterògrada al qual li has de rellegir tot l'expedient cada cop que aixeca la vista del pacient.

En tasques curtes això tant és. En tasques llargues, la pila de text creix fins a saturar la finestra de context, i llavors cal triar: què et pots permetre oblidar?

Les solucions pràctiques són dues: comprimir l'historial periòdicament (resumir què ha passat, descartar els detalls que ja no importen) o externalitzar la memòria a fitxers que l'agent pot consultar quan els necessiti. Claude Code fa les dues coses, però la més curiosa és la segona. Per a la memòria entre sessions té un subsistema anomenat Dream: un agent secundari que corre en background després de cada sessió, consolida el que va ser rellevant, elimina informació que es va contradir durant el treball, i manté l'índex en fitxers Markdown sota una mida màxima. Sense base de dades vectorial. Sense embeddings. Markdown pla amb un agent que el cuida. És una solució deliberadament simple, i probablement per això funciona.

El problema de delegar

Algunes tasques es resolen millor si se'n treballen les parts en paral·lel en lloc d'en sèrie. Aquí apareix el patró multi-agent: un coordinador que descompon el problema, llança workers en paral·lel, i sintetitza els resultats quan tornen.

Sona net. A la pràctica, el parany més comú és la delegació vaga. El coordinador passa el problema al worker dient alguna cosa com "analitza això i decideix què fer", confiant que el worker se'n sortirà. El resultat: bucles que volten sense convergir, agents que es tornen el problema mútuament com una patata calenta, i tokens gastats sense que ningú avanci.

Claude Code ho resol de forma directa: al system prompt del mode coordinador està explícitament prohibit dir "based on your findings, decide what to do". El coordinador ha de llegir els resultats reals de cada worker i especificar exactament el pas següent. Res de delegació mandrosa. És una restricció que sembla menor però que marca la diferència entre un sistema multi-agent que convergeix i un que crema.

Quanta corda li dones?

L'última peça, i la més delicada, és l'autonomia. Un agent que demana confirmació a cada pas és tan útil com un becari que t'interromp cada trenta segons. Un sense cap control pot esborrar la teva base de dades de producció mentre tu vas a buscar cafè.

La solució raonable és classificar cada acció per nivell de risc. Llegir un fitxer: automàtic. Executar un test: automàtic. Escriure en fitxers protegits o executar alguna cosa destructiva: demanar permís. Claude Code té fitxers protegits per defecte, classificació de risc per tipus d'acció, i un classificador que aprèn de l'historial de la sessió per decidir els casos grisos.

El nom intern d'aquest classificador és YOLO. Sense comentaris sobre el sentit de l'humor de l'equip, però el mecanisme és la peça que fa que puguis confiar-li tasques reals a alguna cosa que té accés a bash i no acabar amb el cor a la mà.

El que importa no és el model

El que la filtració mostra —més enllà dels noms en clau i els detalls sucosos— és una cosa que hauria de ser òbvia però que el hype fa fàcil oblidar: un agent que funciona en producció no és, principalment, un model més potent. És un sistema d'enginyeria al voltant del model. Quines eines té. Com gestiona el context quan creix. Amb quina granularitat es controlen els permisos. Amb quina precisió es formulen les instruccions entre agents.

El bucle en si és trivial. El difícil, i l'interessant, és tot el que l'envolta.

Typescript

💬 Parlem del teu projecte? Agendar trucada inicial