Un dezvoltator solicită unui asistent o funcție care verifică dacă un utilizator poate descărca un raport. Codul se compilează. Testul „happy-path” trece. Cererea de extragere arată impecabil. Două săptămâni mai târziu, un coleg observă că funcția verifică dacă utilizatorul este conectat, dar nu verifică niciodată dacă raportul îi aparține.
Acesta este un scenariu ilustrativ, nu un incident documentat. Descrie lacuna pe care trebuie să o acopere instruirea pentru revizuirea codului generat de inteligența artificială: codul generat care trece o verificare de bază poate conține în continuare o eroare de autorizare sau de concurență, iar persoana care îl revizuiește trebuie să o găsească și să explice de ce este importantă.
Acest ghid este destinat liderilor în domeniul capacitării în inginerie și managerilor de inginerie. Acesta acoperă modul de descriere a problemei de performanță, diagnosticarea lacunelor, pregătirea și practica designului, lucrul cu un caz concret și evaluarea dacă abilitățile se transferă în revizuiri reale. Este vorba despre designul instruirii. Fiecare defect, regulă de testare și revizuire din programul dvs. ar trebui validată de inginerii seniori și de echipa dvs. de securitate.
Ce este instruirea pentru revizuirea codului generat de inteligența artificială?
Instruirea pentru revizuirea codului generat de inteligența artificială îi învață pe dezvoltatori să instruiască clar un asistent, apoi să evalueze și să auditeze ce se întoarce: este corect, este sigur, se comportă sub sarcină concurentă, este suficient de eficient? Nu este un curs despre un anumit instrument. Își formează un obicei de revizuire care rămâne același atunci când instrumentul se schimbă.
Scurte
| Întrebare | Răspuns scurt |
|---|---|
| Care este sarcina? | Auditați codul generat și justificați fiecare risc cu un test. |
| Ce punctaj obții? | Calitatea verificării și dacă au fost găsite defectele relevante. |
| Este suficient un test despre regulile de codare sigură? | Nu. Confirmă condițiile preliminare, dar nu dacă un dezvoltator poate identifica o eroare în cod care pare plauzibilă. |
| Cine validează conținutul? | Un manager de inginerie și echipa dumneavoastră de securitate. |
| Ce nu poate rezolva antrenamentul? | Timpul de revizuire, instrumentele, proprietatea neclară și presiunea de a fuziona rapid. |
| De unde știi că a funcționat? | Un exercițiu de cod nou, nevăzut, evaluat în funcție de criterii convenite, cu urmărire pe baza unor recenzii reale. |
1. Descrieți problema de performanță
Începeți cu sarcina: auditați codul generat și fundamentați riscurile cu teste. Auditarea înseamnă citirea cu suspiciune. Fundamentarea înseamnă transformarea unei suspiciuni în dovezi, de obicei un test care eșuează sau o reproducere care arată defectul.
Cercetarea sugerează de ce este nevoie de o practică deliberată în acest sens. Într-un studiu realizat pe GitHub Copilot, Pearce și colegii săi au generat 1,689 de programe în 89 de scenarii alese pentru tipuri de vulnerabilități cunoscute și au descoperit că aproximativ 40% dintre acestea erau vulnerabile (Pearce și colegii săi, 2021). Acesta a fost un instrument timpuriu și un set specific de scenarii, așa că nu tratați cifra ca o rată pentru asistenții de astăzi. Un studiu separat privind utilizatorii a cerut participanților să scrie cod cu și fără un asistent de inteligență artificială. Cei cu asistent au scris cod semnificativ mai puțin sigur și au fost mai predispuși să creadă că codul lor este sigur (Perry și colegii săi, 2023Același studiu a constatat că participanții care au avut mai puțină încredere în asistent și au fost mai implicați în solicitările acestuia au produs mai puține vulnerabilități.
Urmează două lecții pentru proiectarea instruirii. Un rezultat plauzibil are nevoie de un evaluator activ. Iar încrederea nu este o dovadă, așadar exercițiul trebuie să solicite un test, nu o opinie.
Scrieți declarația de performanță într-o singură propoziție și rugați un manager de inginerie să o verifice: „Având în vedere o modificare generată, dezvoltatorul enumeră riscurile de securitate, concurență și eficiență pe care le observă și, pentru fiecare dintre ele, descrie sau scrie un test care ar demonstra acest lucru.”
2. Diagnosticați lacunele de învățare și context
Înainte de a construi orice, comparați sarcina cu ceea ce practică și evaluează programul dumneavoastră actual. Trei întrebări diferențiază de obicei o lacună în instruire de altceva:
- Practica actuală folosește sarcina reală? Dacă instruirea acoperă scrierea promptă, dar nu le cere niciodată dezvoltatorilor să revizuiască rezultatul, nimeni nu a practicat auditarea. Dacă evaluarea este un test cu variante multiple de răspuns privind regulile de codare sigure, aceasta măsoară reamintirea.
- Care este cererea cognitivă? În taxonomia revizuită a lui Bloom, evaluarea siguranței codului și alegerea testului care îl dovedește se află la nivelurile de analiză și evaluare, precum și proiectarea unui prompt mai bun sau a unei corecții ajunge la nivelul de creare. Potrivirea activităților cu aceste niveluri este acoperită în ghidul nostru pentru potrivirea activităților de învățare cu taxonomia lui Bloom.
- Oare altceva în afară de abilitate intervine în cale? Verificați timpul de revizuire, instrumentele și responsabilitatea. Dacă recenzenții au la dispoziție cinci minute pentru fiecare solicitare de extragere, nicio instruire nu va produce un audit. Dacă nu există o analiză statică sau un sistem de testare în curs de desfășurare, un dezvoltator poate identifica un risc, dar nu îl poate justifica. Raportați cauzele care nu țin de instruire persoanelor care le pot remedia.
3. Pregătirea și practica designului
După ce știi ce lacune poate fi acoperită de antrenament, acordă fiecărei etape o sarcină distinctă.
Pregătirea. Verificați cerințele preliminare cu o scurtă diagnosticare: categoriile comune de puncte slabe cu care se confruntă stiva dvs., modul în care sunt structurate testele dvs., lista de verificare pentru revizuire utilizată de echipa dvs. Studiul în ritm propriu se potrivește acestei etape. O verificare a reamintirii confirmă doar cerințele preliminare.
Practică. Folosește exerciții de audit construite din cod generat realist. Seminează fiecare cu un număr mic de defecte de diferite tipuri, cum ar fi o verificare a proprietății lipsă, o concurență între două cereri și o buclă ineficientă, plus niște cod care este în regulă. Dezvoltatorul analizează, numește fiecare risc, spune cât de grav este și propune testul care l-ar demonstra. Cere raționament, nu o listă de numere de linii.
Parere. Leagă-l de decizii, mai degrabă decât de un scor total. „Ai semnalat bucla, dar nu și cursa pe contorul partajat, iar testul tău nu l-ar fi detectat deoarece rulează cererile pe rând” este mai util decât „2 din 3 găsite”.
Intrare în timp real sau revizuire asincronă? Intrarea în timp real adaugă cea mai mare valoare atunci când un risc este ambiguu, iar dezvoltatorii învață ascultând un inginer senior explicând de ce ar bloca îmbinarea. Revizuirea asincronă este suficientă pentru a compara concluziile unui dezvoltator cu o revizuire adnotată a unui expert. Multe echipe folosesc ambele: mai întâi pregătirea în ritm propriu, apoi o sesiune facilitată pe cazurile dificile.
4. Lucrează printr-un exemplu realist
Ilustrativ. Un manager de inginerie ar trebui să valideze cazul și criteriile de răspuns înainte de utilizare.
Cazul. Un endpoint generat returnează factura unui client după ID-ul facturii. Verifică dacă apelantul are o sesiune validă, utilizează o interogare parametrizată și trece testul de bază. Aceeași funcție incrementează un contor de descărcări partajat fără blocare.
Sarcina. Dezvoltatorul enumeră fiecare risc pe care îl observă, le clasifică și descrie testul care l-ar confirma pe fiecare.
O primă încercare. „Arată în regulă. Interogarea este parametrizată și testul trece.” Dezvoltatorul a tratat trecerea testului ca o dovadă și nu a întrebat ce nu acoperă testul.
Feedback și reîncercare. Recenzentul îi cere dezvoltatorului să numească ce dovedește și ce nu dovedește verificarea sesiunii. Reîncercarea îi cere să ia în considerare doi clienți diferiți și două solicitări simultane.
O încercare mai puternică. „Verificarea sesiunii dovedește cine apelează, nu că factura este a lui. Aș scrie un test în care clientul A solicită ID-ul facturii clientului B și se așteaptă la un refuz. Contorul este incrementat fără sincronizare, astfel încât două solicitări simultane ar putea pierde o actualizare. Aș rula un test concurent și aș compara numărul. Interogarea în sine este parametrizată, deci nu aș pierde timp acolo.” Observați că acest răspuns clasifică riscurile și leagă fiecare de un test.
De ce fiecare răspuns este justificabil sau incomplet. Evaluează fiecare în funcție de criteriile aprobate, nu de preferințele evaluatorului. Prima încercare urmează un obicei, dar omite dovezile. Încercarea mai puternică este specifică, prioritizată și testabilă.
5. Evaluarea capacității și planificarea transferului
Dovada capacității este performanța la un exercițiu nou pe care cursantul nu l-a văzut. Calitatea verificării scorului și identificarea defectelor relevante. O rubrică simplă folosește o scală de la 0 la 2 pentru fiecare criteriu:
| Criteriu | Dovezi observabile |
|---|---|
| Executarea sarcinilor | Auditează codul generat și înregistrează dovezile din spatele fiecărei constatări. |
| Raţionament | Explică constrângerile, alternativele și ceea ce rămâne incert și clasifică riscurile. |
| Limite | Respectă regulile de revizuire ale echipei și se adresează unui specialist în securitate atunci când riscul depășește atribuțiile sale. |
Ancore: 0 este absent sau neacceptat, 1 este parțial cu omisiuni relevante, iar 2 este complet și justificat în funcție de criteriile convenite. Definiți separat erorile critice, cum ar fi aprobarea codului cu o cale de acces neprotejată, astfel încât un scor general să nu poată ascunde una. Această rubrică este o propunere, nu un standard de pregătire validat: adaptați-o cu un manager de inginerie și testați-o. Ghidul nostru pentru proiectarea unei practici interactive cu feedback util arată cum se scrie feedback care se leagă de decizii.
Planificați transferul în mod deliberat. După exercițiu, asociați fiecărui dezvoltator o cerere reală de extragere (pull request) care include codul generat și analizați împreună constatările lor sau realizați o scurtă retrospectivă a unei analize recente care a omis ceva.
Unde ajută livrarea interactivă
Formatele interactive sunt utile acolo unde toată lumea ar trebui să își facă un angajament înainte de a vedea grupul. Într-o sesiune live, un facilitator poate afișa un fragment generat, poate ruga fiecare dezvoltator să introducă riscurile pe care le observă și testul pe care l-ar scrie, apoi poate dezvălui distribuția înainte de discuție. Același exercițiu poate fi rulat în ritm propriu pentru pregătire. AhaSlides acceptă învățarea interactivă și trecerea de la livrarea live la cea în ritm propriu. Este un instrument de prezentare și învățare, nu un loc pentru a rula cod, așa că rulați exercițiile de cod în propriul mediu. Verificați orice funcție specifică de creare, feedback sau raportare pe care intenționați să vă bazați în raport cu propriul flux de lucru. Pentru îndrumări privind alegerea formatelor, consultați articolul nostru despre când să folosim învățarea adaptivă, interactivă și live.
Măsoară ce s-a schimbat
Decideți în avans ce ar demonstra că dezvoltatorii pot îndeplini sarcina. Comparați calitatea verificării și identificarea defectelor într-un exercițiu nevăzut cu o bază. Definiți cine este inclus, numitorul și momentul. Dacă rezultatele se îmbunătățesc, verificați ce s-a mai schimbat în aceeași perioadă, cum ar fi o nouă regulă de analiză statică, o listă de verificare revizuită sau o schimbare de asistent, înainte de a acorda credit instruirii.
Constrângeri care pot rămâne
- Timp de revizuire. Un audit durează mai mult decât o recenzie parcursă, iar termenele limită se apropie de recenzie.
- Scule. Fără un sistem de testare sau o scanare în curs de desfășurare, un risc este greu de justificat.
- Schimbarea instrumentelor. Asistenții se schimbă rapid, așa că exercițiile se concentrează pe obiceiul de a recenza, nu pe un singur produs.
- Acoperirea cazului. Un exercițiu prezintă câteva tipuri de defecte. Un scor nu descrie judecata unui dezvoltator în general.
- Transfer. Performanța într-un atelier nu este aceeași cu performanța într-o coadă aglomerată de recenzii.
Numiți-le sponsorilor din timp și planificați remedieri separate. Instruirea îmbunătățește ceea ce un dezvoltator poate găsi și demonstra. Nu creează timpul sau instrumentele necesare.
Întrebări frecvente
Ce este instruirea pentru revizuirea codului generat de inteligența artificială?
Îi învață pe dezvoltatori să solicite, să evalueze și să auditeze codul produs de un asistent de inteligență artificială, identificând probleme de securitate, concurență și eficiență și susținând fiecare problemă cu un test.
Este codul generat mai puțin sigur decât codul uman?
Studiile indică existența unui risc, însă rezultatele depind de instrument, sarcină și designul studiului. Un studiu realizat cu utilizatori a constatat că participanții cu un asistent au scris cod mai puțin sigur și s-au simțit mai încrezători în legătură cu acesta, ceea ce reprezintă un motiv pentru a antrena obiceiul de a revizui.
Cum evaluezi dacă dezvoltatorii pot audita codul generat?
Dați un nou exercițiu de codare și verificați calitatea scorului și identificarea defectelor în funcție de criteriile convenite. Un test despre regulile de codare sigură confirmă doar cerințele preliminare.
Ai nevoie de un sandbox de cod pentru antrenament?
Ai nevoie de un loc unde să faci exercițiile, care de obicei este propriul tău mediu. Verifică dacă orice instrument pe care îl folosești este compatibil cu ceea ce ai nevoie înainte de a te baza pe el.
Unde să încep
Alegeți un tip recurent de modificare generată în baza de cod. Scrieți declarația de performanță, rugați un manager de inginerie să valideze defectele inițiale și testele care le-ar evidenția și elaborați o rubrică cu trei criterii, cu o scală de la 0 la 2 și o listă de erori critice. Testați-o cu un grup mic înainte de a o implementa.
Pentru a vedea cum un exercițiu de audit ar putea fi derulat live cu propria echipă și reutilizat ulterior în ritmul propriu, explorează AhaSlides.
