Cal revisar el codi generat per IA? El debat d'Uncle Bob

Robert C. Martin, conegut com a Uncle Bob i autor de Clean Code, va provocar un debat intens en afirmar que la seva estratègia actual és no llegir el codi escrit pels seus agents d’intel·ligència artificial. Segons Martin, revisar línia per línia eliminaria bona part del guany de productivitat; prefereix envoltar els agents amb restriccions extremes, proves automatitzades, mètriques de qualitat i proves de mutació.

El titular sembla una invitació a acceptar codi a cegues. No ho és. La proposta real trasllada el punt de control: de revisar tota la implementació a verificar especificacions, comportaments observables i portes automàtiques. Midudev hi veu una intuïció vàlida, però defensa que el context importa i que els programadors —especialment els que comencen— encara han d’entendre i revisar què s’incorpora al producte.

La conclusió d’aquest resum verificat és clara: les proves poden reduir molt la necessitat de revisar mecànicament cada línia, però no eliminen la responsabilitat humana ni converteixen una suite verda en una prova absoluta de correcció.

En trenta segons

• Uncle Bob diu que no llegeix la implementació generada pels seus agents perquè vol aprofitar-ne la velocitat.
• La confiança prové d’un “guant” de proves unitàries, escenaris Gherkin, procediments de qualitat, cobertura, mètriques i mutation testing.
• Midudev considera que aquest enfocament pot funcionar en projectes petits, delimitats i molt verificables, però no es pot generalitzar sense tenir en compte arquitectura, infraestructura i negoci.
• Una prova només confirma l’expectativa que algú ha codificat. Si l’expectativa és incompleta o errònia, el test pot passar i el producte continuar estant malament.
• Cobertura alta no significa necessàriament bons tests. Les proves de mutació aporten un senyal més fort, però tampoc demostren tots els requisits.
• Per a canvis crítics —autenticació, pagaments, dades, permisos, criptografia o concurrència— continuen sent necessaris l’anàlisi de risc i una revisió humana qualificada.
• Per als júniors, llegir, executar, depurar i explicar el codi generat és part de l’aprenentatge, no una pèrdua de productivitat.
• El valor diferencial del desenvolupador es desplaça cap a entendre el producte, el domini, els usuaris i els riscos del sistema.

Què va dir realment Uncle Bob?

El vídeo parteix d’una resposta publicada a X el juliol de 2026. Martin explica que programa des de finals dels anys seixanta i que no llegeix el codi creat pels seus agents. Afirma que aquesta és la manera d’aprofitar-ne la productivitat i que, a canvi, els sotmet a restriccions extremes.

La llista que apareix al fil inclou:

• proves unitàries;
• escenaris o proves Gherkin;
• procediments de control de qualitat;
• mètriques de qualitat;
• proves de mutació;
• cobertura de proves;
• altres comprovacions deterministes.

La paraula important no és “no llegeixo”, sinó restriccions. L’agent no rep carta blanca: ha de produir un canvi que compili, compleixi el contracte observable, superi les anàlisis i no degradi els llindars establerts.

Martin també ha admès públicament que apilar totes les modalitats de prova en cada tasca pot ser excessiu. Això impedeix convertir el missatge en una recepta universal. La profunditat del control s’ha d’ajustar a la criticitat, al cost d’una fallada i a la capacitat real de detectar-la abans que arribi als usuaris.

Verificació de les afirmacions del vídeo

Les xifres de visualitzacions i “m’agrada” del fil només descriuen una captura concreta i canvien contínuament. No aporten validesa tècnica a l’argument.

La diferència entre provar la implementació i provar la intenció

Un test automatitzat respon una pregunta concreta: “Amb aquesta entrada i aquest estat, el sistema produeix el resultat esperat?”. Si la pregunta està ben plantejada, la resposta és útil. Si el test codifica una expectativa equivocada, el resultat verd només confirma que el codi i el test comparteixen el mateix error.

Aquest és el problema de l’oracle de proves: algú ha de decidir quin resultat és correcte. Un agent pot escriure la funció i el test a partir de la mateixa interpretació incompleta del requisit. Tots dos artefactes encaixaran entre ells, encara que no resolguin el problema real de l’usuari.

Un exemple simple:

