Specs i agents: l'especificació és on se signa

El 3 d'agost, el desenvolupador Niklas Gruhn va posar nom a una cosa que qualsevol equip amb agents ja havia vist: el meat proxy, la persona que reenvia el que produeix una IA sense llegir-ho, entendre-ho ni validar-ho. El seu exemple més esmolat no és un missatge d'Slack, és un pull request. Enganxes el tiquet a l'agent, no mires el que en surt i deixes que els comentaris del revisor dirigeixin les iteracions. El canvi acaba entrant, però la feina l'han feta els revisors amb l'agent, i tu has fet d'intermediari.

El 21 de setembre, Shakers va portar el terme al castellà amb la pregunta correcta —qui signa el que escriu la IA— i un exemple de dany que qualsevol CTO reconeix: una especificació funcional que baixa a desenvolupament amb un requisit inventat i que es construeix sencera abans que ningú s'adoni que el negoci no l'havia demanat. Hi posa a més un cost, amb l'estudi de BetterUp Labs i l'Stanford Social Media Lab de setembre de 2025: el 40% de 1.150 treballadors d'oficina als Estats Units havia rebut aquest tipus de contingut l'últim mes, cada cas costava de mitjana unes dues hores i el total sortia a 186 dòlars per empleat i mes. És feina d'oficina en general, no codi, però el mecanisme és el mateix.

Aquesta peça es queda amb l'exemple de l'especificació, perquè assenyala una cosa que la conversa sobre el meat proxy encara no ha dit: en un cicle de desenvolupament amb agents, la resposta no és revisar més el codi, és signar abans. I la signatura té un lloc concret.

El meat proxy no és un problema d'actitud

La lectura fàcil és moral: hi ha gent que no es llegeix el que envia. La útil és de disseny. Si en el teu procés l'únic punt on una persona valida la feina és el pull request, qui obre aquest pull request és un intermediari per construcció. No va decidir l'enfocament —el va triar l'agent—, no va escriure les línies i, si el canvi és gran, les està llegint per primera vegada amb la mateixa atenció que el seu revisor.

Ho vam explicar amb dades a la revisió que continua esperant un autor: la revisió de codi es basa en el fet que hi ha algú a qui preguntar per què, i amb codi generat aquest algú sovint no existeix. Allà la conclusió era traslladar el perquè a un artefacte que s'escriu abans de generar. Aquí toca la part que va quedar pendent: qui respon d'aquest artefacte, i com es nota que algú n'ha respost.

Revisar més no arregla el que es va decidir abans

Torna a l'exemple de Shakers i segueix el requisit inventat pel procés. L'agent l'implementa bé, amb tests que passen. El revisor comprova que el codi és correcte, que no duplica res i que els tests proven alguna cosa. Tot està bé. Una revisió impecable confirma que el requisit inventat està ben construït.

La revisió compara el codi amb una intenció. Si aquesta intenció no es va escriure mai i ningú no la va aprovar, es compara amb el que el revisor recorda o suposa del tiquet. Cap esforç addicional sobre el diff ho arregla, perquè l'error no és al diff: és en una decisió que ningú no va prendre explícitament. Per això un test escrit des del codi no el prova, el descriu, i per això una revisió feta sense un criteri escrit acaba sent una opinió.

On se signa en un cicle de desenvolupament amb agents

El flux que comparteixen Spec Kit, Kiro i la majoria d'implementacions de Spec-Driven Development és el mateix: especificació, pla, tasques, codi. El Technology Radar de Thoughtworks el resumeix així des de novembre de 2025. El que cap d'aquests esquemes no diu és en quin artefacte respon cada persona. Aquesta és la nostra proposta:

Dues coses de la taula que convé no llegir de pressa. La primera: la signatura cau on hi ha una decisió humana que l'agent no pot prendre, no a cada pas. Signar tasques o signar codi generat és burocràcia; signar què es construeix i què queda fora és responsabilitat. La segona: el codi deixa de ser el lloc on es decideix. Si a la revisió apareix una decisió nova —una dependència, un camp que ningú no va demanar, un comportament davant d'errors—, no es discuteix al diff. Es torna a l'spec, perquè és allà on algú n'ha de respondre. És el mateix criteri que apliquem a la línia del pull request que ningú no discuteix.

Les eines generen l'spec; cap no exigeix que algú la signi

