Harness Engineering: construir sistemes en lloc de prompts
A l'article anterior d'aquesta sèrie defensava que la veritable palanca no és com redactes un prompt, sinó el context al qual té accés l'agent: què sap, què pot tocar, quins límits ha de respectar.
Però un context que només viu al teu cap, o que has de pedaçar a mà cada vegada que alguna cosa falla, és fràgil. Depèn que te'n recordis. Depèn que hi siguis present.
Aquí és on entra el Harness Engineering: no es tracta d'escriure millors prompts, ni tan sols d'escriure millors fitxers de context, sinó de construir el sistema que manté aquest context viu, actualitzat i estable — estiguis parant atenció en aquell moment o no.
El moment en què vaig adonar-me que havia construït un harness sense posar-li nom
Després d'escriure l'article anterior, vaig començar a fer exactament el que hi descrivia: cada vegada que un Coding Agent s'equivocava en alguna cosa, en lloc de limitar-me a reexplicar-l'hi al xat, anava i arreglava la causa arrel — actualitzava una regla al CLAUDE.md, editava una Skill, ajustava un permís, afegia una comprovació a un hook.
Unes setmanes fent això, i en mirar el que tenia de debò: un conjunt d'instruccions de projecte, una carpeta de Skills per als procediments que faig servir sovint, una llista curta de servidors MCP amb permisos concrets, hooks que executen validacions automàticament, i una regla que diu que res surt a producció sense que jo ho revisi abans.
Res d'això ho vaig planificar com "un sistema". Era simplement jo arreglant un problema cada vegada. Però això és exactament el que és un harness: normalment es construeix per accident abans que ningú li posi nom a propòsit.
Un harness no és un prompt. És un entorn.
Penseu en la diferència entre dir-li a algú què ha de fer una vegada, i donar-li un entorn on fer el correcte sigui l'opció per defecte.
Un prompt és el primer. És una instrucció puntual, vàlida per a una conversa, que desapareix quan acaba la sessió.
Un harness és el segon. És l'entorn durador en què treballa un agent, sessió rere sessió, que fa que el bon comportament sigui el camí de menys resistència en lloc d'una cosa que cal demanar cada vegada.
En concret, un harness per a un Coding Agent està fet de coses que ja tenen nom en aquest ecosistema:
- Instruccions de projecte (
CLAUDE.md,AGENTS.md) — l'arquitectura, les convencions i les restriccions que l'agent ja hauria de conèixer sense que se li diguin. - Skills — procediments empaquetats per a coses que altrament hauries de reexplicar cada vegada.
- Servidors MCP — les eines i fonts de dades externes a què l'agent té permès arribar, i res més.
- Hooks — comprovacions automàtiques que s'executen independentment de si l'agent se'n recorda de fer-ho.
- Permisos — un límit explícit del que l'agent pot fer sense preguntar, i del que no pot fer en absolut.
- Tests — la definició objectiva de "acabat" que no depèn del criteri del mateix agent.
- Punts de revisió humana — els moments en què res avança fins que una persona ho diu.
Cap d'aquestes peces és nova. El que és nou és tractar-les com un sol sistema en lloc d'un munt d'arxius solts que actualitzes de tant en tant quan te'n recordes.
Les instruccions són les parets, no tot l'edifici
Un fitxer CLAUDE.md o AGENTS.md sol ser el primer que s'escriu, i amb raó — és la manera més barata de donar a un agent arquitectura, convencions i límits en un sol lloc.
Però les instruccions només funcionen si l'agent les llegeix, les segueix, i res les trepitja per accident. Són les parets de l'edifici. No són la fontaneria, ni el cablejat, ni l'alarma.
Tractar un bon fitxer d'instruccions com "ja he acabat amb el context" és el mateix error que pensar que una guia d'estil per si sola evita el mal codi. Ajuda. No obliga a res.
Skills: convertir "això ja ho vaig explicar" en una unitat reutilitzable
Tot enginyer sènior té una llista mental de "així és com fem X aquí" que repeteix a cada nova incorporació, a cada col·laborador extern, a cada company ben intencionat que ho fa d'una altra manera una vegada.
Les Skills són aquesta llista, feta executable. En lloc de reexplicar un procediment a un agent a cada sessió — com executar una migració de manera segura, com estructurar la descripció d'una PR, com validar una feature abans de donar-la per acabada — l'escrius una vegada com a Skill, i l'agent la recupera quan és rellevant.
La fallada aquí no és tenir poques Skills. És tenir Skills que se solapen, que queden desactualitzades, o que l'agent no sap distingir amb fiabilitat. Un harness necessita tanta precisió com cobertura.
MCPs i permisos: què pot tocar l'agent de debò
Un agent amb quinze eines que podria fer servir en teoria no és més capaç que un amb cinc que sap fer servir amb fiabilitat. És simplement més difícil de predir.
Els servidors MCP defineixen a quins sistemes externs pot arribar un agent — una base de dades, un sistema de tiquets, un pipeline de desplegament. Els permisos defineixen exactament què pot fer-hi: llegir però no escriure, proposar però no fusionar, executar en un sandbox però mai en producció.
Aquesta és la part del harness que no té res a veure amb la intel·ligència i tot a veure amb el radi d'impacte. Un agent ben acotat i amb permisos estrets és més segur i, paradoxalment, més útil que un màximament capaç sense límits — perquè pots confiar de debò en el que produeix sense haver-ho de revisar tot a mà.
Hooks i tests: les parts que no depenen que l'agent se'n recordi
Les instruccions i les Skills descriuen el que hauria de passar. Els hooks i els tests són el que garanteix de debò que va passar.
Un hook que executa el linter automàticament després de cada canvi no depèn de si l'agent "se'n va recordar" d'executar-lo. Una suite de tests que ha de passar abans de marcar alguna cosa com a acabada no es fia de la paraula de l'agent.
Aquesta és la diferència entre esperar que l'agent segueixi les regles i fer que li resulti estructuralment difícil no seguir-les. Tot el que en un harness puguis convertir de regla escrita en comprovació automàtica, ho hauries de convertir, perquè les regles escrites es passen per alt i les comprovacions automàtiques no.
Punts de revisió humana: quedar-te al bucle a propòsit
Res d'això va d'eliminar-te del procés. Un harness que funciona completament sense supervisió no és més madur, és simplement més arriscat.
La regla que faig servir és senzilla: l'agent no passa al següent pas fins que jo hagi revisat i aprovat l'actual. No perquè no confiï en el sistema que he construït, sinó perquè l'objectiu de construir-lo era fer la meva revisió més ràpida i més enfocada, no fer-la desaparèixer.
Conclusió
El Context Engineering us deia què necessita saber un agent. El Harness Engineering és el que fa que aquest coneixement sigui durador — instruccions, Skills, MCPs, hooks, permisos, tests i punts de revisió humana funcionant com un sol sistema en lloc d'arranjaments solts que apliques sessió a sessió.
Així és com ho veig ara: un harness és l'equivalent a l'entorn controlat en què deixes treballar un agent. No aconsegueixes més confiança esperant que l'agent es comporti bé. L'aconsegueixes dissenyant un entorn on comportar-se bé és l'únic camí disponible.
Al pròxim article d'aquesta sèrie veuré com es connecten de debò aquestes peces entre si — The Orchestrator: CI/CD Thinking Applied to AI Agents — i per què la manera de seqüenciar els passos de Refiner, Implementation i Verification s'assembla molt més a un pipeline de desplegament que a una conversa de xat.
Fins llavors, la pregunta que val la pena fer-se no és:
Ha fet l'agent el que li vaig demanar?
És:
Si no hagués estat mirant, ho hauria detectat igualment el sistema que hi ha al seu voltant?
Si esteu construint alguna cosa semblant, m'agradaria saber com és el vostre harness — no dubteu a escriure'm.