1. El requisit diu que un descompte és per a clients “actius”.
2. L’agent interpreta que actiu significa haver iniciat sessió durant els últims 30 dies.
3. El negoci volia dir tenir una subscripció pagada vigent.
4. L’agent escriu la implementació i un test amb la primera definició.
5. Tota la suite passa, però el producte aplica descomptes incorrectament.

Cap percentatge de cobertura arregla per si sol aquesta discrepància. Cal que una persona amb coneixement del domini revisi el contracte, els exemples o el comportament final.

Què aporta cada capa del “guant” de verificació?

La força no prové d’una capa perfecta, sinó de combinar controls amb errors diferents. Si totes les verificacions depenen de la mateixa interpretació de l’agent, les seves mancances poden estar correlacionades.

Gherkin: fer executable el llenguatge del negoci

Gherkin estructura exemples amb Given, When i Then: context, acció i resultat observable. La documentació de Cucumber recomana expressar regles del domini i evitar detalls d’implementació.

Un escenari útil seria:

Característica: límit de votació

  Escenari: un usuari no pot votar dues vegades la mateixa opció
    Donat que l'usuari ja ha votat l'opció A
    Quan intenta tornar a votar l'opció A
    Aleshores el segon vot no s'ha de comptabilitzar
    I l'usuari ha de rebre una explicació clara

Aquest contracte és més fàcil de discutir amb producte que una implementació concreta de la base de dades. També sobreviu millor a una reescriptura tècnica. Però continua exigint preguntes: què identifica un usuari?, pot canviar de dispositiu?, què passa amb un vot simultani?, hi ha anul·lacions?, quina és la política de privadesa?

Gherkin ajuda a fer visible la intenció; no la descobreix automàticament.

Per què la cobertura no és suficient

La cobertura indica que una línia o branca s’ha executat durant la suite. No indica que el test hagi comprovat el resultat correcte. Un test sense assercions pot produir cobertura elevada i no detectar cap regressió.

Google ho formula de manera directa en la seva guia de revisió: els tests no es proven a si mateixos i una persona ha d’avaluar si són vàlids, sensats i útils. La mateixa guia demana examinar disseny, funcionalitat, complexitat, concurrència, noms, documentació i context global, aspectes que una xifra de cobertura no resumeix.

L’anàlisi recent de 4.882 pull requests generades per agents també mostra una xarxa de seguretat desigual: en l’estudi, els agents només van afegir canvis de tests en aproximadament la meitat dels PR que modificaven codi cobert, i moltes línies modificades no eren executades per cap test existent. És una fotografia d’un conjunt de dades, no una llei universal, però qüestiona la idea que “codi d’agent” impliqui automàticament “tests suficients”.

Què millora el mutation testing?

Les proves de mutació introdueixen deliberadament petits defectes: canvien >= per >, inverteixen una condició o substitueixen un retorn. Després executen la suite. Si els tests fallen, el mutant ha estat “eliminat”; si tot continua verd, pot faltar una comprovació útil.

És un control més informatiu que la cobertura simple perquè pregunta si els tests reaccionen davant un canvi de comportament. Tanmateix, conserva límits importants:

• els mutants són aproximacions a errors possibles, no tots els defectes reals;
• una puntuació alta pot coexistir amb un requisit completament absent;
• pot ser costós en repositoris grans;
• els mutants equivalents no canvien el comportament observable però poden semblar supervivents;
• no substitueix proves de rendiment, seguretat, recuperació o experiència d’usuari.

Un estudi de replicació publicat el 2026 conclou que la utilitat de cobertura i mutació depèn del context. Poden ser senyals útils per comparar suites en alguns entorns, però perden força quan el codi sota prova ja pot contenir l’error que s’intenta descobrir.

El punt fort de Midudev: infraestructura i escala

Midudev explica que una web de La Velada va patir pantalles en blanc de manera intermitent durant un pic molt gran de visites i votacions. Segons el seu relat, la lògica de prediccions i la implementació semblaven correctes, però la combinació d’escala i comportament del tallafoc de Vercel va generar un problema que no havia quedat cobert.

L’exemple il·lustra una distinció important: correctesa funcional no és fiabilitat operativa. Una funció pot retornar sempre el valor correcte i el sistema pot fallar per saturació, límits de taxa, latència, cues, connexions, memòria, dependències o configuració del WAF.

Vercel documenta que les regles de rate limiting poden agrupar peticions per IP, capçalera o empremta i respondre amb bloqueig, desafiament o codi 429. Configurar la regla requereix observar trànsit i comprovar-ne l’efecte. Cap test unitari d’una funció de votació pot reproduir, per si sol, la interacció completa entre milions de peticions i una política de xarxa.

