Com revisar codi generat per IA

Per revisar codi generat per IA, comença per allò que ha canviat —quins fitxers i per què— i prova el comportament tu mateix abans de llegir cap línia de codi. Després, comprova les àrees on el codi d'IA sol fallar més: manca de comprovacions de permisos al servidor, secrets exposats al navegador, dades d'entrada sense validar, paquets o funcions que no existeixen, i modificacions de coses que mai no li vas demanar que toqués.

La IA escriu codi que normalment funciona i sovint té un aspecte net. Això fa que sigui fàcil aprovar-lo sense comprovar-lo de veritat. Aquesta guia és una rutina de revisió que funciona tant si llegeixes codi amb fluïdesa com si no el llegeixes gens.

Ajusta la revisió al risc

No tots els canvis necessiten la mateixa atenció.

Pas 1: mira què ha canviat

Abans de jutjar el codi, obtén la llista de canvis:

• Si el projecte està a Git, mira el diff: els fitxers i les línies que han canviat des del darrer commit. Consulta com fer servir Git amb una app construïda amb IA.
• O demana-ho directament a la IA:

Llista cada fitxer que has canviat en l'últim canvi, i per a cadascun explica en una frase què ha canviat i per què.

Senyals d'alerta en aquesta etapa: fitxers que no tenen relació amb la petició, fitxers esborrats, canvis a la configuració o a les dependències que no havies demanat.

Pas 2: prova primer el comportament

Llegir codi et diu què es suposa que fa; provar-lo et diu què fa de veritat. Abans de llegir:

• Prova el canvi com un usuari normal, en escriptori i en una pantalla de mida de telèfon.
• Prova-ho amb dades d'entrada incorrectes: camps buits, text molt llarg, nombres negatius, una data al passat.
• Prova-ho tancat la sessió i com un usuari diferent.
• Torna a provar els fluxos més importants: registre, inici de sessió, l'acció principal, el pagament.

Si la prova falla, t'has estalviat temps de lectura: informa-ne clarament i deixa que la IA ho arregli. Consulta com escriure un bon informe d'error.

Pas 3: comprova els permisos al servidor

És el punt més important. Les eines d'IA sovint amaguen un botó a la pàgina però deixen que el servidor faci l'acció a qualsevol que la demani.

Per a cada ruta o funció que llegeix o canvia dades, pregunta:

• Comprova que l'usuari ha iniciat sessió?
• Comprova que aquest usuari té permís per accedir a aquest registre?
• Aquesta comprovació és al servidor, no només a la pàgina?

Per a cada ruta d'API que has afegit o canviat, digues quina comprovació de permisos fa al servidor, citant la línia. Marca qualsevol ruta que no en tingui cap.

Després prova-ho: inicia sessió com a usuari A, anota l'ID d'un registre, inicia sessió com a usuari B i sol·licita'l. La llista de comprovació de seguretat per a apps fetes amb IA té la prova completa.

Pas 4: busca secrets exposats

• Cerca als fitxers canviats qualsevol cosa que sembli una clau o una contrasenya.
• Comprova que les claus secretes es llegeixen des de variables d'entorn i només s'usen al codi del servidor.
• Vigila els prefixos públics com VITE_ o NEXT_PUBLIC_ en variables secretes: aquests s'incorporen al codi del navegador.

Consulta com mantenir segures les claus d'API.

Pas 5: revisa les dades d'entrada i els errors

• Validació al servidor. Les comprovacions del navegador es poden saltar. Els camps obligatoris, les longituds, els formats i els valors permesos també els han de comprovar el servidor.
• Les consultes a la base de dades usen paràmetres, no text construït unint dades de l'usuari dins d'una consulta.
• Els errors no s'ignoren. Un try/catch que no fa res amaga els fallades. Els errors s'han de registrar, i els usuaris han de veure un missatge senzill.
• Cap detall intern als usuaris: els traces de pila i els errors de la base de dades pertanyen als registres.

Pas 6: comprova que és real

Els models d'IA de vegades produeixen codi que sembla correcte però fa referència a coses que no existeixen.

• Paquets: cada dependència nova ha de ser un paquet real, mantingut, amb exactament aquest nom. Desconfia dels noms que semblen errors tipogràfics de paquets populars.
• Funcions i opcions d'API: si el codi crida una funció de biblioteca o una opció d'una API externa que no has vist mai, comprova la documentació oficial.
• Codi de marcador de posició: cerca TODO, mock, fake, dades d'exemple codificades a mà, o funcions que retornen un valor fix.

Has afegit paquets nous? Per a cadascun, digues el nom exacte, per a què serveix i si podríem prescindir-ne.

Pas 7: comprova que encaixa

El codi pot funcionar i, tanmateix, fer que l'app sigui més difícil de canviar més endavant:

• Duplicació. La mateixa lògica copiada en diversos llocs es desviarà.
• Coherència. Ha de seguir els patrons que fa servir la resta de l'app.
• Mida. Una petició de 20 línies que ha produït 600 línies mereix una pregunta.
• Codi mort. Versions antigues que s'han quedat al costat de les noves.

Hi ha cap codi del projecte que ara no s'utilitzi a causa d'aquest canvi, o lògica duplicada en un altre lloc? No canviïs res; només enumera-ho.

Errors habituals

• Aprovar perquè sembla net. El codi polit pot saltar-se una comprovació de permisos.
• Llegir en lloc de provar. Prova primer; llegeix després.
• Provar només el camí feliç. Prova dades d'entrada incorrectes, l'usuari equivocat i la sessió tancada.
• Ignorar els canvis de fitxers no relacionats. Pregunta per què han canviat tots els fitxers.
• Confiar del tot en l'autorevisió de la IA. Fes servir la revisió de la IA com una primera passada i confirma-ho provant.
• Revisar una setmana de canvis de cop. Revisa els canvis petits a mesura que passen.

Llista de comprovació

• Sé quins fitxers han canviat i per què, i no ha canviat res que no tingui relació.
• El canvi funciona en escriptori i en telèfon, amb dades incorrectes, amb la sessió tancada i com a un altre usuari.
• Cada ruta de dades comprova l'inici de sessió i la propietat al servidor.
• Cap secret al codi ni als paquets del navegador.
• Les dades d'entrada es validen al servidor; les consultes usen paràmetres.
• Els errors es registren, no s'ignoren, i no es mostren amb detall als usuaris.
• Els paquets nous són reals i necessaris; no queden funcions inventades ni marcadors de posició.
• Els canvis d'alt risc han tingut una lectura atenta i, si cal, una segona persona revisora.

Revisar codi a Mythex

• El mode Ask respon preguntes sobre el codi sense editar-lo: ideal per a les peticions «explica cada canvi» i «quines rutes no tenen una comprovació de permisos». Consulta Xat.
• La vista de codi mostra l'arbre de fitxers, l'editor i el terminal en tots els plans (només lectura al pla Free, editable al Pro), perquè puguis llegir tu mateix què ha canviat. Consulta Editor de codi.
• /test fa que l'agent cliqui per la previsualització com un usuari i informi dels fluxos trencats.
• Els punts de control et permeten desfer un canvi que no passi la revisió.

Si una persona desenvolupadora revisa per tu, com treballar amb una persona desenvolupadora en una app feta amb IA explica el traspàs; si la revisió troba un error, consulta com depurar una app feta amb IA.

Preguntes