Són les sis i mitja de la tarda. Algú del teu equip té una funcionalitat sencera ben especificada i podria deixar-la en mans d'un agent de codi fins demà. No ho fa, perquè a les nou del matí ningú no sabria dir si el que ha fet l'agent es pot integrar.
El Technology Radar 35 de Thoughtworks, publicat aquest mes, posa aquesta nit a l'anell Trial i, al seu voltant, la llista del que cal per fiar-se del resultat. Gairebé res d'aquesta llista és una eina nova.
Hem llegit el volum sencer, les 117 entrades, i ens hem quedat amb el que és a Adopt i a Trial i afecta un equip que desenvolupa amb agents. Ho hem ordenat per les preguntes que es fa aquest equip.
Com es llegeix el Radar
El Radar l'elabora el Technology Advisory Board de Thoughtworks, 18 tecnòlegs sènior que es reuneixen dues vegades l'any; aquesta edició surt de la trobada de setembre de 2026 a Recife (Brasil). Cada entrada, que ells anomenen blip, cau en un de quatre anells:
- Adopt: creuen que el sector ho hauria d'adoptar i ho fan servir als seus projectes quan encaixa.
- Trial: val la pena; les empreses ho poden provar en un projecte que aguanti el risc.
- Assess: convé explorar-ho per entendre com t'afecta.
- Caution: cal anar amb compte, perquè té problemes seriosos.
Segons el nostre recompte, en aquest volum Adopt té 11 entrades i Trial, 49. I del que hi ha dins: de les sis tècniques a Adopt, cinc les justifica el mateix Radar per l'arribada dels agents o de la IA generativa (aïllar l'agent, el mutation testing, mapar el camí a producció, donar el context per parts i el modelatge d'amenaces); la sisena és la criptografia postquàntica. Entre les eines, OpenAI Codex passa a Adopt i, segons el text, se suma a Claude Code i OpenCode com a agents de terminal que els seus equips fan servir cada dia.
Amb tres agents de codi citats com a eina d'ús diari, triar agent ja no distingeix un equip d'un altre. El que el Radar puja d'anell és el que envolta l'agent, i li dedica un dels seus quatre temes, harness engineering at scale: l'harness és tot el que es construeix al voltant de l'agent, de la memòria i el context als bucles de correcció i els límits, i el Radar el descriu com «un actiu viu» que necessita propietari i manteniment.
| Entrada del Radar 35 | Anell | Què li demana al teu equip |
|---|---|---|
| Path-to-production mapping | Adopt | Dibuixar el camí del codi des del portàtil fins a producció i marcar on s'embussa |
| Mutation testing | Adopt | Comprovar que els tests, també els que escriu l'agent, detecten un error de debò |
| Agent sandboxing | Adopt | Que tot agent treballi aïllat i amb l'accés mínim |
| Progressive context disclosure | Adopt | Un fitxer de l'agent curt, amb enllaços al que pot consultar quan ho necessiti |
| Threat modeling | Adopt | Decidir amb persones on s'accepta un comportament no determinista i on no |
| OpenSpec, grilling i plans visuals | Trial | Especificar i aclarir la intenció abans que l'agent escrigui |
| Risk-tiered human oversight | Trial | Revisar amb més o menys profunditat segons el que el canvi pugui trencar |
| Feedback flywheel i self-improving harness | Trial | Convertir el que falla a cada sessió en canvis de l'harness, també traient regles |
| Agent plugin marketplace i Agent Package Manager | Trial | Repartir skills i instruccions entre equips amb versió i procedència |
| Toxic flow analysis for AI | Trial | Localitzar per on podria entrar una injecció d'instruccions i sortir una dada |
| Unattended overnight agentic builds | Trial | Tenir tot l'anterior abans de deixar l'agent sol amb una tasca gran |
Selecció pròpia de les entrades a Adopt i Trial que afecten equips que desenvolupen amb agents; la descripció de la tercera columna és la nostra lectura del text de cada entrada. Font: Thoughtworks, Technology Radar vol. 35, novembre de 2026.
Abans que l'agent escrigui: especificar sense enterrar-lo en Markdown
OpenSpec, un marc lleuger de Spec-Driven Development (SDD, desenvolupament guiat per especificacions) que funciona amb qualsevol agent, passa d'Assess a Trial. Segons el Radar, diversos equips de Thoughtworks l'han fet servir amb èxit, també sobre codi existent, i expliquen que l'agent produeix resultats més previsibles i menys canvis no demanats que quan se li dona només un prompt. El que destaquen és que cada canvi s'escriu com una diferència sobre una especificació persistent, que continua sent la referència actual del sistema.
Al mateix anell hi ha dues tècniques per a la conversa prèvia. Amb el grilling, l'agent t'entrevista sobre el pla abans d'actuar, per no endevinar allà on la teva intenció no és clara; el Radar afegeix que t'obliga a revisar els teus propis supòsits i deixa decisions que es poden registrar. Amb els plans visuals interactius, l'agent prepara un pla en HTML amb diagrames i esbossos de pantalles que l'equip recorre abans d'implementar; els seus equips avisen de no convertir-lo en un gran disseny previ i de treballar en passos petits i comprovables.
El contrapès és a Caution: AI-driven documentation sprawl, la documentació que els agents generen en grans quantitats i que ningú no poda. El Radar cita Spec Kit i BMAD com a eines amb què passa, parla d'una «gran bola de fang de documentació» i avisa que les especificacions obsoletes o contradictòries consumeixen context i desvien l'agent. La seva recomanació és tractar el Markdown com un artefacte de primera classe i dedicar esforç humà deliberat a podar-lo.
La nostra lectura és que el Radar separa les dues entrades pel manteniment: una especificació que ningú no actualitza acaba sent soroll que l'agent llegeix com si fos cert. Al mateix OpenSpec el Radar li demana disciplina per mantenir l'especificació persistent.
És també el que veig amb els equips amb què treballem. Sempre els explico que els alineem amb OpenSpec perquè la nostra manera de treballar ja segueix aquest mateix enfocament, però que eines com Spec Kit avui no s'ajusten a les necessitats del seu projecte, perquè porten skills i plantilles massa genèriques.
El context: menys instruccions, carregades quan fan falta
Progressive context disclosure puja a Adopt perquè, segons el Radar, ja és gairebé universal a les aplicacions serioses: l'agent arrenca amb l'essencial i carrega la resta quan ho necessita. En codi, això és un AGENTS.md curt amb enllaços a documentació que l'agent consulta si li cal, i skills i eines que no ocupen context fins que es fan servir.
L'entrada de Caution que l'acompanya és agent instruction bloat: les instruccions creixen, cada regla sembla útil per separat i amb el temps el conjunt s'allarga i es contradiu. El Radar proposa convertir en comprovacions automàtiques tot el que es pugui i revisar les instruccions amb cada model nou per esborrar les que ja no necessita. Com a exemple, explica que Anthropic va treure més del 80 % del prompt de sistema de Claude Code per als seus últims models sense una pèrdua mesurable. Què convé deixar en aquest fitxer ho hem tractat a part (CLAUDE.md i AGENTS.md: què deixar al fitxer de l'agent).
Tres entrades de Trial van en la mateixa direcció. Els subagents per gestionar el context fan l'exploració i els reintents fora de la sessió principal i li tornen només l'essencial; el Radar suggereix dos a quatre alhora i reconeix que el seu benefici encara no s'ha mesurat de manera sistemàtica. Les bases de coneixement mantingudes per agents guarden el coneixement de l'equip en fitxers de text enllaçats que un agent manté al dia, amb el risc que s'allunyin de la realitat si cap persona no les revisa. I ancorar els agents a una aplicació de referència els permet consultar en el moment les convencions vigents de la plataforma, que canvien més de pressa que qualsevol plantilla.
A Caution queda també agent skill cognitive surrender: importar biblioteques senceres de skills de la comunitat sense entendre què fan. El Radar posa a Trial una d'aquestes biblioteques, mattpocock/skills, precisament perquè són skills petites i fàcils d'adaptar, i demana llegir cada skill abans de fer-la servir i preferir les que l'equip escriu per al seu propi domini.
La comprovació: on mira una persona i on mira una màquina
Amb més agents treballant, el Radar veu el coll d'ampolla en la capacitat de revisió i en el camí a producció. La seva resposta a Trial és risk-tiered human oversight: els canvis més arriscats o més difícils de desfer els aplica una persona, els intermedis passen per revisió humana i els de baix risc els pot integrar l'agent a través de la integració contínua. Per classificar-los proposa dues vies, zones del codi que exigeixen més revisió i una classificació del canvi amb un model de llenguatge, que el Radar qualifica de fal·lible, i esmenta el procés que ha publicat Meta.
L'alternativa, revisar-ho tot amb la mateixa intensitat, el Radar la posa a Caution amb nom propi: human-in-the-loop theater, la persona que aprova canvis que no pot avaluar de debò i converteix l'aprovació en un lloc on ningú no és responsable de la decisió. Per al que no revisi una persona, proposa vigilar el sistema amb comprovacions: mutation testing, tests basats en propietats, models formals i revisió semàntica assistida per agents.
El mutation testing és a Adopt per un motiu molt concret: l'agent genera molts tests, la cobertura de codi és fàcil d'inflar amb tests superficials i el mutation testing introdueix petits errors a propòsit per veure si algun test els detecta. El Radar afegeix que el mateix agent ho pot fer dins del seu bucle, i aconsella limitar-ho als paquets que importen o al codi canviat, perquè triga.
L'altre Adopt d'aquesta part és path-to-production mapping, una pràctica de sempre a Thoughtworks que, segons el Radar, torna a ser rellevant: si l'agent escriu més codi, els embussos apareixen en un altre punt del camí. És un taller amb totes les persones que dissenyen, desenvolupen, despleguen i operen el programari: primer s'escriuen en una pissarra els passos, del lloc del desenvolupador fins a producció, i en una segona volta, els punts de dolor.
Dues eines a Trial serveixen perquè l'agent rebi els seus propis errors abans que una persona: Act, que executa en local els fluxos de GitHub Actions perquè l'agent provi la integració contínua abans de pujar, i ast-grep, les regles estructurals del qual un equip de Thoughtworks fa servir per comprovar el codi de l'agent i tornar-li el resultat. A Caution, el Radar torna a advertir contra mesurar la productivitat pel percentatge de codi generat per IA o pels tokens consumits, i recomana les mètriques DORA i els resultats de negoci.
L'harness es manté, igual que qualsevol altre sistema
El feedback flywheel passa a Trial perquè, segons el Radar, editar l'harness ja és rutina. La pràctica afegeix una pregunta al final de cada sessió (cal canviar res en un artefacte compartit?) i un punt a la retrospectiva on l'equip decideix què actualitzar. El Radar insisteix que la roda també ha de treure: les regles que només s'acumulen acaben en l'excés d'instruccions d'abans. Un equip pot començar apuntant cada correcció que li fa a l'agent (el que ensenyen les correccions del teu equip).
Manel Marcos, el nostre CTO, ho resol amb una persona: a l'equip que acompanyem hi deixem un rol de context engineer, i li ensenyem a vetllar per l'harness i pel context i a millorar-los de manera contínua.
El pas següent, també a Trial, és el self-improving harness: agents que analitzen les traces d'execució i els resultats de les avaluacions i proposen o apliquen millores a l'harness mateix. El Radar recomana fer-ho amb experiments acotats i proves de regressió, amb persones que fixen els objectius i els límits del que es pot modificar.
Quan diversos equips d'una empresa fan servir agents, apareix el problema de repartir el que funciona. El Radar posa a Trial l'agent plugin marketplace, un repositori Git documentat des del qual es publiquen skills, instruccions, servidors MCP i subagents, i Agent Package Manager, que els gestiona com a dependències amb versió i procedència registrades, i busca Unicode ocult que podria segrestar l'agent. El nivell següent, l'enterprise harness comú a tota l'organització, es queda a Assess, amb el consell de mantenir-lo fi i federat mentre no hi hagi consens sobre com fer-ho bé.
Seguretat: l'agent, aïllat i amb l'accés mínim
Agent sandboxing arriba a Adopt com a opció per defecte per a tots els agents, també els que actuen en sistemes de negoci: entorns aïllats amb privilegis i accés a sistemes externs restringits, amb un enfocament per risc que surti del modelatge d'amenaces. El threat modeling, a Adopt, hauria de ser una part habitual del cicle de desenvolupament, dirigida per persones i recolzada per agents, i acabar amb decisions explícites: on és acceptable que el model es comporti de forma no determinista i on calen límits deterministes.
A Trial, el toxic flow analysis for AI busca els camins perillosos de les dades en un sistema amb agents. El Radar parteix de la combinació que anomena «trifecta letal»: accés a dades privades, exposició a contingut no fiable i capacitat de comunicar-se cap a fora. I avisa que el risc també arriba per skills que semblen útils i amaguen instruccions per treure dades. El managed agents runtime, executar els agents en una plataforma que gestiona la seva execució, fora del portàtil del desenvolupador, també és a Trial, amb la recomanació de tractar-lo com a infraestructura de producció.
Si construeixes agents que no programen
Una entrada de Trial interessa a qui porta agents a processos de negoci: el coding harness for general-purpose agents. Cada vegada més equips munten el bucle dels seus agents sobre el motor d'un agent de codi madur (el Claude Agent SDK, l'SDK de Codex, el servidor d'OpenCode o Pi), que ja resol la compactació del context en tasques llargues i les sessions persistents. El preu és menys control, i el Radar demana revisar-ne les instruccions per defecte, pensades per escriure codi, i vigilar el consum de tokens.
Al voltant hi ha diversos components de producció a Trial: els stateful guardrails, que avaluen la conversa sencera, torn a torn; Promptfoo, per a avaluacions i proves d'atac repetibles; Presidio, per detectar dades personals abans d'enviar-les a un model, amb l'avís que no és infal·lible; Temporal i Restate, per a processos llargs que esperen una persona; i LibreChat, que el Radar presenta com una manera controlada de donar eines d'IA a qui no és d'enginyeria. En models, els de pesos oberts i els petits passen a Trial, i l'ús del model més potent per a tot, sense mirar cost ni latència, es queda a Caution.
Límit El Radar recull l'opinió d'un grup de tecnòlegs d'una consultora a partir dels seus propis projectes; no és un estudi amb dades mesurades. Trial és una invitació a provar-ho en un projecte que aguanti el risc, i en diverses entrades el mateix text reconeix que l'experiència és curta: el benefici dels subagents no s'ha mesurat de manera sistemàtica i algunes recomanacions es basen en l'experiència d'un equip concret. Thoughtworks ven aquest tipus de feina, igual que nosaltres.
La prova d'aquesta nit
De totes les entrades, la que millor serveix de diagnòstic és la de la nit. El Radar explica que «overnight» és al nom perquè és difícil de fingir, i que un equip que no deixa un agent treballant sol de nit probablement tampoc no té feina autònoma durant el dia. També diu que la pràctica té requisits d'entrada i que bona part del seu valor és obligar l'equip a complir-los. Convertits en preguntes per al teu equip, més una que surt de la revisió per risc:
- L'agent treballa en un entorn aïllat, sense accés al que no necessita per a aquella tasca?
- La tasca està especificada abans de començar, amb criteris que es puguin comprovar, com en Spec-Driven Development?
- L'agent rep els seus propis errors (tests i estat de la integració contínua) i els pot corregir sense esperar una persona?
- Teniu un harness provat que validi el resultat, per no dependre de llegir línia a línia la feina d'una nit?
- Sabeu quins canvis revisa una persona al matí i quins pot integrar el mateix sistema?
Al nostre producte propi, on hem arribat a un nivell de maduresa alt, ho fem així: quan una feature té totes les preguntes obertes resoltes, deixem els agents desenvolupant tota la nit un sprint d'històries d'usuari i al matí revisem l'auditoria de l'sprint.
Si alguna resposta és «no», el Radar suggereix tractar la nit com un objectiu que justifica construir aquesta base. És la feina d'AI-Accelerated Development. Construïm amb el teu equip dues coses que es queden a casa teva: el context en què treballa la IA i el procés amb què treballeu, de la idea a la documentació actualitzada. Si vols revisar amb algú de fora què us falta, hi ha un diagnòstic gratuït.
Preguntes freqüents
Què és el Technology Radar de Thoughtworks?
És la guia en què Thoughtworks dona la seva posició sobre tècniques, plataformes, eines i llenguatges. L'elabora el seu Technology Advisory Board, un grup de 18 tecnòlegs sènior que es reuneix dues vegades l'any, a partir del que veuen als seus projectes. El volum 35, de novembre de 2026, té 117 entrades.
Què signifiquen Adopt, Trial, Assess i Caution al Radar?
Adopt vol dir que Thoughtworks creu que el sector ho hauria d'adoptar ja. Trial, que val la pena provar-ho en un projecte que pugui assumir el risc. Assess, que convé explorar-ho per entendre com t'afecta. Caution, que cal anar amb compte perquè té problemes importants.
Què és l'harness d'un agent de codi?
És tot el que l'equip construeix al voltant de l'agent perquè treballi bé: el context i les instruccions, la memòria, les comprovacions que li tornen els seus errors i els límits del que pot tocar. El Radar 35 el tracta com un actiu viu, amb propietari i manteniment.
Es pot deixar un agent de codi treballant tota la nit?
El Radar 35 ho posa a Trial per a equips que ja tenen la base: l'agent aïllat en un entorn restringit, la feina especificada abans, comprovacions que li permetin corregir els seus propis errors i un harness provat que validi el resultat sense dependre de llegir cada línia.
Què diu el Radar 35 sobre Spec-Driven Development?
Puja OpenSpec a Trial perquè els seus equips l'usen amb èxit, també en codi existent, i demana que l'especificació es mantingui com a referència viva. Alhora posa a Caution la documentació generada en massa que ningú no poda, i cita Spec Kit i BMAD com a eines amb què passa.
Què és human-in-the-loop theater?
És mantenir una persona al bucle d'un agent com un pas d'aprovació buit: aprova accions o canvis que no pot avaluar de debò. El Radar 35 ho posa a Caution i proposa graduar la revisió segons el risc de cada canvi.
Fonts
- Thoughtworks, Technology Radar, vol. 35, novembre de 2026 (PDF en anglès).
- Entrades citades: Unattended overnight agentic builds, OpenSpec, AI-driven documentation sprawl, Progressive context disclosure, Agent instruction bloat, Risk-tiered human oversight, Human-in-the-loop theater, Mutation testing, Path-to-production mapping, Feedback flywheel, Agent sandboxing, Toxic flow analysis for AI i Coding harness for general-purpose agents.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →