Revisar codi generat per IA: la revisió que encara espera un autor

De tots els números que ha deixat el 2026 sobre programar amb IA, n'hi ha un que no apareix en cap presentació de vendes: les pull requests que es fusionen sense cap revisió, ni humana ni automàtica, van pujar un 31,3%. La dada és de Faros AI, sobre dos anys de telemetria de 22.000 desenvolupadors en més de 4.000 equips. En el mateix període, els bugs per desenvolupador van pujar un 54% i la proporció d'incidents per pull request es va multiplicar per més de tres.

La lectura fàcil és que la gent s'ha tornat descurada. La lectura útil és una altra: la revisió no s'està saltant per deixadesa, s'està saltant perquè el procés demana una cosa que ja no es pot donar. Quan arriba el triple de canvis, cadascun el doble de gran, i qui els envia no els pot explicar millor que tu, la revisió deixa de ser un control i passa a ser una cua. I les cues, quan pressionen, es drenen pel lloc més barat: aprovant.

Aquesta peça no va de revisar més ràpid. Va que revisar codi generat és revisar una altra cosa, i de què cal canviar al procés quan l'autor deixa d'existir com a interlocutor.

Primer, l'objecció seriosa

Convé despatxar-la abans de construir-hi res a sobre, perquè si és correcta, mitja indústria està optimitzant el lloc equivocat.

El juny de 2026, GitLab va publicar amb Harris Poll una enquesta a 1.528 desenvolupadors i compradors de tecnologia de sis països: el 85% hi està d'acord que la IA ha desplaçat el coll d'ampolla d'escriure codi a revisar-lo i validar-lo. El 78% diu que els seus desenvolupadors escriuen i fan commit més ràpid des que van adoptar IA, i el 79% subscriu el que l'informe anomena la paradoxa: la productivitat individual va millorar, el lliurament global no va seguir el ritme.

Steve Fenton, el juliol de 2026, discuteix la premissa sencera. El seu argument és que ni programar era el coll d'ampolla abans ni la revisió ho és ara, i proposa una prova que es contesta en un minut: al sistema on treballes, quants canvis han passat la revisió i encara no estan desplegats i actius per als usuaris? Si aquest número és molt per sobre de zero, la restricció no és a la revisió — és riu avall. El seu senyal és el desplegament per lots: segons les seves dades, el 92% dels equips desplega en lot i només el 8% desplega canvis de manera independent. Accelerar la generació de codi amb IA, sense tocar això, produeix lots més grans, no lliuraments més primerencs.

Fenton té raó, i no invalida res del que ve després. Estan mesurant dues coses diferents i totes dues importen:

Què diuen les dades, i de qui són

Abans de la taula, un advertiment de procedència que gairebé mai es fa i que aquí canvia quant de pes suporta cada xifra. Bona part de les dades disponibles sobre això les publiquen empreses que venen eines d'analítica d'enginyeria o de seguretat de codi. No les descarta —són les úniques sèries longitudinals grans que existeixen—, però no són revisió per parells i el biaix de selecció dels seus clients és real. Ho marco a l'última columna.

La convergència és el que resulta interessant. GitClear i LinearB no comparteixen metodologia ni clients, i tots dos troben el mateix per camins diferents: la refactorització desapareix. A GitClear, el moviment de codi cau al 3,8%; a LinearB, la taxa de refactorització de les pull requests assistides per IA és pràcticament zero davant d'un 37% a les no assistides. Quan dues telemetries amb biaixos diferents coincideixen en la direcció i en l'ordre de magnitud, el senyal aguanta més pes que qualsevol de les dues per separat.

Els quatre supòsits que es van trencar

La revisió de codi moderna es va estabilitzar a la indústria al voltant d'una idea senzilla: dues persones miren un canvi, una l'explica i l'altra pregunta. Tot el valor és a la conversa, no al formulari. I aquesta conversa descansa sobre quatre supòsits que fins al 2024 es complien sols.

