Pregătirea: kill signals și semaforul

Când n-ar trebui să folosești agenți AI de cod?¶

O afirmație nepopulară, ca să deschidem capitolul. Există codebase-uri în care n-ar trebui să folosești livrarea cu agenți. Nu pentru că agentul ar fi prost, nici pentru că echipa ar fi slabă, ci pentru că codebase-ul are proprietăți care fac lucrul cu agenți nesigur, neproductiv sau ambele. Când o echipă mă întreabă dacă să pună un agent pe monolitul ei legacy, lucrul onest e să evaluez mai întâi codebase-ul și abia apoi să răspund.

Grila pe care o folosesc pentru evaluarea asta are opt kill signals. Fiecare semnal e o proprietate a codebase-ului sau a echipei. Cu cât sunt prezente mai multe semnale, cu atât e mai periculos să pui un agent în fața codului. De la un anumit prag, te oprești și repari codebase-ul înainte să aduci agentul.

Grila nu e o respingere a livrării cu agenți. E exact opusul: e disciplina care îți permite să spui da livrării cu agenți acolo unde funcționează, tocmai pentru că spui nu acolo unde nu funcționează. Fără kill signals, orice proiect devine un proiect AI, inclusiv cele care n-ar trebui să fie, iar eșecurile proiectelor nepotrivite murdăresc reputația întregii abordări. Tot ăsta e și capitolul construit să circule în sus pe ierarhie: cele opt semnale și semaforul sunt conversația de portofoliu - care codebase-uri acum, care mai târziu, care niciodată - într-o formă pe care un director o poate pune direct în practică.

Semnalele, pe scurt:

Semnalul unu: fără teste.

Codebase-ul nu are o suită de teste automate, sau are una atât de învechită încât n-o mai rulează nimeni. Build-ul trece. Nimic nu exersează comportamentul.

Asta blochează lucrul condus de agent în condiții de siguranță, pentru că agentul nu-și poate verifica propriile schimbări. Agentul va scrie cod care arată corect. Codul va compila. Va trece de verificările de sintaxă. Va ajunge pe mediul de staging. Apoi va strica ceva în producție, iar nimeni nu va observa până când un client se plânge trei săptămâni mai târziu - moment în care schimbarea e îngropată sub alte douăzeci și regresia e greu de atribuit.

Mi s-a întâmplat de două ori, în banking, cu aceeași cauză de fond: un modul de reconciliere a tranzacțiilor scris la începutul anilor 2010 de un senior care a plecat din companie în 2018. Fără teste, pentru că „seniorul pur și simplu știa că merge”. Următorul om care l-a modificat a stricat logica de reconciliere într-un fel care a ieșit la suprafață abia după două luni, moment în care discrepanța depășise deja pragul care declanșează o raportare către reglementator. Ăsta e costul lui „n-am avut niciodată teste” într-un mediu reglementat. Agentul nu face decât să accelereze totul - și drumul productiv, și drumul spre eșec.

Ce e de făcut: scrie întâi testele. Nu toate; doar cât să fixezi comportamentul curent. Folosește agentul pentru asta - îndreaptă-l spre modul și cere-i teste de caracterizare care surprind ce face modulul acum. Agentul e bun la genul ăsta de generare de teste în masă, pentru că specificația e „orice produce codul în acest moment”. Odată ce testele de caracterizare există, poți lăsa agentul să modifice modulul, pentru că testele vor prinde schimbările de comportament.

Asta transformă un kill signal într-un risc gestionabil. E, totodată, o investiție reală de timp. Dacă echipa nu e dispusă s-o facă, răspunsul e nu: n-ar trebui să pui un agent pe codul ăsta.

O precauție: testele de caracterizare generate de agent pe cod legacy fixează comportamentul curent, nu comportamentul corect. Folosește-le ca plasă de siguranță împotriva regresiilor cât timp migrezi, nu ca dovadă de corectitudine.

Semnalul doi: fără documentație.

Codebase-ul n-are o privire de ansamblu asupra arhitecturii, n-are comentarii în cod care să explice de ce s-au luat deciziile, n-are documente de design, n-are decision records. Structura e ce e, și doar autorul original știe de ce.

