Programar amb IA també té friccions: cinc problemes que assenyalen els desenvolupadors

El vídeo «It’s not just you», de The PrimeTime, recull queixes i observacions de diversos desenvolupadors sobre l’ús quotidià d’eines d’intel·ligència artificial per programar. La idea no és que la IA no serveixi, sinó que la promesa de guanyar velocitat conviu amb friccions molt concretes: més feina de revisió, esperes, soroll i menys aprenentatge si es delega sense criteri.

Les publicacions originals que el canal enllaça són experiències i opinions individuals, no una enquesta representativa. Llegides així, ajuden a posar nom a problemes que els equips poden mesurar i corregir en lloc d’atribuir-ho tot a una mala experiència personal.

1. Més codi també pot voler dir més proves per mantenir

Un dels malestars és que una funcionalitat generada amb IA pot arribar acompanyada d’un volum considerable de proves i canvis. Les proves són necessàries, però no són gratuïtes: algú les ha de llegir, comprovar que realment protegeixen comportaments importants, mantenir-les quan canvia el producte i entendre per què fallen a la integració contínua.

La mètrica útil no és quantes línies o tests ha produït el model, sinó si cada prova detecta un risc real. Una bateria extensa que repeteix casos trivials pot alentir el CI i fer més difícil distingir una regressió important d’un test fràgil. La revisió humana ha de mirar cobertura i intenció, no premiar el volum.

2. L’espera del model fragmenta la feina

Quan una resposta triga, és temptador obrir una altra tasca mentre el model treballa. En teoria, això aprofita el temps; a la pràctica, cada canvi de context té un cost. Cal recordar què s’estava resolent, quines decisions ja s’havien pres i què s’ha de revisar quan arriba la resposta.

Si el desenvolupador manté massa fils de feina en paral·lel, la latència no desapareix: es transforma en coordinació i en més possibilitats d’oblidar detalls. Per això convé separar tasques petites i independents, deixar-ne constància i no iniciar una nova línia de treball només perquè el model encara està generant.

3. La pressió per provar cada novetat

El ritme de nous models, agents i frameworks alimenta la sensació que l’equip es quedarà enrere si no adopta l’última eina. Aquesta por de perdre’s alguna cosa —el conegut FOMO— pot acabar generant migracions i experiments que no resolen cap problema prioritari.

El criteri més sòlid és començar per una necessitat concreta: reduir el temps de revisió, millorar una tasca repetitiva o detectar errors abans. Després es pot fer una prova limitada i comparar-la amb el procés actual. Si no hi ha una millora observable o el cost d’integració és massa alt, no cal adoptar-la perquè sigui nova.

4. Les revisions llargues poden amagar el que importa

Les eines d’IA també poden afegir comentaris prolixos a les revisions de codi. Una explicació llarga no és necessàriament una revisió millor: pot repetir informació evident, assenyalar preferències com si fossin errors o diluir un problema real entre recomanacions de poc valor.

Una revisió útil hauria de prioritzar defectes reproduïbles, riscos de seguretat, casos límit i desviacions dels requisits. Els comentaris haurien de ser concrets, verificables i proporcionals a la gravetat. L’equip pot demanar a l’assistent que assenyali el fitxer i la línia, expliqui la conseqüència i separi els bloquejadors dels suggeriments opcionals.

5. Delegar massa pot frenar l’aprenentatge dels perfils júnior

Si una persona en formació demana a la IA que resolgui cada problema i només accepta el resultat, pot perdre part del procés que ensenya a programar: llegir el codi existent, formular hipòtesis, depurar i entendre per què una solució funciona. El lliurament pot semblar més ràpid avui, però deixar menys coneixement per a la següent tasca.

Això no vol dir prohibir l’assistent. Es pot fer servir perquè expliqui alternatives, generi preguntes, proposi proves o revisi una solució pròpia. En equips, combinar aquest ús amb revisió i tutoria humanes ajuda a mantenir l’aprenentatge visible i a comprovar que qui lliura el codi el pot explicar i mantenir.

Conclusions principals

El missatge del vídeo és que les dificultats amb la programació assistida per IA no són necessàriament un fracàs individual: poden venir del disseny del flux de treball. Tests de més, canvis constants de context, pressa per adoptar novetats, revisions sorolloses i aprenentatge delegat són riscos que es poden observar i abordar.

La síntesi s’ha de prendre com un recull de friccions i no com una mesura de quants programadors pensen igual. La pregunta pràctica per a cada equip és si l’eina redueix el temps total fins a un canvi correcte i mantenible —incloent-hi revisió, proves i aprenentatge—, no només el temps que triga a generar codi.