1 · Que existeix algú a qui preguntar per què

És el supòsit que sosté tots els altres. «Per què ho has fet així?» era la pregunta més productiva d'una revisió perquè tenia destinatari: algú havia considerat alternatives i n'havia descartat unes quantes. Amb un canvi generat, aquesta persona pot no existir. Qui obre la pull request va revisar una sortida i li va semblar bé, que és exactament el que farà el revisor. S'han duplicat els lectors i s'ha quedat sense autor.

L'efecte pràctic: la revisió llisca de detectar problemes de disseny a detectar problemes de superfície. I els problemes de superfície són justament els que el generador ja no comet.

2 · Que escriure costa més que revisar

Tota l'economia de la revisió depenia d'aquesta asimetria. Escriure dues-centes línies costava una tarda; llegir-les, vint minuts. Per això era raonable que una persona revisés la feina de diverses. Quan generar aquestes dues-centes línies passa a costar noranta segons i llegir-les continua costant vint minuts, la relació s'inverteix i el sistema s'encalla per on no s'havia dissenyat per encallar-se. Les dades d'espera de LinearB —de tres hores a setze per al primer revisor— no descriuen revisors més lents: descriuen la mateixa capacitat de lectura contra un cabal multiplicat.

3 · Que la mida del diff reflecteix la mida de la decisió

Una pull request gran solia significar un canvi important, i per això mereixia més atenció. Ara un diff de quatre-centes línies pot ser una decisió trivial expressada amb generositat, o tres decisions serioses amagades entre bastida. La mida va deixar de ser senyal, i amb ella va caure l'heurística que els equips feien servir per repartir esforç de revisió.

4 · Que el codi nou s'assembla al que ja hi ha

Un desenvolupador que fa un any que és al repositori reutilitza sense pensar-hi: sap que aquella validació ja existeix. Un generador, amb la finestra de context que sigui, tendeix a resoldre el problema que té al davant escrivint-lo un altre cop. D'aquí la troballa de GitClear que més incomoda: el 2026 la duplicació de blocs ha pujat un 81% respecte al 2023 i les crides a funcions d'altres fitxers —el millor indicador barat de reutilització— han caigut un 35%.

I això és el que cap revisió basada en el diff pot veure. Un bloc duplicat és impecable dins de la seva pull request. Només és un problema en relació amb una cosa que és en un altre fitxer, que el revisor no té obert, i que sovint no sap que existeix. La revisió de codi és estructuralment cega al mode de fallada dominant del codi generat.

La trampa de la percepció

Aquí entra la font més incòmoda d'aquesta peça, i mereix explicar-se amb totes les seves limitacions perquè se cita molt malament.

El juliol de 2025, METR va publicar un assaig controlat aleatoritzat amb 16 desenvolupadors de codi obert experimentats, sobre 246 tasques reals en repositoris propis —una mitjana de més de 22.000 estrelles i més d'un milió de línies—, amb Cursor Pro i Claude 3.5/3.7 Sonnet. Abans de començar, els participants van pronosticar que la IA els faria un 24% més ràpids. El resultat mesurat va ser que van trigar un 19% més. I el que converteix l'estudi en una cosa més que una anècdota: després d'haver fet les tasques, continuaven estimant que la IA els havia fet un 20% més ràpids.

Les limitacions són grans i els mateixos autors les escriuen: la mostra és petita, són repositoris que els participants coneixien a fons, les eines són de principis del 2025 i METR marca avui el resultat com a històric, sense afirmar que descrigui els fluxos de treball actuals. No serveix per sostenir que la IA fa més lenta la gent. Cap d'aquestes limitacions no toca, però, la troballa que importa aquí:

Això explica la dada amb què comença l'article millor que la hipòtesi de la deixadesa. Un equip que aprova ràpid no està sent negligent: està aplicant la seva intuïció calibrada durant anys sobre quant triga algú a escriure alguna cosa i quanta cura mereix llegir-la. Aquesta intuïció s'ha quedat sense base, i com tota intuïció trencada, falla en silenci i amb confiança. És el mateix mecanisme que fa que el ROI de Copilot i Cursor es mesuri on no és: es pregunta a la gent si va més ràpid en lloc de mirar què arriba a producció i què torna.

