Cum revizuiești codul generat de AI

Pentru a revizui codul generat de AI, începe cu ce s-a schimbat — ce fișiere și de ce — apoi testează comportamentul tu însuți înainte să citești vreo linie de cod. După aceea, verifică zonele în care codul AI greșește cel mai des: lipsa verificărilor de permisiuni pe server, secrete expuse browserului, date de intrare nevalidate, pachete sau funcții care nu există și modificări ale lucrurilor pe care nu i-ai cerut să le atingă.

AI-ul scrie cod care de obicei rulează și adesea arată îngrijit. Asta face ușor să aprobi fără să verifici cu adevărat. Acest ghid este o rutină de revizuire care funcționează indiferent dacă citești cod fluent sau deloc.

Adaptează revizuirea la risc

Nu fiecare schimbare cere aceeași atenție.

Pasul 1: Vezi ce s-a schimbat

Înainte să judeci codul, obține lista modificărilor:

• Dacă proiectul este în Git, uită-te la diff: fișierele și liniile modificate de la ultimul commit. Vezi cum folosești Git cu o aplicație construită cu AI.
• Sau întreabă direct AI-ul:

Listează fiecare fișier pe care l-ai modificat în ultima schimbare și, pentru fiecare, explică într-o propoziție ce s-a schimbat și de ce.

Semnale de alarmă în acest stadiu: fișiere fără legătură cu cererea, fișiere șterse, modificări ale configurării sau dependențelor pe care nu le-ai cerut.

Pasul 2: Testează mai întâi comportamentul

Citirea codului îți spune ce ar trebui să facă; testarea îți spune ce face de fapt. Înainte să citești:

• Încearcă schimbarea ca un utilizator obișnuit, pe desktop și pe un ecran de telefon.
• Încearcă cu date de intrare greșite: câmpuri goale, text foarte lung, numere negative, o dată din trecut.
• Încearcă deconectat și ca alt utilizator.
• Reia fluxurile cele mai importante: înregistrare, autentificare, acțiunea principală, plata.

Dacă testarea eșuează, ți-ai economisit timp de citire — raportează clar și lasă AI-ul să repare. Vezi cum scrii un bun raport de eroare.

Pasul 3: Verifică permisiunile pe server

Cel mai important lucru de verificat. Instrumentele AI ascund adesea un buton în pagină, dar lasă serverul dispus să facă acțiunea pentru oricine o cere.

Pentru fiecare rută sau funcție care citește sau modifică date, întreabă:

• Verifică dacă utilizatorul este autentificat?
• Verifică dacă acest utilizator are voie să acceseze această înregistrare?
• Verificarea este pe server, nu doar în pagină?

Pentru fiecare rută API pe care ai adăugat-o sau modificat-o, spune-mi ce verificare de permisiune face pe server, citând linia. Semnalează orice rută fără una.

Apoi testeaz-o: autentifică-te ca utilizatorul A, notează ID-ul unei înregistrări, autentifică-te apoi ca utilizatorul B și cere-o. Lista de verificare de securitate pentru aplicațiile construite cu AI conține testul complet.

Pasul 4: Caută secrete expuse

• Caută în fișierele modificate orice ce seamănă cu o cheie sau o parolă.
• Verifică dacă cheile secrete sunt citite din variabile de mediu și folosite doar în codul de server.
• Atenție la prefixele publice, cum ar fi VITE_ sau NEXT_PUBLIC_, puse pe variabile secrete — acestea sunt încorporate în codul din browser.

Vezi cum păstrezi în siguranță cheile API.

Pasul 5: Verifică datele de intrare și erorile

• Validare pe server. Verificările din browser pot fi ocolite. Câmpurile obligatorii, lungimile, formatele și valorile permise trebuie verificate și de server.
• Interogările din baza de date folosesc parametri, nu text construit prin lipirea datelor utilizatorului în interogare.
• Erorile nu sunt înghițite. Un try/catch care nu face nimic ascunde eșecurile. Erorile trebuie înregistrate, iar utilizatorii trebuie să vadă un mesaj simplu.
• Niciun detaliu intern nu ajunge la utilizatori — urmele de stivă și erorile bazei de date aparțin jurnalelor.