Asta blochează lucrul condus de agent în condiții de siguranță pentru că agentul inventează context acolo unde contextul lipsește. Într-o echipă, seniorul responsabil de logica de comisioane știa că fee tier-ul se calculează diferit pentru linia de produse legacy, din cauza unei excepții de reglementare din 2017. Agentul nu știa. A citit codul, a văzut un singur calcul, a presupus tratament uniform și a propus un refactor care „simplifica” funcția. Seniorul a prins bug-ul la code review. Același senior ajunsese să facă review pe output de AI patruzeci de ore pe săptămână, în loc să construiască.

Povara cade exact pe oamenii pe care îți permiți cel mai puțin să-i pierzi. Când echipa adoptă livrarea cu agenți fără să investească mai întâi în documentație, seniorii echipei se opresc din construit și se apucă de review. Throughput-ul poate rămâne același; experiența e mult mai proastă, iar seniorii pleacă până la urmă, pentru că nimeni nu s-a angajat din pasiune ca să facă review pe output de AI cât e ziua de lungă.

Ce e de făcut: rulează mai întâi workflow-ul de review de arhitectură din Capitolul 7. Agentul produce în cincisprezece minute documentația care i-ar fi luat unui senior o săptămână. Dă-i commit. Pune un link spre ea în AGENTS.md. Adaugă un glosar scurt de domeniu. Acum agentul are context.

Asta transformă kill signal-ul într-un risc gestionabil. E tot o investiție reală de timp - dar mult mai mică decât să scrii documentația de la zero.

Semnalul trei: cuplare strânsă.

Codebase-ul are module care nu pot fi modificate izolat. Editezi un fișier, se strică alte trei. Graful de dependențe e un ghem. Importurile traversează nonșalant granițele dintre straturi. Testele unui modul cer să pregătești stare în alt modul. „Nucleul de domeniu” e împletit cu stratul de persistență, care e împletit cu stratul HTTP.

Asta blochează lucrul condus de agent în condiții de siguranță pentru că blast radius-ul agentului devine imposibil de prezis. Agentul editează fișierul pe care i l-ai cerut. Rulează testele pe care le găsește. Testele trec. Schimbarea pleacă în producție. Și strică un modul din aval care n-are niciun test - sau al cărui test nu exersează exact acel code path - iar stricăciunea iese la iveală în producție, la închiderea batch-ului de sfârșit de lună.

Un exemplu: un modul de customer service care importa dintr-un modul de originare a creditelor, care importa dintr-un modul de credit scoring, care importa din modulul de customer service. Ciclul fusese introdus acum paisprezece ani ca să „câștige timp”, și nimeni nu-l refactorizase, pentru că orice încercare de a-l sparge ar fi însemnat un proiect de opt săptămâni. Agentul nu știa de ciclu. A făcut o schimbare. Schimbarea s-a propagat într-un fel care a ieșit la suprafață luni mai târziu, în producție.

Ce e de făcut: identifică întâi cea mai gravă cuplare și sparge-o. Doar bucata cea mai gravă. Proiectul de opt săptămâni nu trebuie terminat înainte de orice lucru cu agenți; bucata cea mai gravă, da - pentru că acolo se vor amplifica greșelile agentului. Odată decuplată bucata cea mai gravă, restul codebase-ului nu mai e un pericol imediat pentru agent: e cod legacy normal, gestionabil cu celelalte practici din acest manual.

Dacă echipa nu vrea să investească în decuplare, răspunsul e galben în cel mai bun caz, roșu în cel mai rău, în funcție de cât de gravă e cuplarea.

Semnalul patru: reguli de business împrăștiate.

Aceeași regulă de business e exprimată în trei locuri. Constrângere în baza de date, verificare în stratul de servicii, validare în UI. Când regula se schimbă - și regulile de business se schimbă încontinuu - agentul actualizează una și le ratează pe celelalte. Schema acceptă o valoare pe care serviciul o respinge, sau UI-ul îl lasă pe utilizator să introducă o valoare pe care schema o refuză. Sistemul se minte singur.