Per a aquest tipus de risc calen altres controls:

• proves de càrrega en un entorn autoritzat;
• pressupostos de latència i capacitat;
• límits de taxa alineats amb el flux d’usuari;
• mètriques, traces i registres útils;
• alarmes per errors i saturació;
• proves de degradació i recuperació;
• desplegaments canari i reversió ràpida;
• simulació de dependències lentes o caigudes.

El relat concret de La Velada no es pot auditar amb el vídeo, però la lliçó tècnica és coherent amb les pràctiques de fiabilitat.

Quan pot tenir sentit no llegir cada línia?

La proposta de Martin és més defensable quan coincideixen diverses condicions:

1. El component és petit i té límits clars.
2. El comportament es pot expressar amb entrades i sortides deterministes.
3. Hi ha una especificació executable revisada per algú que entén el domini.
4. Les proves no depenen exclusivament de la mateixa generació que la implementació.
5. El CI bloqueja realment els canvis que incompleixen els llindars.
6. L’anàlisi estàtica i de dependències s’executa automàticament.
7. El canvi es pot revertir fàcilment.
8. Hi ha observabilitat suficient per detectar errors residuals.
9. El cost d’una fallada és limitat.
10. Una persona competent manté la responsabilitat sobre arquitectura i resultats.

Exemples possibles són eines internes petites, transformacions de dades reversibles, adaptadors simples o codi generat a partir d’un esquema estable. Fins i tot aquí és prudent revisar selectivament les parts sensibles i mostrejar el resultat.

Quan no s’hauria d’aplicar com a eslògan

NIST recomana que el desenvolupament segur combini requisits, revisió, anàlisi i proves durant el cicle de vida. OWASP defensa que la revisió manual complementa les eines automàtiques, sobretot en lògica de negoci, criptografia, configuració i arquitectura. GitHub també recomana verificar intenció, dependències, qualitat i errors específics de la IA, a més d’executar tests i anàlisi estàtica.

No hi ha contradicció: l’automatització pot absorbir comprovacions repetitives i permetre que les persones concentrin l’atenció allà on el judici aporta més valor.

Una política de revisió proporcional al risc

En lloc d’escollir entre “llegir-ho tot” i “no llegir res”, un equip pot definir nivells.

La mida del canvi també importa. Google recomana canvis petits perquè són més ràpids d’entendre i menys propensos a ocultar problemes. Un agent que produeix milers de línies en una sola proposta pot generar una falsa eficiència: escriure és ràpid, però validar continua sent car.

Per què els principiants sí que haurien de revisar el codi

Midudev insisteix que qui comença és precisament qui més ha de llegir el resultat. Té sentit pedagògic: un desenvolupador novell encara està construint el model mental que li permet detectar una abstracció inadequada, una consulta insegura o una dependència inventada.

Una bona regla d’aprenentatge és no incorporar cap canvi que no es pugui:

• explicar amb paraules pròpies;
• executar i depurar;
• relacionar amb el requisit;
• modificar sense demanar a la IA que ho refaci tot;
• provar amb un cas feliç, un límit i un error;
• situar dins de l’arquitectura del projecte;
• revertir si causa una regressió.

Utilitzar l’agent per proposar tests, explicar alternatives o buscar casos límit pot accelerar l’aprenentatge. Acceptar respostes verdes sense entendre-les pot produir dependència i impedir adquirir criteri.

L’enginyer de producte i la lògica de negoci

El tram final del vídeo amplia el debat: el valor del programador no és només escriure sintaxi. És entendre per què existeix el producte, quins processos transforma, què necessita l’usuari i quins costos té una decisió.

Aquest coneixement millora el treball amb agents perquè permet:

• formular requisits menys ambigus;
• detectar quan la IA resol el problema equivocat;
• prioritzar casos límit amb impacte real;
• distingir una preferència tècnica d’una regla de negoci;
• anticipar efectes sobre suport, operacions i dades;
• validar si la funcionalitat aporta valor;
• decidir què no s’ha d’automatitzar.

Dir que aquest perfil “no serà substituït” seria massa categòric. Però el coneixement del domini és difícil de comprimir en un únic prompt, sovint està repartit entre persones i processos, i resulta essencial per crear els oracles que decideixen si el programari és correcte.