El que el generador no revisa de si mateix

La resposta reflexa del mercat és posar un revisor automàtic al davant. És una bona idea mal dimensionada, i les dades de Veracode expliquen per què.

A la seva actualització del 2026, amb 80 tasques de codi, quatre llenguatges i més de 150 models avaluats al llarg del temps, la correcció sintàctica supera el 95% mentre la taxa d'aprovat en seguretat es queda al 55% — i aquesta segona xifra fa dos anys que és essencialment plana. Els models han millorat molt a escriure codi que funciona i gens a escriure codi que no es pot explotar. El desglossament és més eloqüent que l'agregat: Python aprova el 62% i Java el 29%; i per tipus de fallada, la injecció en logs aprova el 13% i el cross-site scripting el 15%, davant del 82-86% de la injecció SQL i la criptografia insegura. Ni tan sols els llançaments més recents no mouen l'agulla de manera apreciable, amb l'excepció parcial dels models de raonament, al voltant del 70-72%.

La conclusió operativa no és «no facis servir revisió automàtica». És que la revisió automàtica és més forta justament on el codi generat ja és fort, i comparteix punts cecs amb el generador. Serveix com a primera passada sobre diffs llargs i com a substitut del linter. No serveix com a última baula abans de fusionar, per la mateixa raó per la qual els filtres no poden ser l'última baula abans d'una acció irreversible: un percentatge alt de detecció és una bona notícia per al cost de l'error i una mala base per a una garantia.

I hi ha un efecte de segon ordre pitjor que el tècnic. Un revisor automàtic visible a la pull request produeix la sensació que algú ja ho ha mirat. El 31,3% més de merges sense cap revisió de la telemetria de Faros és consistent amb això: no és que la màquina revisi malament, és que la seva presència es llegeix com un permís per no mirar.

Què es canvia al procés

Res del que ve a continuació no requereix cap eina nova ni aturar lliuraments. Són canvis de contracte entre qui obre una pull request i qui l'aprova.

L'artefacte que retorna el perquè a la pull request

Dels set, el segon és el que sosté els altres, i és també on això connecta amb una cosa que ja defensàvem abans que les dades ho avalessin.

Si la revisió va perdre valor perquè va perdre l'autor, la reparació no és buscar un autor que ja no existeix: és moure el perquè a un artefacte que s'escriu abans de generar i es revisa a part. Això és exactament el que fa l'Spec-Driven Development: l'especificació deixa de ser documentació que envelleix i passa a ser la unitat que es discuteix, s'aprova i es versiona. El codi generat es converteix en la seva conseqüència comprovable, no en la font de veritat.

Vist des de la revisió, el canvi és concret. La conversa es parteix en dues, i cada meitat recupera un interlocutor:

• Sobre l'especificació —abans de generar res— sí que hi ha un autor humà amb intenció, alternatives descartades i criteris. És la conversa cara que val la pena tenir, i costa minuts perquè l'artefacte és curt.
• Sobre el codi la pregunta deixa de ser «per què així?» i passa a ser «això fa el que diu l'especificació, i què fa a més d'això?». És una pregunta que un revisor sí que pot contestar llegint un diff, fins i tot sense haver escrit res.

El «i què fa a més d'això» és la part que la gent es salta i on viu el problema real, perquè el codi generat tendeix a portar feina no demanada: una dependència nova, un fitxer de configuració tocat de passada, una gestió d'errors que s'empassa l'excepció. Aquest excés és invisible si revises contra la teva memòria del que es va demanar, i evident si revises contra un document. És també, dit sigui de passada, el que separa un MVP d'un quick ship.

