Imagina la planificació del dilluns. El teu equip estima una història en cinc dies. Dimarts, l'agent ja ha escrit el codi i les proves. Divendres la història continua oberta: ningú no havia decidit què passa quan un client no té adreça de facturació, i la resposta va trigar tres dies a arribar.
Quan programar deixa de ser el que és car, el cicle de vida del programari no desapareix: canvia de coll d'ampolla. El temps que l'agent estalvia escrivint codi es perd en les suposicions que ningú no va dir en veu alta abans de començar.
Què passa quan planifica la IA tota sola
Adriana Caraeni, Alexander Shick i Andrew Lan van comparar tres maneres de planificar un sprint sobre un encàrrec real d'una agència digital mitjana: només amb IA, només amb persones i amb totes dues alhora. Planificar només amb IA va ser el més ràpid i el més barat, però «significantly degrades risk capture rates»: va captar menys riscos i va deixar més retreball per suposicions que ningú no havia dit.
La seva conclusió qüestiona una cosa que molts equips donen per feta: «that efficiency equates to effectiveness». Proposen deixar a les eines l'estimació i el format del backlog, i reservar a les persones la conversa sobre riscos i ambigüitats.
Límit És un preprint de set pàgines, en revisió, fet en una sola agència, i el resum no dona la mida de la mostra. Serveix com a senyal d'on mirar al teu equip.
On se'n va ara el temps
Si el codi surt en hores, el ritme del cicle el marca el que triga el teu equip a respondre una pregunta. Què passa amb aquest cas límit? Qui decideix si canvia el contracte de l'API? Abans, aquestes preguntes apareixien a mitja implementació i es resolien pel camí, perquè programar donava temps per pensar. Amb un agent apareixen en minuts. I llavors es queden esperant algú, com al metatreball amb agents, o l'agent les respon tot sol amb el que li sembla raonable.
Una cosa semblant passava en un client del sector públic. Els proveïdors externs programaven amb IA sense integrar-se al flux ni al context de l'equip. Cada cop, les pull requests, les propostes de canvi que es revisen abans d'incorporar-les al codi, eren més complexes de fer.
La fase que més creix és la d'abans del codi: escriure el que l'equip dona per suposat. Amb una issue de dues línies no n'hi ha prou, per les raons de per què una issue no és una especificació. N'hi ha prou amb una línia per suposició, amb la manera de comprovar que es compleix: ja canvia la setmana.
Una pregunta per a la teva propera planificació
Mira l'última història que es va endarrerir al teu equip. Es va endarrerir escrivint codi o esperant una resposta? Si va ser el segon, la drecera és a la planificació: fer-hi seure qui pot respondre i sortir-ne amb les suposicions escrites.
Si ho vols mirar amb algú de fora, el diagnòstic és gratuït. Abans, pots veure com treballem amb equips de desenvolupament a AI-Accelerated Development.
Preguntes freqüents
Com canvia el cicle de vida del programari amb IA?
Les fases continuen sent les mateixes: entendre el problema, especificar, construir, provar, desplegar i operar. Canvia on se'n va el temps. Escriure el codi pot passar a durar hores, i el ritme el marca el que triga l'equip a decidir allò que l'agent no pot deduir pel seu compte.
Cal canviar de metodologia, per exemple a AIDLC?
No necessàriament. AIDLC (AI-Driven Development Life Cycle) és la metodologia que AWS va presentar el juliol de 2025 per a un cicle de desenvolupament dirigit per IA, i n'hi ha altres propostes. Abans de canviar el nom del procés, convé mirar on espera avui la feina del teu equip: si espera respostes, el canvi és en quan i amb qui decideix l'equip.
Pot la IA planificar l'sprint tota sola?
Pot ajudar a estimar i a ordenar el backlog. En un experiment publicat l'abril de 2026 sobre un encàrrec real d'una agència digital, planificar només amb IA va ser més ràpid i més barat, però va captar menys riscos i va generar més retreball per suposicions que ningú no havia dit. Els autors proposen deixar a les persones la conversa sobre riscos i ambigüitats.
Serveix aquest experiment per a la meva empresa?
Serveix com a senyal d'on mirar. És un preprint en revisió, de set pàgines, fet en una sola agència, i el resum no dona la mida de la mostra. El que és útil és mirar al teu equip on s'endarrereixen les històries: escrivint codi o esperant una resposta.
Què és una suposició sense escriure?
Qualsevol decisió que l'equip dona per feta i que ningú no ha deixat per escrit abans de començar: què passa si un client no té adreça de facturació, qui pot canviar el contracte d'una API, quin temps de resposta s'accepta. Si ningú no l'escriu, l'agent l'omple amb el que li sembla raonable.
Escriure les suposicions obliga a fer documents llargs?
No cal. N'hi ha prou amb una línia per suposició, amb la manera de comprovar que es compleix. És la base de l'Spec-Driven Development (SDD), el desenvolupament guiat per especificacions: deixar escrit què ha de fer el canvi i amb quins criteris s'accepta abans que ningú, persona o agent, escrigui el codi.
Fonts
- Adriana Caraeni, Alexander Shick i Andrew Lan, «Cognitive Offloading in Agile Teams: How Artificial Intelligence Reshapes Risk Assessment and Planning Quality», arXiv:2604.13814, 15 d'abril de 2026 (en revisió).
- Raja SP, «AI-Driven Development Life Cycle: Reimagining Software Engineering», AWS DevOps & Developer Productivity Blog, 31 de juliol de 2025.
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 →