Are voie agentul să atingă codul ăsta?
7 min de citit
La finalul capitolului poți stabili condițiile necesare unui task, poți identifica lipsurile de pregătire și poți decide ce muncă poate continua în limite testate.
TL;DR
- Înainte de punctare, definește task-ul, reviewerul calificat, dovezile care ar expune o greșeală cu consecințe importante și permisiunile și recuperarea potrivite.
- Condițiile lipsă sau necunoscute restrâng task-ul afectat la investigație sau pregătire supravegheată. Un repository verde nu autorizează orice task din el.
- Folosește cele opt semnale ca ghid euristic de pregătire. Notează explicit necunoscutele; procentul de coverage singur nu stabilește dacă verificarea e suficientă.
Când n-ar trebui să folosești agenți AI de cod?¶
Unele codebase-uri n-ar trebui să primească încă un agent, iar un nu acolo e ceea ce îți permite să spui da peste tot în rest.
Motivul nu e că agentul ar fi prost sau echipa slabă: schimbarea propusă poate depăși capacitatea echipei de a o evalua, verifica sau limita consecințele. Stabilește întâi aceste condiții. Cele opt semnale ajută apoi la prioritizarea pregătirii; sunt un sprijin pentru discuție, desprins din practică, nu un model de risc validat.
Înainte de punctare: definește task-ul
| Condiție | Dovezi necesare |
|---|---|
| Scope | Comportamentul vizat, modulul și mediul afectate; acțiunile permise |
| Capacitate de evaluare | O persoană calificată care poate recunoaște un rezultat plauzibil, dar greșit |
| Verificare | Check-uri care expun greșelile cu consecințe importante pentru această schimbare, cu aserțiuni relevante și eșecuri interpretabile |
| Limite și recuperare | Accesul, aprobarea, deployment-ul și recuperarea potrivite consecințelor |
Dacă un răspuns lipsește sau e necunoscut, restrânge munca respectivă până rezolvi lacuna. Agentul poate totuși investiga un modul netestat sau poate propune teste de caracterizare sub supraveghere. Asta nu îl autorizează să schimbe comportamentul de business al modulului. Restricția urmărește task-ul afectat, nu orice activitate din repository.
Cele opt kill signals
Fiecare semnal strică lucrul agentului în felul lui, și fiecare are un prim fix.
| Semnal | Cum arată | Exemplu | Primul fix |
|---|---|---|---|
| 1. Fără teste | Nicio suită, sau una pe care n-o rulează nimeni | O modificare a stricat un modul de reconciliere netestat; a ieșit la suprafață abia după două luni | Teste de caracterizare |
| 2. Fără documentație | Doar autorul original știe de ce | Agentul a „simplificat” un fee tier care avea o excepție de reglementare din 2017 | Review-ul de arhitectură (Capitolul 7) |
| 3. Cuplare strânsă | Editezi un fișier, se strică alte trei | Trei module într-un ciclu de importuri vechi de 14 ani | Sparge cea mai gravă cuplare |
| 4. Reguli împrăștiate | Aceeași regulă trăiește în mai multe locuri | Limita de transfer într-un config de UI, o constantă din serviciu și un trigger din baza de date | O singură sursă de adevăr |
| 5. Constrângeri de reglementare | Fiecare schimbare cere o aprobare trasabilă | Schimbările de anti-money-laundering cer trei semnături pe care agentul nu le poate ruta | Workflow de aprobare |
| 6. Echipa nu poate evalua output-ul | Nimeni nu poate judeca rezultatul într-un anumit domeniu | Un junior livrează criptografie scrisă de agent (mai jos) | Restrânge scope-ul sau adaugă un reviewer expert |
| 7. Potrivirea model-context | Corpus public subțire (COBOL, DSL-uri proprietare) | Un workflow engine intern; agentul a aplicat pattern-uri dintr-un alt framework | Adaugă documentație și skill-uri sau alege un model cu potrivire mai bună |
| 8. Viteza schimbării | Un framework se mișcă sub agent | Idiomuri de React 18 în cod care avea nevoie de React 19 | Numește versiunea-țintă în AGENTS.md; încetinește agentul pe căile atinse |
Semnalul 1: fără teste
Stabilește verificarea relevantă înainte de schimbări de comportament; lasă agentul să ajute la pregătirea ei.
Cere-i agentului să propună teste de caracterizare pentru comportamentul actual, apoi pune un reviewer calificat să distingă comportamentul intenționat de bug-urile existente. Verifică rezultatele importante, cazurile de eșec, fiabilitatea și capacitatea echipei de a interpreta eșecurile. Dacă nicio dovadă disponibilă nu ar expune o greșeală cu consecințe importante, restrânge munca afectată la investigație sau pregătire supravegheată până există acele dovezi. Testele sunt o plasă de regresie, nu o dovadă de corectitudine (Capitolul 5).
Semnalul 6: echipa nu poate evalua output-ul
E cel mai important semnal și cel pe care echipele îl înțeleg greșit cel mai des.
Un developer junior primește un story: adaugă un pas de verificare criptografică în fluxul de plăți. Juniorul trimite agentul la treabă, iar agentul produce un modul care folosește AES-256 în mod CBC cu un initialization vector hardcodat. Pentru cineva nou în criptografie, arată corect: compilează, testele unitare trec, iar criptograful senior e în concediu de creștere a copilului trei luni. Juniorul livrează, iar vulnerabilitatea stă în producție șase luni, până o găsește un penetration test.
Agentul a făcut exact ce i s-a cerut. Output-ul lui arăta bine și era greșit, iar nimeni nu era în poziția de a vedea asta.
Echipele citesc asta ca „ne trebuie mai mulți ingineri seniori”, ceea ce nu scalează pe un orizont de șase luni. Pentru zonele sensibile, cere aprobarea unui specialist calificat printr-un review obligatoriu impus pe server, pe care credențialele agentului nu-l pot ocoli. Politica aplicată la nivel de tool poate împiedica și editarea acelor module. AGENTS.md poate explica restricția, iar agenții de review pot ajuta, dar niciunul nu înlocuiește expertiza lipsă și nu face aprobarea inevitabilă.
Semnalul ăsta încalcă condiția de evaluare, indiferent de total. Și alte semnale pot bloca un anumit task, inclusiv verificarea absentă sau o cale de aprobare indisponibilă. Construiește capacitatea lipsă, adu pe cineva care o are sau restrânge munca afectată. Un total mic nu anulează niciodată o condiție neîndeplinită.
Sunt agenții AI de cod gata de producție?¶
Pregătirea ține de un task și de controalele lui; culoarea repository-ului ajută doar la prioritizarea pregătirii.
Înainte de scor: definește task-ul, cine poate evalua rezultatul, dovezile care ar expune erorile importante, permisiunile și recuperarea. Lipsește ceva sau nu știi? Limitează acel task la investigație ori pregătire supravegheată.
- 1Verificare slabă a comportamentului afectat
- 2Fără documentație
- 3Cuplare strânsă
- 4Reguli împrăștiate
- 5Constrângeri de reglementare
- 6Nimeni calificat să evalueze rezultatul
- 7Potrivirea model-context
- 8Viteza schimbării
Un scor verde pentru repo nu autorizează orice task. Investighează semnalele necunoscute (?); nu le socoti zero. Când nu mai ai necunoscute, adună scorurile și rotunjește jumătățile în sus înainte de a stabili culoarea.
- Verde: un posibil punct de pornire, după ce task-ul propus îndeplinește toate condițiile.
- Galben: prioritizează lacunele concrete și folosește muncă atent supravegheată acolo unde condițiile sunt îndeplinite.
- Roșu: probabil ai nevoie de pregătire mai amplă. Investigația și reparațiile delimitate pot fi în continuare utile; culoarea nu e permisiune pentru schimbări de comportament.
Aplică ghidul zonei relevante din proiect. Un scor verde al repository-ului te ajută să alegi un punct de pornire. Nu autorizează fiecare task din acel repository.
Numără după intensitate, nu după prezență
Punctează dovezile din zona afectată; păstrează necunoscute proprietățile neinvestigate.
Folosește 0 pentru o lacună absentă, 0,5 pentru una parțială și 1 pentru una substanțială, cu o scurtă notă despre dovezi. Folosește ? pentru ce n-ai investigat; nu calcula un total liniștitor trecând necunoscutele ca zero. Fără necunoscute, adună și rotunjește jumătățile în sus înainte să aplici benzile 0-1 / 2-3 / 4+. Sunt reguli euristice ale autorului, nu praguri de siguranță măsurate. Anexa B.4 oferă repere de comportament; procentul de line coverage e doar o informație de sprijin.
Cum arată culorile
Fiecare culoare schimbă felul în care folosești agentul.
| Proiect și dovezi | Număr | Pregătire | Ce faci |
|---|---|---|---|
| Serviciu de profil de client: rezultate și eșecuri relevante testate fiabil, prezentare actuală, reguli canonice, reviewer calificat | 0 | Verde | Alege un task delimitat și stabilește celelalte condiții necesare |
| Plăți legacy: cazuri de eșec relevante absente (1), documentație veche (0,5), cuplare costisitoare (1), reguli împrăștiate (0,5); aprobare și expertiză disponibile | 3 | Galben | Pregătește întâi verificarea; supraveghează investigația și refactorizarea delimitate |
| Bibliotecă de criptare custom: nedocumentată, fără reviewer calificat în criptografie | Nu decide | Condiție neîndeplinită | Restrânge schimbările criptografice; obține expertiză sau evaluează un înlocuitor verificat |
| API greenfield: cerere clară, verificare și deployment neinvestigate | ? | Necunoscută | Definește comportamentul, check-urile, reviewerul și recuperarea înainte să alegi un mod de lucru |
| Tool intern: check-uri relevante stabilite, câteva lacune de documentație și cuplare (0,5 fiecare), expunere mică | 1 | Verde | Un posibil pilot, cu condițiile task-ului îndeplinite și limite de cheltuieli |
Când se strică
- Numărarea coverage-ului în locul aserțiunilor ascunde verificarea lipsă. Verifică comportamentul afectat și cazurile de eșec cu consecințe importante.
- Un total verde maschează o necunoscută. Investighează necunoscuta și condițiile task-ului înainte să extinzi scope-ul.
- Leadership-ul impune un mod de lucru deși lipsește o condiție necesară. Restrânge task-ul afectat și numește pregătirea de care are nevoie.
- Un codebase verde începe să dea rezultate galbene după un upgrade de model. Bănuiește întâi instrucțiunile scrise pentru modelul anterior, înainte să dai vina pe cod: rulează checklist-ul de migrare din Anexa B.9.
De făcut luni
- [ ] Numește un task propus, comportamentul afectat și mediul.
- [ ] Completează cele patru condiții din B.4; restrânge munca afectată oriunde un răspuns lipsește sau e necunoscut.
- [ ] Notează dovezi pentru cele opt semnale de pregătire. Folosește
?pentru necunoscute și check-uri relevante în locul pragurilor de coverage. - [ ] Dă-i lead-ului o acțiune următoare delimitată, un responsabil și un criteriu de finalizare. Ai terminat când alt inginer poate reproduce decizia din fișă.
- [ ] Repetă verificarea când se schimbă task-ul, modelul, controalele sau sistemul din jur.
Mai departe
- Template-uri: Anexa B.4, fișa de punctare; B.9, checklist-ul de migrare între modele.
- Deep dive: Anexa D, Capitolul 8 - cazurile din banking din spatele semnalelor de la 1 la 5 și 7, bug-ul React 18/19 din spatele semnalului 8 și studiul din spatele verificării de migrare.
- Pentru manageri: Anexa A, perspectiva de portofoliu.
- Surse: Anexa C.