Flux recomanat per treballar amb codi d’agents

Un procés equilibrat pot ser aquest:

1. Definir el resultat. Escriure objectiu, exclusions, riscos i criteris d’acceptació abans de generar codi.
2. Classificar la criticitat. Identificar dades, diners, permisos, irreversibilitat, concurrència i superfície pública.
3. Dividir el canvi. Demanar unitats petites i revisables, no una reescriptura massiva.
4. Separar especificació i implementació. Revisar primer els exemples de negoci; idealment, usar una font o un revisor diferent per als tests clau.
5. Executar portes deterministes. Compilació, tipus, format, lint, tests, cobertura, dependències i anàlisi estàtica.
6. Mesurar la qualitat dels tests. Introduir proves negatives i de mutació quan el cost ho justifiqui.
7. Revisar amb focus. Examinar arquitectura, seguretat, lògica de negoci, errors, concurrència i dependències noves.
8. Provar el sistema real. Fer una demostració o E2E i, si cal, càrrega i fallades parcials.
9. Desplegar gradualment. Usar feature flags, canari, mètriques i capacitat de reversió.
10. Aprendre dels incidents. Cada error que escapa ha de convertir-se en una nova prova, regla o millora d’observabilitat.

Aquest flux no obliga a llegir amb la mateixa intensitat cada línia. Concentra el judici segons el risc i manté proves independents de la narrativa de l’agent.

Preguntes freqüents

Uncle Bob recomana fer vibe coding?

No en el sentit habitual d’acceptar resultats per intuïció. Descriu un entorn fortament restringit, amb especificacions i proves. El titular “no reviso el codi” sense aquest context és enganyós.

Si tots els tests passen, el codi és correcte?

Només respecte dels comportaments que els tests comproven. Pot haver-hi requisits absents, assercions equivocades, vulnerabilitats, problemes de rendiment o interaccions que la suite no representa.

Una cobertura del 100% és suficient?

No. Significa que les línies o branques mesurades s’han executat, no que cada resultat s’hagi verificat bé. Cal inspeccionar la qualitat de les assercions i els casos.

Les proves de mutació resolen el problema?

Milloren el senyal perquè comproven si la suite detecta petits defectes deliberats. No descobreixen automàticament una regla de negoci que ningú ha especificat ni substitueixen les proves de seguretat, integració o operació.

Pot una IA revisar el codi escrit per una altra IA?

Pot aportar una segona perspectiva i trobar problemes, sobretot si usa instruccions, context o eines diferents. No és independència perfecta: els models poden compartir patrons i punts cecs. En canvis crítics, la responsabilitat continua requerint persones qualificades.

Cal revisar cada línia de codi generat?

Depèn del risc i de les garanties externes. Per a una transformació petita, reversible i ben especificada, pot bastar una revisió selectiva amb proves fortes. Per a permisos, diners, dades o infraestructura, és prudent una revisió profunda i especialitzada.

Què ha de fer un desenvolupador júnior?

Llegir el canvi, executar-lo, depurar-lo, explicar-lo i modificar-lo. Pot fer servir la IA com a tutor i accelerador, però no hauria d’aprovar codi que no entén.

Conclusió

Uncle Bob no ha abandonat la disciplina del programari: n’ha desplaçat el centre. Quan els agents poden escriure molt més ràpid que una persona, la verificació no pot dependre només de llegir el diff. Es necessiten contractes executables, restriccions mecàniques, proves de diferents nivells, anàlisi i observabilitat.

Midudev encerta en el límit principal: el mètode no es pot copiar sense copiar també el context, el criteri i la infraestructura que el fan viable. Un petit programa determinista no és un servei heretat amb dades, concurrència, tercers i pics de trànsit.

La pregunta útil no és “hem de revisar el codi de la IA?”. És: quina evidència independent necessitem per confiar en aquest canvi, donat el seu impacte? A vegades serà una suite i una inspecció selectiva. Altres vegades caldran revisió humana completa, especialistes en seguretat, proves de càrrega i desplegaments controlats.

L’objectiu no és defensar la lectura manual ni eliminar-la. És construir un procés on la velocitat de generació no superi la capacitat de comprendre, validar i operar el programari amb responsabilitat.

Article verificat amb informació disponible el 31 de juliol de 2026. Les publicacions i mètriques de X poden canviar o desaparèixer.