Exemplu din banking: suma maximă de transfer. Definită într-un fișier de config pentru UI. Hardcodată într-o constantă în serviciu. Constrânsă de un trigger în baza de date. Echipa de compliance actualizează config-ul, pentru că ăla e fișierul pe care știe să-l citească. Șase săptămâni mai târziu, un client nu poate trimite un transfer valid, pentru că constanta din stratul de servicii a rămas veche. Actualizarea făcută de compliance a fost ignorată de sistemul pe care toți au uitat să-l actualizeze.

Agentul agravează problema, și o agravează mai repede. Fără o singură sursă de adevăr, agentul va ghici care copie e cea canonică - și va ghici greșit.

Ce e de făcut: identifică duplicările și consolidează-le. Pattern-ul e „extrage regula într-o sursă unică și derivă celelalte expresii din ea”. Pentru validări în stil bancar, asta înseamnă de multe ori mutarea regulilor într-un rules engine tipizat sau într-un serviciu de configurare consultat de toate straturile. Vorbim de săptămâni de refactor, nu de o după-amiază. Și se amortizează indiferent dacă aduci sau nu agenți vreodată, pentru că duplicarea era deja o fabrică de bug-uri.

Dacă echipa nu face consolidarea, contribuția agentului în acest codebase se va limita la zonele care nu ating regulile duplicate. E o utilizare mai restrânsă a agentului decât și-ar dori probabil echipa, dar e onestă față de constrângere.

Semnalul cinci: constrângeri de reglementare.

Codebase-ul e sub cerințe de audit în care fiecare schimbare trebuie să fie trasabilă către o aprobare anume, un reviewer anume, un lanț de dovezi anume.

Agentul nu poate îndeplini singur constrângerea de audit. Nu știe care schimbări sunt materiale pentru audit și care nu. Nu știe care revieweri trebuie să semneze pentru care categorii de schimbări. Nu poate ruta aprobări; nu poate satisface cerințe de tip two-person rule; nu poate produce dovezi în forma pe care o așteaptă auditorul.

Nu e fatal, dar cere ca echipa să împacheteze agentul într-un workflow. Agentul produce schimbarea. Echipa rutează aprobarea. Mecanismul de audit deja existent al echipei se ocupă de trail-ul de dovezi. Output-ul agentului e un input într-un proces mai mare; nu e procesul.

Exemplu din banking: orice schimbare a logicii de anti-money-laundering cere semnătura ofițerului de compliance, a unui reprezentant din legal și a unui senior neimplicat în implementare. Agentul poate produce schimbarea. Agentul nu poate ruta aprobarea. Echipa trebuie să împacheteze agentul într-un workflow.

Dacă constrângerile de reglementare sunt blânde - să zicem, orice schimbare de cod cere un code review de la un senior, dar nu există o matrice formală de semnături - agentul intră curat în procesul existent. Dacă sunt apăsătoare - matrici de sign-off, cerințe de dovezi, aprobări cu timestamp, obligații de retenție - agentul funcționează doar ca parte dintr-un sistem mai mare care gestionează deja acele constrângeri.

Kill signal-ul aici e „echipa n-are niciun sistem pentru constrângerile de reglementare și speră că agentul le va rezolva cumva”. Nu le va rezolva. Sistemul trebuie să existe independent. Agentul operează înăuntrul lui.

Semnalul șase: echipa nu poate evalua output-ul.

E cel mai important semnal. E și cel pe care echipele îl înțeleg greșit cel mai des.

Semnalul e structural. Se aprinde atunci când capacitatea existentă a echipei de a evalua munca nu e suficientă pentru munca pe care urmează s-o facă agentul. Un developer junior primește un story: adaugă un pas de verificare criptografică în fluxul de plăți. Juniorul trimite agentul la treabă. Agentul produce un modul de criptografie care folosește AES-256 în mod CBC cu un initialization vector hardcodat. Pentru un junior care n-a făcut criptografie până atunci, arată corect. Codul compilează. Testele unitare trec. Criptograful senior e în concediu de creștere a copilului trei luni. Juniorul livrează. Vulnerabilitatea stă în producție șase luni până când o găsește un penetration test.

Agentul a făcut exact ce i s-a cerut. Output-ul agentului arăta bine. Output-ul agentului era greșit. Echipa n-a avut pe nimeni în poziția de a evalua output-ul în momentul în care output-ul a fost produs.