La mateixa lògica que fa que un golden set sigui l'artefacte que sobreviu als canvis de model en un sistema d'IA opera aquí: el que persisteix no és la sortida, és el criteri contra el qual es jutja. I si aquest criteri no és escrit enlloc, cada revisió el reinventa — amb el resultat desigual que és d'esperar.

Com saber si això t'està passant

Cinc preguntes que es contesten amb les dades que el teu repositori ja desa. No calen enquestes de percepció — que, com acabem de veure, són justament el que no funciona aquí.

1. Quin percentatge dels teus merges dels últims trenta dies va entrar amb zero comentaris? Si puja mes a mes mentre puja el volum, la teva revisió ja és un tràmit. És el mesurament més barat i el que més fa mal.
2. Quin percentatge dels teus incidents va sortir d'un canvi que sí que va passar la revisió? Mesura si detecta res. Una revisió que ho aprova tot i no evita res té cost i no té funció.
3. Està creixent el percentil 75 de la mida de les teves pull requests? És l'indicador avançat de tota la resta, i el més fàcil de corregir amb una regla d'equip.
4. Quanta duplicació té el teu repositori avui respecte a fa un any? Si no ho saps, el mode de fallada dominant del codi generat no és al teu tauler.
5. Quants canvis han passat la revisió i no estan desplegats? La prova de Fenton. Si és alta, arregla això primer: redissenyar la revisió no et lliurarà abans.

Les quatre primeres diuen si la teva revisió continua fent la seva feina. La cinquena diu si la revisió és tan sols el teu problema més urgent. Val la pena en aquest ordre, i val la pena tenir-les abans de la propera conversa sobre comprar una altra llicència — perquè el patró que descriu el gap del 70% es repeteix aquí exactament igual: l'eina va arribar, el mètode no.

Els equips que se'n surten bé no revisen més ràpid ni revisen menys. Revisen una altra cosa: un document curt abans de generar, i un diff acotat després, contra aquest document. Sona a més passos. En hores de persona surt més barat que llegir quatre-centes línies que no ha escrit ningú, buscant un error que, si és l'habitual, ni tan sols és dins de la pull request.

Preguntes freqüents

Realment s'ha desplaçat el coll d'ampolla a la revisió de codi?

Depèn de què en diguis coll d'ampolla, i convé ser precís perquè la resposta canvia la inversió. A l'enquesta de GitLab del juny de 2026, el 85% de 1.528 desenvolupadors i compradors de tecnologia diu que sí. Steve Fenton discuteix la premissa sencera: si la feina s'acumula després de la revisió —canvis aprovats que no estan desplegats— aleshores la restricció és riu avall, al desplegament per lots, i accelerar la revisió no lliura res abans. Tots dos poden tenir raó alhora, perquè parlen de coses diferents: la revisió gairebé mai és la teva restricció de cabal, però és on es concentra el risc. Es redissenya pel segon motiu, no pel primer.

Què canvia exactament quan revises codi generat per IA?

Es trenca el supòsit que existeix un autor. Una revisió tradicional és una conversa amb algú que va prendre decisions i les pot explicar: per què aquesta estructura, quina alternativa va descartar, què passa si arriba un valor nul. Amb codi generat, qui obre la pull request sovint la llegeix per primera vegada amb la mateixa atenció que el revisor. La pregunta «per què ho has fet així?» es queda sense destinatari, i amb ella cau bona part del mecanisme pel qual la revisió detectava problemes de disseny i no només de sintaxi.

Les dades diuen que el codi generat és pitjor?

Diuen una cosa més incòmoda: no és pitjor línia a línia, és més i pitjor connectat. Veracode va mesurar el 2026 que el 55% de les mostres generades passen les seves proves de seguretat —una xifra plana durant dos anys— mentre la correcció sintàctica supera el 95%. GitClear, sobre 623 milions de canvis entre 2023 i 2026, troba que el moviment de codi propi de la refactorització va caure del 21% el 2022 al 3,8% el 2026 i que el copiar i enganxar va pujar del 9,4% al 15,7%. El codi compila, passa, sembla raonable al diff i duplica el que ja existia tres carpetes més enllà. Això no es veu llegint la pull request: es veu llegint el repositori.

