Mètodes
Per què he deixat el Spec Driven Development
Després de mesos utilitzant Spec Driven Development, he comprovat que planificar-ho tot abans genera massa codi i endarrereixa els errors. Ara treballo amb històries curtes i llesques verticals, perquè la IA escrigui el codi mentre jo decideixo, reviso i guio cada pas.
3 min de lectura
Fa uns mesos vaig començar a fer servir l'Spec Driven Development. El mètode consisteix a escriure una especificació detallada, lliurar-la a l'agent i que aquest s'encarregui d'implementar-ho tot: des de la proposta fins al codi final. Sobre el paper sembla una bona idea i durant un temps vaig voler creure que era el camí a seguir.
Després de mesos de pràctica, he arribat a conclusions semblants a les d'altres programadors que han explicat la mateixa experiència. Gent com Kent Beck, Matt Pocock o Dave Farley també hi posen objeccions. No em convenç i vull explicar per què.
El problema no és planificar
Planificar és necessari. El problema és voler planificar-ho tot d'una vegada. Quan defineixes l'arquitectura, el model de dades i el llistat de tasques en el moment en què menys saps sobre el problema, tornes a la gestió de projectes en cascada de fa vint anys. L'agent, si no se li indica el contrari, acostuma a omplir els buits amb sobreenginyeria: interfícies innecessàries, camps a la base de dades que no saps per què hi són o capes d'abstracció pensades per a un futur que segurament no arribarà.
Demanes un sistema de login i l'agent et torna un document de tres pàgines amb requeriments, pla d'arquitectura, vint-i-set tasques i quatre capes de codi. Tot i això, encara no pots iniciar sessió.
Res funciona fins al final
Les tasques solen sortir dividides per capes: primer tota la base de dades, després l'API i, finalment, el frontend. Una base de dades sense API no es pot provar; una API sense frontend no es pot utilitzar. El resultat és que no tens res que funcioni fins a l'últim dia. Quan arriba el moment, la revisió implica analitzar 3.000 línies de codi. L'agent ha trigat quinze minuts a generar-ho i tu hi passes tres hores. Al final, demanes canvis fins que te'n canvies i acceptes el que hi ha.
Com treballo ara
El que m'ha funcionat és un enfocament més clàssic: un backlog d'històries d'usuari curtes, treballades d'una en una. Un exemple seria: Com a usuari, vull registrar-me amb correu i contrasenya. Aquesta història es refina abans de construir-la: definim els casos, els criteris d'acceptació i, sobretot, què queda fora del projecte.
Cada història es construeix com una llesca vertical: travessa la base de dades, l'API i el frontend. En acabar, tens alguna cosa que pots provar fent-la servir, no llegint-ne el codi. Si alguna cosa no funciona, te n'adones als trenta minuts, no tres dies més tard.
La IA escriu, però tu navegues. Decideixes què es construeix, què no, quan cal refer el codi per millorar-lo i quan no. Cada petit pas és visible: si l'agent modifica un test per fer-lo passar, ho veus a l'instant.
En resum
L'Spec Driven Development no està optimitzat per programar; està pensat per delegar l'especificació. La implementació tècnica funciona millor en petits passos, amb la IA escrivint i tu pilotant el procés. Menys documents, menys capes i més software que realment funcioni.