Pasul 6: Verifică dacă e real

Modelele AI produc uneori cod care arată corect, dar se referă la lucruri care nu există.

• Pachete: fiecare dependență nouă trebuie să fie un pachet real, întreținut, cu exact acel nume. Fii atent la nume care par greșeli de scriere ale unor pachete populare.
• Funcții și opțiuni API: dacă codul apelează o funcție de bibliotecă sau o opțiune de API externă pe care nu ai mai văzut-o, verifică documentația oficială.
• Cod de tip placeholder: caută TODO, mock, fake, date de exemplu scrise direct în cod sau funcții care returnează o valoare fixă.

Ai adăugat pachete noi? Pentru fiecare, dă-mi numele exact, la ce servește și dacă am putea renunța la el.

Pasul 7: Verifică dacă se potrivește

Codul poate funcționa și totuși să facă aplicația mai greu de schimbat mai târziu:

• Duplicare. Aceeași logică copiată în mai multe locuri se va desincroniza.
• Consecvență. Trebuie să urmeze tiparele pe care le folosește restul aplicației.
• Dimensiune. O cerere de 20 de linii care a produs 600 de linii merită o întrebare.
• Cod mort. Versiuni vechi lăsate în urma celor noi.

Există cod în proiect care acum nu mai este folosit din cauza acestei schimbări sau logică duplicată în altă parte? Nu schimba nimic; doar listează.

Greșeli frecvente

• Aprobi pentru că arată curat. Codul îngrijit poate să sară peste o verificare de permisiune.
• Citești în loc să testezi. Testează mai întâi; citește după.
• Testezi doar cazul fericit. Încearcă date greșite, utilizatorul greșit și deconectarea.
• Ignori modificările fișierelor fără legătură. Întreabă de ce s-au schimbat toate fișierele.
• Încrezi complet într-o autoevaluare. Folosește revizuirea AI-ului ca primă trecere și confirmă prin testare.
• Revizuiești o săptămână de schimbări deodată. Revizuiește schimbările mici pe măsură ce apar.

Listă de verificare

• Știu ce fișiere s-au schimbat și de ce, iar nimic fără legătură nu s-a schimbat.
• Schimbarea funcționează pe desktop și pe telefon, cu date greșite, deconectat și ca alt utilizator.
• Fiecare rută care lucrează cu date verifică autentificarea și proprietatea pe server.
• Niciun secret în cod sau în pachetele din browser.
• Datele de intrare sunt validate pe server; interogările folosesc parametri.
• Erorile sunt înregistrate, nu înghițite, și nu sunt arătate în detaliu utilizatorilor.
• Pachetele noi sunt reale și necesare; nu mai rămân funcții inventate sau placeholdere.
• Schimbările cu risc mare au avut o citire atentă și, dacă e cazul, un al doilea revizor.

Revizuirea codului pe Mythex

• Modul Ask răspunde la întrebări despre cod fără să îl editeze — ideal pentru cereri de tipul „explică fiecare schimbare” și „ce rute nu au o verificare de permisiune”. Vezi Chat.
• Vizualizarea de cod arată arborele de fișiere, editorul și terminalul pe fiecare plan (doar citire pe Free, editabilă pe Pro), ca să poți citi tu ce s-a schimbat. Vezi Editorul de cod.
• /test cere agentului să navigheze prin previzualizare ca un utilizator și să raporteze fluxurile defecte.
• Checkpoint-urile îți permit să anulezi o schimbare care nu trece revizuirea.

Dacă un dezvoltator revizuiește în locul tău, cum lucrezi cu un dezvoltator la o aplicație construită cu AI acoperă predarea; dacă revizuirea scoate la iveală un bug, vezi cum depanezi o aplicație construită cu AI.

Întrebări