Serveix de res posar una IA a revisar el codi d'una altra IA?

Serveix per a la capa que ja cobria el linter i per fer una primera passada sobre diffs llargs, i és una millora real respecte a no mirar res. No serveix com a última baula, per dues raons mesurades. La primera és que el mode de fallada del codi generat no és sintàctic, i la revisió automàtica és més forta justament on el codi ja és fort. La segona la va posar Faros a la seva telemetria de 2026: les pull requests que es fusionen sense cap revisió, humana o agèntica, van pujar un 31,3%. El risc pràctic no és que el revisor automàtic s'equivoqui, és que la seva presència es llegeixi com un permís per no mirar.

Com es revisa una pull request de 400 línies que no ha escrit ningú?

No es revisa: es retorna. És l'única regla d'aquesta peça que funciona sense res més, i la que genera més resistència. Les dades de LinearB sobre 8,1 milions de pull requests situen les assistides per IA en més de 400 línies al percentil 75, davant de 157 de les no assistides, i la seva taxa d'acceptació cau del 84,5% al 32,7%. Un canvi gran generat en vint minuts costa el mateix de partir que un de petit, perquè el cost de generar va deixar de ser el límit. El que sí que cal canviar amb ell és què acompanya la pull request: l'especificació contra la qual es va generar, i els casos que la comproven.

Per on començo aquesta setmana sense aturar lliuraments?

Per mesurar dues coses que gairebé ningú té al tauler i que no requereixen cap eina nova: quin percentatge dels vostres merges dels últims trenta dies va entrar amb zero comentaris de revisió, i quin percentatge dels vostres incidents d'aquell mes va sortir d'un canvi que sí que va passar la revisió. La primera diu si la revisió existeix o és un tràmit; la segona, si detecta res. Amb aquestes dues xifres damunt la taula, la conversa sobre la mida de les pull requests i sobre què les ha d'acompanyar deixa de ser una opinió d'estil i passa a tenir un número al costat.

Fonts citades

• Faros AI — The AI Engineering Report 2026: The Acceleration Whiplash (dos anys de telemetria de 22.000 desenvolupadors en més de 4.000 equips; merges sense revisió +31,3%, bugs per desenvolupador +54%, incidents per PR +242,7%)
• LinearB — 2026 Software Engineering Benchmarks Report (8,1 milions de pull requests, 4.800 equips, 42 països; mida, espera al primer revisor i taxa d'acceptació per tipus de PR)
• GitClear — The Maintainability Gap: 2026 AI Code Quality Research (623 milions de canvis entre 2023 i 2026; refactorització, duplicació i crides entre fitxers)
• Veracode — Spring 2026 GenAI Code Security Update (80 tasques, quatre llenguatges, més de 150 models; 55% d'aprovat en seguretat davant de més del 95% de correcció sintàctica)
• DORA / Google Cloud — 2025 DORA Report · State of AI-assisted Software Development (prop de 5.000 professionals; relació positiva amb el cabal i negativa amb l'estabilitat del lliurament)
• Stack Overflow — 2025 Developer Survey · AI (66% «gairebé correcte, però no del tot»; 45,2% més temps depurant codi generat)
• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (16 desenvolupadors, 246 tasques; pronòstic de +24% de velocitat, resultat de −19%, percepció posterior de +20%). Els autors acoten explícitament l'abast del resultat i METR el marca avui com a històric
• GitLab i The Harris Poll — AI Accountability Report (23 de juny de 2026; 1.528 enquestats de sis països; el 85% del «coll d'ampolla desplaçat a la revisió»)
• Fenton, S. — Code Review Isn't Your Bottleneck, Even With AI (21 de juliol de 2026; la prova dels canvis aprovats i no desplegats, i el desplegament per lots)