Văd semnalul ăsta înțeles greșit ca „ne trebuie mai mulți seniori”. E o soluție. Nu scalează pe un orizont de șase luni. Cealaltă soluție e structurală: cuplează output-ul generat de agent cu un reviewer senior, într-un workflow care face review-ul inevitabil. O regulă de hookify care blochează merge-ul până aprobă un senior. Toolkit-ul de PR review care își rulează agenții înainte ca reviewerul uman să vadă diff-ul. O restricție în AGENTS.md prin care agentul nu are voie să atingă deloc modulele de criptografie până nu e setat un flag anume. Răspunsuri structurale, nu de headcount.

Semnalul e cel mai important și pentru că e singurul care prinde eșecurile catastrofale rare. Celelalte semnale prind probleme de productivitate și frustrări operaționale. Ăsta prinde eșecurile care ajung în raportări de conformitate și în retrospective de incident.

Semnalul șapte: potrivirea model-context.

Codebase-ul e scris într-un limbaj, framework sau domeniu unde pretraining-ul agentului e subțire. COBOL vechi. DSL-uri proprietare ezoterice. Framework-uri interne fără nicio urmă publică. Biblioteci științifice de nișă care n-au ajuns niciodată pe web-ul deschis.

Agentul va produce output sigur pe el, valid sintactic, dar deviat semantic. Face pattern-matching pe corpusul greșit. O funcție nouă va arăta a cod idiomatic pentru un alt framework care seamănă cu al tău. Un nume de clasă va urma o convenție din alt limbaj. Greșelile sunt subtile și consecvente, ceea ce le face mai greu de prins decât eșecurile evidente.

Exemplu din banking: un workflow engine intern, custom, scris la începutul anilor 2010, fără documentație publică și cu o sintaxă ciudată pentru tranzițiile de stare. Agentul a produs „îmbunătățiri” care arătau a curățenie, dar care aplicau de fapt pattern-uri dintr-un alt workflow framework (fără nicio legătură), pe care agentul îl văzuse mai mult. Codul a compilat. Testele, câte erau, au trecut. Mașina de stări nu se mai comporta corect în trei edge case-uri pe care echipa nu le-a testat inițial.

Ce e de făcut: stabilește dacă framework-ul sau domeniul codebase-ului tău are o amprentă publică consistentă (repo-uri open source pe care agentul le-ar fi putut vedea, documentație publică, prezentări la conferințe). Dacă da, potrivirea model-context e rezonabilă. Dacă nu, încrederea agentului va depăși competența lui. Tratează codebase-ul ca și cum ar avea activ doar semnalul de capacitate a echipei (șase), chiar și atunci când toate celelalte semnale sunt curate.

Semnalul opt: viteza schimbării.

Framework-ul sau dependențele codebase-ului se mișcă sub el chiar în perioada în care vrei să folosești agentul. Migrarea de la React 18 la React 19 e în plină desfășurare. Un bump de versiune majoră de Spring Boot la mijloc de trimestru. O bibliotecă centrală care își depreciază vechiul API public. O migrare de bază de date pe care echipa a dus-o doar pe jumătate.

Pretraining-ul agentului e un instantaneu înghețat al lumii. Dacă lumea s-a mișcat de la instantaneu încoace, iar codebase-ul tău e călare pe mișcarea asta, agentul va greși cu toată convingerea despre versiunea nouă, în timp ce are dreptate cu toată convingerea despre cea veche. Și nu vei ști mereu care e care.

Mod de eșec concret: am livrat un bug într-o componentă React pentru că Claude folosea idiomuri de React 18 în cod care avea nevoie de pattern-uri de React 19. Componenta mergea local, pentru că mediul de development local încă rezolva spre o dependență tranzitivă de React 18. S-a stricat în producție când build-ul a tras pachetul actualizat de React 19. Agentul nu greșea despre React 18. Greșea despre versiunea de React pe care trebuia s-o suporte exact acel code path.