Aquí hi ha la part incòmoda per a qui ha comprat SDD com a eina. Hem llegit la documentació de les dues més utilitzades buscant el punt on una persona aprova l'especificació abans de continuar.

A Spec Kit, el kit de GitHub, la fase d'especificació està ben plantejada: demana definir el què i el perquè abans de decidir el com, i deixa la tecnologia per al pla. Però la seva documentació no fixa cap aprovació obligatòria entre fases. Recomana revisar el resultat abans de continuar, i s'hi queda. A Kiro, d'Amazon, el flux complet guia per requisits, disseny i tasques, i la documentació ofereix a més una drecera explícita: per a funcionalitats ben enteses, Quick Spec genera els tres artefactes «sense punts d'aprovació». Claude Code té un mode pla que proposa un pla i no toca cap fitxer fins que l'aproves, però aquesta aprovació viu a la sessió d'una persona, no en un artefacte versionat del repositori.

No és una crítica a les eines: generar l'artefacte és la seva feina, i decidir qui en respon és feina de l'organització. Però convé veure el risc que obre. Amb un SDD mal implantat, l'agent escriu l'spec, l'agent escriu el codi i la persona reenvia totes dues coses. És un meat proxy amb més passos i amb aparença de mètode. El Radar de Thoughtworks apunta en la mateixa direcció amb altres paraules: algunes eines generen especificacions llargues i difícils de revisar, i de vegades no queda clar a qui van adreçades.

L'objecció seriosa: ningú no vol llegir especificacions

Cal explicar-la sencera, perquè és la millor crítica publicada a SDD i la que més costa respondre. L'octubre de 2025, Birgitta Böckeler, de Thoughtworks, va provar Kiro, Spec Kit i Tessl sobre casos reals. Les seves conclusions: la sortida de Spec Kit li va semblar molt prolixa i feixuga de revisar, fins al punt d'escriure que preferia revisar codi abans que tots aquells fitxers markdown. Kiro va convertir un bug petit en quatre històries d'usuari amb setze criteris d'acceptació. I l'agent, amb tota l'especificació al davant, no va seguir totes les instruccions: va arribar a duplicar codi en prendre la descripció d'una classe existent per un requisit nou.

Les tres observacions són certes, i cap no tomba la tesi. La corregeixen en tres punts concrets:

• Una signatura sobre dotze pàgines també és simbòlica. Si ningú no pot llegir l'spec sencera, signar-la és el mateix gest buit que aprovar un pull request de quatre-centes línies. L'spec que se signa ha de cabre en una pàgina, i el que no hi càpiga és senyal que el canvi és massa gran. Parlem de format i d'extensió a la taula de decisió dels artefactes SDD.
• No tot necessita spec. Un bug d'una línia no s'especifica: s'arregla amb un test que falla i després passa. La signatura es reserva per al que canvia comportament de negoci o toca diners, dades personals, permisos o migracions.
• L'spec no garanteix que l'agent la compleixi. Per això la taula no acaba a l'especificació: el codi es jutja contra ella i els casos d'acceptació en surten. La signatura no substitueix la verificació, li dona un criteri. És la mateixa lògica per la qual el golden set és el que sobreviu als canvis de model.

Böckeler distingeix a més tres nivells: l'spec que s'escriu i es llença després de la tasca, la que es manté i acompanya la funcionalitat, i la que substitueix el codi com a font que s'edita. La signatura només té sentit en els dos últims. Si l'especificació es llença en acabar la tasca, el que queda signat és un document que ja no existeix.

SDD, TDD i BDD amb agents: què valida cadascun

La pregunta surt a totes les formacions, i amb agents la resposta canvia de matís. Les tres pràctiques no competeixen: cadascuna respon una pregunta diferent, i totes tres fallen de la mateixa manera quan l'artefacte de control el genera l'agent a partir del que ja ha fet.

A la pràctica, encaixen així: els escenaris d'acceptació viuen dins de l'spec —són el que se signa juntament amb el què i el perquè—, i els tests es deriven d'aquests escenaris, no del codi. BDD hi posa el format, SDD hi posa la signatura i TDD executa la comprovació. L'ordre importa més que l'etiqueta: primer el que s'ha signat, després el que s'ha generat.

L'spec viu al teu repositori, no a l'eina

Una conseqüència pràctica de posar la signatura a l'artefacte i no a l'eina: el mètode no et lliga a cap agent. Claude Code, Copilot, Cursor o Kiro llegeixen fitxers del repositori. Si l'spec signada és un fitxer, canviar d'eina no canvia qui respon de què. Si la signatura viu a la sessió d'un producte concret, la perds en canviar, i el mercat d'eines canvia cada trimestre, com vam repassar a Claude, Cursor i Copilot a l'empresa.

El mecanisme ja el tens, i no és una eina nova: una carpeta d'especificacions al repositori, un fitxer CODEOWNERS que assigna aquesta carpeta a qui en respon i una regla de protecció de branca que exigeixi la seva aprovació abans de fusionar. Amb això, la signatura queda registrada amb nom, data i versió exacta del text. Un avís de la documentació de GitHub que gairebé ningú no llegeix: amb la revisió de propietaris activada, n'hi ha prou amb l'aprovació d'un d'ells. Si voleu les dues signatures —producte i tècnica—, cal exigir-les a part. L'eina, sola, no distingeix el rol.

El que es configura a l'agent és el contrari: que no comenci a generar sense una spec aprovada, i que llegeixi la constitució i les skills del projecte abans de proposar el pla. La responsabilitat és al repositori i l'agent la llegeix. No a l'inrevés.

Una especificació que es pot signar, sencera

Perquè la idea no es quedi en l'abstracte, així de curta és una spec que es pot signar de debò. El cas és inventat però típic: exportar les factures del mes per a la gestoria.

specs/factures-export-gestoria.md · v1.2

OBJECTIU
  L'usuari d'administració descarrega en un fitxer les factures
  emeses en un mes, amb el format que demana la seva gestoria.

PER QUÈ
  Avui es copien a mà a cada tancament de mes (unes 3 h). Petició de
  Finances al tiquet FIN-214.

FORA D'ABAST
  - Factures rebudes.
  - Enviament automàtic a la gestoria.
  - Qualsevol format que no sigui CSV.

CASOS D'ACCEPTACIÓ
  1. Donat un mes amb factures emeses, quan exporto, obtinc un CSV
     amb una fila per factura i les columnes de l'annex A.
  2. Donat un mes sense factures, quan exporto, obtinc el CSV amb
     capçalera i sense files, i un avís a la pantalla.
  3. Donat un usuari sense rol d'administració, no veu l'opció.

DECISIONS OBERTES
  Cap.

SIGNATURES
  Producte ........ [responsable de producte] · 2026-09-18 · PR #412
  Tècnica ......... [tech lead]               · 2026-09-18 · PR #412

Tres línies d'aquest exemple fan gairebé tota la feina. «Fora d'abast» és la que caça el requisit inventat: si l'agent afegeix l'enviament automàtic perquè li ha semblat útil, la revisió ja no és una opinió, és una comparació amb una línia signada. «Decisions obertes: cap» és la condició per signar: mentre n'hi hagi una, l'spec no està a punt i l'agent no comença. I les signatures no són un adorn: si demà algú pregunta per què l'exportació no inclou les factures rebudes, la resposta té nom, data i un pull request.

Signar aquesta pàgina costa minuts. Costa força menys que llegir quatre-centes línies generades buscant una cosa que ningú no va dir que no calia fer. I canvia la pregunta de la revisió de «està bé, això?» a «fa això el que vam signar, i què fa a més?», que és una pregunta que un revisor sí que pot respondre, encara que no hagi escrit ni una línia. És també el que separa un MVP d'un quick ship.

Cada merge ja és una signatura

Una última observació, per a qui pensi que això afegeix un tràmit. El vostre equip ja signa: cada aprovació d'un pull request és una signatura, amb nom i data, sobre un canvi que entra a producció. L'únic que canvia amb agents és sobre què se signa. Si l'única signatura del procés és al codi, s'està signant una cosa que cap persona no ha escrit. Si és a l'especificació, se signa l'única cosa que una persona sí que ha decidit.

El meat proxy no es corregeix demanant a la gent que llegeixi més. Es corregeix traslladant la signatura al lloc on hi ha alguna cosa a decidir.

Preguntes freqüents

Què és un meat proxy i què té a veure amb el desenvolupament de programari?

És la persona que reenvia el que produeix una IA sense llegir-ho, entendre-ho ni validar-ho. El terme el va proposar el desenvolupador Niklas Gruhn el 3 d'agost de 2026, i el seu exemple més clar és de codi: enganxar el tiquet a l'agent, no mirar el que en surt i deixar que els comentaris del revisor dirigeixin les iteracions. En aquest cas, diu Gruhn, la feina l'han fet els revisors amb l'agent, i qui va obrir el pull request només ha fet d'intermediari. En desenvolupament el patró és especialment car perquè el reenviament acaba a producció.

Què vol dir «signar» una especificació a la pràctica?

Res semblant a un PDF amb rúbrica. Vol dir que l'especificació és un fitxer versionat al repositori i que entra a la branca principal mitjançant un pull request aprovat per persones amb nom, abans que l'agent generi el codi. La signatura és aquesta aprovació: queda registrat qui, quan i sobre quina versió exacta del text. A partir d'aquell moment, el codi es jutja contra aquest fitxer, i qualsevol canvi d'abast passa per modificar-lo i tornar-lo a aprovar.

Qui ha de signar l'especificació?

Dues persones, perquè signen coses diferents. Qui respon del producte signa el què i el perquè: que això és el que el negoci va demanar, i que el que queda fora d'abast està bé fora. Qui respon tècnicament signa que és construïble i coherent amb les regles del projecte. El que no funciona és que la signi només qui l'ha generat amb l'agent: és la mateixa persona revisant el seu propi reenviament. Compte amb les eines: amb CODEOWNERS de GitHub n'hi ha prou amb l'aprovació d'un dels propietaris, així que les dues signatures s'han d'exigir a part.

L'agent pot escriure l'especificació?

Com a esborrany, sí, i sol estalviar temps. La condició és que qui la signa pugui defensar cada línia sense tornar-li a preguntar a l'agent: és la prova de Gruhn aplicada a l'spec. Si no sabria explicar una frase en una reunió, o no sap d'on surt un requisit, no la pot signar. L'exemple de dany que posa Shakers és exactament aquest: una especificació que baixa a desenvolupament amb un requisit inventat i que es construeix sencera abans que ningú s'adoni que el negoci no l'havia demanat.

En què es diferencia SDD de TDD i BDD quan treballes amb agents?

Responen preguntes diferents i es complementen. TDD comprova que el codi fa el que diuen els tests. BDD comprova que el comportament és el que es va descriure en escenaris de negoci. SDD fixa què es va decidir construir, per què, què queda fora i qui ho va decidir. Amb agents, totes tres fallen de la mateixa manera si l'artefacte de control el genera l'agent a partir del codi: tests que descriuen la implementació, escenaris que la parafrasegen o una spec que ningú no ha signat. El pràctic és que els escenaris d'acceptació visquin dins de l'spec i que els tests se'n derivin, no del codi.

Això no és tornar al waterfall?

No, si l'spec és d'una funcionalitat i cap en una pàgina. El waterfall signava un document gran al començament del projecte; aquí se signa un text curt abans de cada canvi rellevant, en minuts. L'objecció té una part de raó que convé acceptar: Birgitta Böckeler va veure com una eina convertia un bug petit en quatre històries d'usuari amb setze criteris d'acceptació. Un bug d'una línia no necessita spec. Una funcionalitat que toca diners, dades o permisos, sí.

Fonts citades

• Gruhn, N. — Don't be a meat proxy (3 d'agost de 2026; origen del terme i exemple del pull request)
• Willison, S. — Don't be a meat proxy (3 d'agost de 2026; la nota que va difondre el terme)
• Shakers — Meat proxy: quién firma lo que la IA escribe (21 de setembre de 2026; l'exemple de l'especificació amb un requisit inventat)
• BetterUp Labs i Stanford Social Media Lab — Workslop (setembre de 2025; 1.150 treballadors d'oficina als EUA, 40% afectats l'últim mes, unes 2 hores per cas, 186 $ per empleat i mes)
• Böckeler, B. — Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (15 d'octubre de 2025; els tres nivells de SDD i les crítiques sobre revisió, mida i compliment)
• Thoughtworks — Technology Radar: Spec-driven development (anell Assess, novembre de 2025)
• GitHub — Spec Kit (flux constitució, especificació, pla, tasques i implementació)
• Kiro — Specs (documentació; Quick Spec sense punts d'aprovació)
• Anthropic — Claude Code: Common workflows (mode pla: proposa i no edita fins que s'aprova)
• GitHub — About code owners (revisió obligatòria de propietaris; n'hi ha prou amb l'aprovació d'un)