Una issue ben escrita per al teu equip pot ser una mala especificació per a un agent de codi. La persona que la llegeix omple el que falta amb el que sap del producte, del client i del que es va parlar ahir a la daily. L'agent no té res d'això.
La idea que defensa aquest insight: quan a una tasca li falta informació, un agent de codi al qual ningú li ho demana sol no preguntar: s'ho inventa i continua. Per això convertir una issue en una especificació no es delega a l'agent. Ho fa una persona que coneix el producte, abans que l'agent escrigui una línia.
Allò que una issue dona per sabut
Una issue és una nota entre companys. «Afegir filtre per data al llistat de comandes» és suficient si qui la recull sap què és una comanda, quina data compta i a qui preguntar. Gairebé sempre es donen per sabudes tres coses: on és el canvi, què no s'ha de tocar i quan es dona per acabat. Aquesta llista és nostra, no d'un estudi. Un agent que rep només aquesta frase ha de decidir les tres, i ho fa sense avisar.
Allò que fa l'agent quan falta alguna cosa
Tres estudis recents mesuren el mateix amb mètodes diferents: què passa quan a la instrucció li falten dades.
El primer és Ambig-SWE (Vijayvargiya, Zhou, Yerukola, Sap i Neubig; acceptat a ICLR 2026). Parteix de 500 issues de SWE-bench Verified, un conjunt d'issues reals de repositoris de codi obert, i genera amb GPT-4o versions resumides a les quals els falten dades. Resultat: sense una indicació explícita, els models gairebé mai interactuen, ni tan sols amb instruccions greument incompletes. I només dos dels sis models avaluats van distingir amb una precisió notable (89 % i 84 %) una tasca completa d'una d'incompleta, i això quan se'ls animava a preguntar. Quan l'agent podia preguntar a un usuari simulat, el rendiment millorava fins a un 74 % respecte de no poder-ho fer.
El segon és «Ask or Assume?» (Edwards i Schuster, Universitat de Viena; EMNLP 2026). Fa servir 500 issues de SWE-bench Verified a les quals es treuen detalls com fragments de codi, rutes d'arxius i traces d'error. Amb Claude Sonnet 4.5 com a model base, l'agent resol el 70,8 % amb la issue completa. Amb la issue incompleta i sense poder preguntar, el 54,8 %. Amb un muntatge que separa la detecció del que falta de l'execució del codi i pregunta abans d'actuar, el 69,4 %. Amb un segon model, el 69,4 % davant del 72,8 % amb la issue completa.
En punts, el nostre compte: dels 16 que es perden amb la issue retallada, el muntatge que pregunta en recupera 14,6. La diferència no la posa un model millor, sinó un pas en el procés: detectar el que falta i preguntar abans d'escriure codi.
El tercer és «Coding Agents Are Guessing» (Ji i altres, Universitat de Ciència i Tecnologia de Hong Kong i Universitat de Tongji, juliol de 2026). Mesura tasques d'operacions (DevOps) amb 2.208 variants de 69 famílies de tasques i cinc combinacions d'agent i model. La seva conclusió, traduïda: la falta d'especificació, més que fer fallar els agents, fa que endevinin. Segons la configuració, van preguntar entre l'1,7 % i el 44,5 % de les execucions puntuades. I avisar del radi d'impacte de l'acció gairebé no reduïa que l'agent actués.
Risc Són benchmarks, no equips reals. A Ambig-SWE les issues incompletes són resums generats amb GPT-4o. A «Ask or Assume?» es treuen detalls d'issues reals i qui contesta és un usuari simulat (GPT-5.1) que té la issue completa; el teu equip necessita una persona de veritat. «Coding Agents Are Guessing» mesura operacions, no funcionalitats. Els models són els de cada estudi. Ens quedem amb la direcció, no amb el percentatge.
Allò que ha de dur una issue abans de donar-la a un agent
Els estudis no diuen com escriure una issue, diuen què passa quan li falten dades. A partir d'aquí, aquesta és la nostra proposta: sis coses que la persona sol dur al cap i l'agent necessita per escrit. La columna de la dreta és la pregunta que, contestada, tanca cada buit.
| El que la issue deixa implícit | El que l'agent ha de saber | La pregunta que ho tanca |
|---|---|---|
| On és el canvi | Mòduls, arxius i punts d'entrada afectats | On es toca i on no? |
| Què vol dir cada terme | El concepte del domini tal com existeix en aquest codi («comanda», «data») | A quin camp o concepte es refereix exactament? |
| Els casos límit | Buits, zones horàries, permisos, volums grans | Què passa quan l'entrada és estranya? |
| Quan està acabat | Criteris d'acceptació que es puguin comprovar | Quina prova demostraria que està fet? |
| Què no es pot trencar | Contractes d'API, dades de clients, migracions | Quin canvi seria visible a fora o irreversible? |
| Qui decideix si hi ha risc | La persona que aprova si afecta diners, dades o seguretat | Qui ho aprova abans de fusionar-ho? |
Elaboració d'onext
Qui tanca els buits
L'agent pot ajudar, amb una condició. Se li demana que, abans d'escriure codi, llisti el que li falta com a preguntes i no com a suposicions; és, en essència, el que fa el muntatge que proposa «Ask or Assume?». Però qui contesta és una persona que coneix el producte. La seqüència que proposem, dins del Spec-Driven Development (SDD), el desenvolupament guiat per especificacions:
- Demanar a l'agent una llista de preguntes sobre la issue, sense codi. Ha de ser una instrucció explícita: sense ella, segons Ambig-SWE, gairebé no pregunta.
- Una persona que coneix el producte contesta per escrit, a la mateixa issue, perquè ho llegeixi qui vingui després.
- Amb les respostes, la issue passa a ser una especificació: abast, límits i criteris d'acceptació que es puguin comprovar.
- On hi ha risc (diners, dades personals, seguretat, canvis que no es poden desfer), una persona aprova l'especificació abans que l'agent implementi, i es decideix com desfer el que faci. Una persona decideix on hi ha risc.
Una issue està llesta per a un agent quan ningú ha d'explicar-li res més: el que falta es pregunta abans, no es descobreix a la revisió.
Un exemple, inventat
La issue diu «Afegir filtre per data al llistat de comandes». Abans d'escriure codi, un agent hauria de preguntar: la data és la de creació o la de lliurament? El rang inclou l'últim dia? En quina zona horària s'interpreta? Hi ha paginació i quantes comandes pot haver-hi? Qui pot veure quines comandes? Si ningú ho contesta, l'agent tria una resposta per cada pregunta, i qui revisa se n'assabenta, si se n'assabenta, llegint el diff. És un exemple per il·lustrar; no és de cap client.
És la mateixa lògica que expliquem a Specs i agents: l'especificació és on es signa, però un pas abans: aquí no se signa l'especificació, s'escriu. El que l'agent no pot endevinar del teu codi, com les decisions d'arquitectura, ho vam veure a decisions d'arquitectura. I si el que arriba a revisió és una suposició que ningú va detectar, el guany s'hi queda esperant, com expliquem a més codi, el mateix lliurament.
Una prova per a aquesta setmana
Agafa tres issues que el teu equip hagi de començar. Dona-n'hi cadascuna a l'agent amb una sola instrucció: «No escriguis codi. Llista el que necessites saber i no és a la issue». Compta quantes preguntes són útils i quantes hauries descobert a la revisió. És una prova de collita pròpia, no un mètode mesurat. Si en alguna no pregunta res, no la donis per bona: els models d'Ambig-SWE distingien malament una tasca completa d'una d'incompleta.
Si vols veure amb algú de fora com s'escriu això sobre el codi del teu equip, el diagnòstic és gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Com és la resta del camí és a AI-Accelerated Development. El mètode complet és a Spec-Driven Development amb IA.
Preguntes freqüents
Quina diferència hi ha entre una issue i una especificació per a un agent de codi?
Una issue és una nota entre companys: dona per sabut on és el canvi, què no s'ha de tocar i quan es dona per acabat. Una especificació per a un agent ho diu per escrit: abast, límits, casos límit i criteris d'acceptació que es puguin comprovar. El que a la issue completa la persona amb el seu coneixement del producte, a l'agent cal donar-li-ho.
Els agents de codi pregunten quan falta informació?
Si no els ho demanen, rarament. A Ambig-SWE, els models gairebé mai interactuen sense una indicació explícita, ni tan sols amb instruccions greument incompletes. A Coding Agents Are Guessing, segons la configuració, els agents van preguntar entre l'1,7 % i el 44,5 % de les execucions. A «Ask or Assume?», el muntatge que separa la detecció del que falta de l'execució pregunta abans d'actuar.
Cal escriure una issue molt més llarga per a un agent?
No coneixem cap estudi que mesuri la longitud ideal. El que els estudis treuen a les issues per deixar-les incompletes són detalls concrets: fragments de codi, rutes d'arxius, traces d'error. No cal més text, sinó la informació que l'agent no pot deduir: on, què no tocar i quan està fet.
Pot l'agent mateix convertir la issue en una especificació?
Pot ajudar amb la meitat de la feina: llegir la issue i llistar el que li falta com a preguntes, sense escriure codi. L'altra meitat no és seva: contestar aquestes preguntes exigeix conèixer el producte, el client i el context del negoci, i ho fa una persona. Sense aquesta resposta, l'agent torna a omplir els buits amb suposicions.
Quines tasques no haurien d'anar directes a un agent?
Les que afecten diners, dades personals, seguretat o canvis que no es poden desfer. En aquestes, l'especificació l'aprova una persona abans que l'agent implementi. L'estudi sobre instruccions d'operacions (DevOps) va veure que avisar l'agent del radi d'impacte gairebé no reduïa que actués: demanar-li cura no substitueix que algú decideixi.
Com comprovo si el meu equip ho està fent bé?
Amb una prova petita: agafa tres issues a punt de començar, demana a l'agent que llisti el que necessita saber sense escriure codi i compta quantes preguntes són útils, és a dir, quantes hauries descobert a la revisió. Si no pregunta res, no vol dir que la issue estigui completa: els models d'Ambig-SWE distingien malament una tasca completa d'una d'incompleta.
Fonts
- Sanidhya Vijayvargiya, Xuhui Zhou, Akhila Yerukola, Maarten Sap i Graham Neubig, «Ambig-SWE: Interactive Agents to Overcome Underspecificity in Software Engineering», arXiv:2502.13069, versió 3 del 21 de febrer de 2026 (acceptat a ICLR 2026).
- Nicholas Edwards i Sebastian Schuster (Universitat de Viena), «Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents», arXiv:2603.26233, versió 3 del 7 de setembre de 2026 (versió final per a EMNLP 2026).
- Zimo Ji, Zekai Zhang, Congying Xu, Zongjie Li, Yudong Gao, Shuai Wang i Shing-Chi Cheung, «Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions», arXiv:2607.02294, 2 de juliol de 2026.
- Les cites de fonts en anglès estan traduïdes per onext. La taula, els passos, l'exemple, la prova d'aquesta setmana i el càlcul dels punts recuperats són elaboració pròpia d'onext.
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 →