Ce e de făcut: dacă codebase-ul tău e în mijlocul unei migrări de framework sau de dependențe, încetinește agentul pe căile atinse de migrare. AGENTS.md trebuie să numească explicit versiunea-țintă („migrăm de la React 18 la React 19 trimestrul ăsta; codul nou folosește idiomuri de 19; codul vechi mai poate folosi 18, dar se actualizează când e atins”). Agentul citește regula și folosește idiomurile potrivite pentru contextul potrivit. Fără regula asta, bug-urile le descoperi în producție.

Opt semnale. Fără teste. Fără documentație. Cuplare strânsă. Reguli de business împrăștiate. Constrângeri de reglementare. Echipa nu poate evalua output-ul. Potrivirea model-context. Viteza schimbării.

Sunt agenții AI de cod gata de producție?¶

Semnalele nu sunt o respingere a agentului. Sunt disciplina care îi permite agentului să reușească acolo unde poate. Mai rămâne să le combinăm într-o regulă de decizie. Regula pe care o folosesc eu e un semafor: verde, galben, roșu.

Verde: zero sau un semnal prezent. Lucrul condus de agent e potrivit. Un singur developer poate trimite agentul la treabă, supraveghea bucla în șase faze, face review pe output și livra. Viteză normală. Povară de review normală. Asta e ce-și imaginează lumea când își imaginează „productivitate cu AI”.

Galben: două sau trei semnale prezente. Condus de om, cu sprijinul agentului. Faci pair programming cu agentul, nu îl trimiți singur la treabă ca apoi doar să-i verifici rezultatul. Mai lent decât verde. Beneficiu real de productivitate față de varianta fără agent, dar beneficiul stă mai mult în calitate (agentul prinde lucruri pe care omul le scapă) decât în viteză (omul face în continuare grosul muncii).

Roșu: patru sau mai multe semnale prezente. Repară mai întâi codebase-ul. Contribuția agentului aici va fi net negativă până când kill signals se reduc. Tentația va fi să folosești agentul oricum, pentru că leadership-ul a decis că „adoptăm AI”. Rezistă. Tentația asta e cea care produce poveștile de adopție AI eșuată care murdăresc tot domeniul.

Trei exemple din banking fac regula concretă.

Exemplul unu. Un microserviciu care gestionează actualizările profilului de client. Teste cu acoperire de 70%. Privire de ansamblu asupra arhitecturii în README-ul repo-ului. Decuplat de celelalte servicii printr-un API REST bine definit. Reguli de business exprimate o singură dată, într-o bibliotecă de validare tipizată. Controale SOX standard, dar fără cerințe speciale de audit. Echipa are seniori care se ocupă în mod curent de schimbările legate de profil.

Număr de semnale: zero. Verde. Lucrul condus de agent e potrivit. Echipa poate trimite agentul cu încredere pe story-urile legate de profil, le trece prin bucla în șase faze, livrează.

Exemplul doi. Motorul legacy de plăți. Teste cu acoperire de 20%, majoritar happy-path. Documentația de arhitectură există, dar e parțial învechită. Cuplare moderată între domeniul de plăți și cel de clienți, cu granițe documentate, dar și cu niște abstracțiuni care curg. Reguli de business în mare parte centralizate, cu câteva rătăcite prin code path-uri legacy. Constrângerile de reglementare sunt reale (PCI, raportare de fraudă), iar echipa are mecanismul de audit care să le gestioneze. Senioritate mixtă, cu unu-doi seniori care pot evalua output specific plăților.

Număr de semnale: două și jumătate (lipsa testelor e jumătate, documentația parțială e jumătate, cuplarea moderată e un întreg, constrângerile de reglementare gestionate sunt zero pentru că mecanismul există, capacitatea de evaluare e zero pentru că seniorii sunt disponibili, regulile împrăștiate sunt jumătate). Rotunjește în sus. Galben. Condus de om, cu sprijinul agentului. Echipa poate folosi agentul pentru task-uri punctuale - teste de caracterizare, generare de documentație, refactoring pe module bine delimitate - dar nu pentru livrare autonomă de feature-uri pe părțile de codebase unde kill signals sunt prezente.

Exemplul trei. O bibliotecă de criptare custom scrisă de un contractor în 2017, nedocumentată, testată doar prin teste de integrare care exersează feature-uri din aval, cuplată strâns de infrastructura de key management, cu reguli de conformitate codificate direct în cod, întreținută în prezent de o echipă în care nimeni nu e specializat în criptografie.

Număr de semnale: cinci (fără teste pe unitatea în sine, fără documentație, cuplare strânsă, constrângeri de reglementare cu logică custom, echipa nu poate evalua). Roșu. Agentul n-are ce căuta în acest codebase. Echipa ar trebui fie să găsească sau să finanțeze expertiză în criptografie, să scrie documentația și testele, și abia apoi să reevalueze. Fie să înlocuiască biblioteca custom cu o bibliotecă standard verificată - ceea ce probabil ar trebui să facă oricum. Pentru codul ăsta, răspunsul nu e agentul; e o practică de inginerie mai bună.

Semaforul se aplică la nivel de proiect, nu la nivel de companie. O singură companie va avea simultan codebase-uri verzi, galbene și roșii. Întrebarea nu e „e compania asta pregătită pentru AI”. Întrebarea e „care dintre codebase-urile companiei e pregătit pentru AI azi, și ce ar fi nevoie ca celelalte să treacă într-o altă culoare”.

Cel mai des întâlnit pattern de adopție pe care îl văd: începi cu codebase-urile verzi, ca echipa să capete experiență și încredere; investești în cele galbene ca să le împingi spre verde într-un trimestru sau două; iar pe cele roșii fie le reformezi, fie le scoți din uz, pe un orizont mai lung. Agentul nu e scopul. Scopul e să livrezi software. Agentul e un mijloc.

Aplică grila o dată pe portofoliul tău de proiecte. Sortează după culoare. Observă că imaginea e mai nuanțată decât „facem AI” sau „nu facem AI”. Majoritatea companiilor au un mix. Mixul îți spune ordinea operațiilor.

Două rafinări apar aproape de fiecare dată când trec o echipă prin semafor.

Prima: semnalele nu sunt binare, iar pragul de două-trei versus patru-sau-mai-multe e o regulă empirică, nu un prag exact. Codebase-urile reale au semnale de intensități diferite. Un codebase cu „teste există, dar sunt parțiale” are jumătate din semnalul unu, nu tot. Un codebase cu „documentație există, dar e parțial învechită” are jumătate din semnalul doi. Eu număr așa: adun valorile parțiale și rotunjesc la întregul cel mai apropiat. Un codebase cu patru jumătăți e un doi. Un codebase cu trei jumătăți și un semnal întreg e un trei. Un codebase cu cinci jumătăți e un trei. Aritmetica e impresionistă; ce contează e ordinul de mărime.

Rafinarea contează pentru că unele echipe se uită la un codebase, numără doar da-urile stricte pe cele opt semnale, obțin unu sau doi și trag concluzia că e verde, când realitatea e mai aproape de galben. Codebase-ul care „tehnic are teste”, dar testele acoperă 10% din cod și sunt de calitate slabă, nu e un codebase verde. Codebase-ul care „tehnic are documentație”, dar documentația e veche de trei ani, nu e un codebase verde. Numără după intensitate, nu după simpla prezență.

A doua: semnalul șase (echipa nu poate evalua output-ul) cântărește mai greu decât celelalte. Un codebase care are zero pe semnalele unu-cinci, dar da pe semnalul șase, e tot un codebase roșu pentru munca respectivă. Golul de capacitate al echipei domină celelalte semnale, pentru că el e cel care produce rezultatele cu adevărat proaste - cod pe care echipa nu-l poate verifica, livrat în producție, unde eșecul are consecințe care se compun. Celelalte semnale produc fricțiune și încetinire. Semnalul șase produce incidente care ajung în raportări de conformitate și în retrospective de incident.

Dacă descoperi că semnalul șase e prezent pentru un anumit tip de muncă, răspunsul nu e „hai să facem codebase-ul mai verde pe celelalte semnale”. Răspunsul e „nu face acest tip de muncă cu agentul, în configurația actuală a echipei”. Fie construiești capacitatea echipei, fie te asociezi cu cineva care o are, fie ții agentul departe de zonele respective. Semnalele sunt un diagnostic; semnalul șase e cel care cere cel mai precis răspuns structural.

Încă trei exemple, mai scurte decât primele, acoperă situații pe care primele trei nu le-au atins: