De la cod generat la software livrat

Cea mai frecventă eroare pe care o văd la echipele care adoptă programarea cu agenți este că tratează agentul ca pe un generator de cod. Folosesc agentul pentru partea de muncă în care se tastează cod. Restul livrării de software îl fac exact cum l-au făcut dintotdeauna. Și apoi se miră de ce contribuția agentului pare marginală sau, mai rău, de ce echipa pierde mai mult timp reparând output-ul agentului decât a câștigat lăsându-l pe el să tasteze.

Greșeala e că generarea de cod nu mai e bottleneck-ul.

În ultimii patruzeci de ani de inginerie software, constrângerea pe output a fost, foarte aproximativ, viteza cu care un developer putea tasta cod valid care făcea cam ce trebuia. Autocomplete-ul a ajutat. IDE-urile mai bune au ajutat. Tastatul asistat de AI a ajutat mult. Fiecare dintre aceste tool-uri a atacat aceeași constrângere - timpul dintre „știu ce vreau să scriu” și „codul e pe ecran”. Fiecare generație de tooling a mai ros câte puțin din decalajul ăsta.

AI-ul agentic sparge constrângerea. Agentul poate produce o sută de linii de cod care compilează în timpul în care tu formulezi promptul. Producția de cod s-a prăbușit cu un ordin de mărime în genul de muncă pe care agentul îl face bine. Nu a ajuns la zero - agentul tot costă latență, tokeni și timpul tău de formulare și de review - dar costul marginal al următoarelor o sută de linii de cod a scăzut de la „o oră de tastat” la „treizeci de secunde de așteptat”. Asta e constrângerea care se rupe. Așa că, dacă metoda ta e „agentul produce cod, tu faci review pe cod, tu livrezi cod”, bottleneck-ul tău s-a mutat. Bottleneck-ul nu mai e producerea codului. Bottleneck-ul e dacă poți formula munca suficient de clar încât agentul să facă exact ce trebuie.

Fraza asta e afirmația metodologică centrală a manualului.

Bottleneck-ul e disciplina formulării. Capabilitatea există. Ce desparte echipele care livrează bine cu agenți de echipele care se zbat e dacă și-au construit obiceiul de a formula munca într-un mod pe care agentul îl poate executa corect. Echipele fără acest obicei ajung la specificații vagi. Specificațiile vagi produc ghicit. Ghicitul produce output care arată corect și nu e. Echipele cu practica formată ajung la specificații tăioase. Specificațiile tăioase produc execuție predictibilă. Execuția predictibilă produce output pe care îl poți livra.

Ce înseamnă „disciplina formulării” în practică?

Întâi, claritate pe domeniu înainte să se scrie orice linie de cod. Agentul nu îți cunoaște business-ul. Nu îți cunoaște convențiile. Nu cunoaște istoria din spatele felului în care arată codebase-ul tău. Înainte să-i ceri agentului o modificare, trebuie să-i încarci context - prin AGENTS.md, prin skill-uri, prin faza de Research a workflow-ului, prin orice alt mecanism. Volumul de muncă pregătitoare necesară a scăzut față de era pre-agent (pentru că agentul poate face singur o bună parte din încărcare), dar nu a ajuns la zero. S-a mutat din „îți încarci contextul în propriul cap” în „încarci contextul în context window-ul agentului”.

În al doilea rând, descompunerea pe fișiere și pe task-uri înainte de orice acțiune. Agentul va încerca bucuros un refactor pe mai multe fișiere dintr-un singur foc. Output-ul va arăta impresionant. Va fi și mult mai greu de revizuit decât același refactor descompus în cinci pași mici, fiecare o modificare coerentă. Regula e să faci descompunerea explicită - scrii întâi planul, apoi execuți planul, apoi verifici fiecare pas independent. Nu e un sfat nou; inginerii seniori au lucrat dintotdeauna așa la schimbările complexe. Agentul face însă ca prețul lipsei de descompunere să fie mult mai mare, pentru că agentul va produce ceva care compilează indiferent dacă e bun sau nu.

În al treilea rând, refuzul de a spune „gata” fără verificare. Agentul îți va spune că modificarea e completă. Agentul va fi sincer. Agentul va fi, uneori, și pe lângă, pentru că senzația lui internă de „arată bine” nu e totuna cu „am rulat testele și trec”. Regula e: nu există „gata” fără dovezi din teste. Nu teste unitare bifate de formă - teste comportamentale reale, care exersează modificarea. Dacă modificarea ta nu poate fi testată comportamental, probabil că nici nu trebuia să fie un task pentru agent.

Trei obiceiuri. Claritate pe domeniu înainte de cod. Descompunere pe fișiere și pe task-uri. Dovezi din teste înainte de „gata”. Toate trei țin de formulare, nu de generare. Toate trei sunt ce desparte o echipă care livrează software cu agenți de o echipă care doar generează cod cu agenți.

Aici e momentul să anticipez obiecția. Probabil te gândești: sună a multă muncă pentru ceva care trebuia să-mi economisească timp.

Întâi, e mai puțină muncă decât pare. Disciplinele de mai sus sunt, în mare parte, deja practicate de inginerii seniori buni la schimbările importante. Formulează cu grijă. Descompun. Verifică. Ce nu fac întotdeauna e să împacheteze practica într-o formă care scalează - care călătorește de la obiceiurile unui om la obiceiurile unei echipe, de la un repository la mai multe, de la un proiect la un an de proiecte. Workflow-ul cu agenți îți permite să codifici practica o singură dată și s-o aplici peste tot. Costul total e mai mic, chiar dacă costul per task e comparabil.

În al doilea rând, alternativa e mai proastă. Abordarea „lasă agentul în freestyle” pare mai rapidă pe moment. Produce output vizibil. Output-ul ajunge la code review. Reviewerul prinde bug-urile (uneori). Bug-urile se întorc la agent. Ciclul se repetă. Până ajunge modificarea în producție, echipa a cheltuit în total mai mult timp decât ar fi cheltuit dacă impunea rigoare de la început. Senzația că „disciplina ia timp” e reală. Realitatea că „lipsa de disciplină ia mai mult timp” e și ea reală - și de obicei invizibilă până nu te uiți la cycle time pe un trimestru întreg.

Am văzut asta pe mai multe echipe: cele care au impus rigoare devreme au livrat mai repede la nivel de trimestru. Cele care au lăsat agentul în freestyle s-au simțit mai rapide pe moment și au livrat mai încet pe trimestru. Aceleași echipe, aceiași agenți, aceleași codebase-uri. Disciplină de formulare diferită. Rezultate substanțial diferite.

O euristică pentru momentul în care disciplina formulării se amortizează. Nu orice task are nevoie de bucla completă. Costul unei formulări bune - nota de research, planul la nivel de fișier, definițiile testelor - se plătește în avans, înainte ca agentul să scrie vreo linie. Pentru munca trivială, costul formulării depășește contribuția agentului și pierzi timp.

Practica se amortizează când cel puțin una dintre condițiile astea e adevărată: munca atinge mai mult de trei fișiere (blast radius-ul e destul de mare încât un agent nesupravegheat va greși ceva); schimbarea taie transversal prin mai multe straturi (schema bazei de date plus service layer plus UI, unde un singur pas greșit se propagă în cascadă); sau n-ai face munca tastând-o tu însuți (e cu adevărat nouă, sau mare, sau în cod pe care nu-l cunoști destul de bine ca să-l scrii de mână). Dacă niciuna nu se aplică, scrie-o tu. Un bugfix de două linii nu are nevoie de notă de research. O modificare de config de o linie nu are nevoie de plan.

Modul de eșec pe care îl văd cel mai des: echipe care aplică bucla la absolut tot (și încetinesc) sau la absolut nimic (și ratează câștigurile). Euristica de mai sus le desparte. Folosește bucla când costul formulării e mai mic decât costul ca agentul să greșească; sari peste ea când nu e.

Studiul randomizat controlat METR, publicat în iulie 2025, a măsurat exact asta. Developeri open-source experimentați, lucrând cu asistență AI (Cursor cu Claude) pe propriile repository-uri, pe care le cunoșteau bine, au avut nevoie de 19% mai mult timp ca să termine task-urile decât aceiași developeri lucrând fără AI. Înainte de studiu, developerii au prezis că AI-ul îi va face cu 24% mai rapizi. După studiu, în ciuda încetinirii obiective, tot credeau că AI-ul i-a făcut cu aproximativ 20% mai rapizi. Asta înseamnă un decalaj de 43 de puncte între accelerarea prezisă și încetinirea măsurată - și o percepție care persistă chiar și după ce datele o contrazic.

METR nu a testat disciplina formulării ca variabilă separată. Au măsurat asistența AI brută pe cod familiar. Eu tratez rezultatul METR ca pe un avertisment: asistența AI brută nu se transformă automat în viteză de livrare. Variabila lipsă e disciplina de workflow. Echipele care impun proces pot face mai bine de atât. Echipele care nu impun pot rămâne la nivelul METR sau sub el - convinse, între timp, că sunt mai rapide.

Cea mai vie versiune a acestui contrast pe care am văzut-o cu ochii mei: două echipe din aceeași companie, lucrând pe zone adiacente ale aceluiași produs. Echipa A a dat drumul agentului din prima zi. Au sărbătorit velocity-ul de început. Prin luna a treia livrau cam la nivelul de dinainte de agent, dar cu rate de defecte mai mari și cu reviewerii seniori vizibil storși.

Echipa B a petrecut prima lună pe practică. AGENTS.md scris și iterat. Skill-uri scrise pentru pattern-urile specifice echipei. Hook-uri configurate. În prima lună n-au livrat nimic condus de agent. În luna a doua au revenit la velocity-ul de bază, cu practica deja pusă la punct. În luna a treia livrau la o calitate și un velocity vizibil mai bune decât înainte de agent. Investiția își arăta efectul compus.

Aceeași companie. Codebase-uri adiacente. Același agent. Diferența a fost disciplina formulării impusă devreme. Costul: o primă lună lentă. Beneficiul s-a întors pe parcursul trimestrului. A fost o observație de teren pe mai multe echipe, nu un experiment controlat. Contrastul a fost însă destul de clar încât să schimbe felul în care predau adopția - cu mențiunea că două echipe adiacente din aceeași companie nu sunt eșantioane independente.

Cel mai dur test al tezei din acest capitol a venit între februarie și aprilie 2026. Anthropic a livrat, în șase săptămâni, trei schimbări de produs care au degradat semnificativ Claude Code pentru munca de inginerie complexă, în anumite workflow-uri. Adaptive thinking activat implicit, pe 9 februarie. Effort-ul implicit coborât de la high la medium, pe 3 martie. Un bug de caching în retenția istoricului de raționament, pe 26 martie. Efectul combinat a fost destul de sever încât un senior director de la AMD a analizat 6.852 de sesiuni de Claude Code și 234.760 de tool call-uri; analiza a arătat modelul trecând de la un comportament research-first la unul edit-first pe măsură ce ascunderea (redaction) thinking-ului a crescut de la 1,5% la 100% din tururi. O analiză externă separată a raportat o scădere substanțială a calității codului în aceeași perioadă. Anthropic a publicat un post-mortem tehnic pe 23 aprilie, în care recunoaște toate cele trei cauze.

Am urmărit două echipe adiacente în perioada respectivă. Prima își petrecuse trimestrul anterior construind infrastructura descrisă în acest manual: CLAUDE.md cu reguli specifice echipei, plan mode activat implicit, bucla în șase faze pentru orice muncă netrivială, hook-uri care interceptau operațiunile distructive. A doua echipă folosea același Claude Code, aceleași modele, aceleași planuri, dar le rula ca dispatch în freestyle. Velocitatea celei de-a doua echipe s-a înjumătățit peste noapte când modelul a început să taie pe scurtătura edit-first. Velocitatea primei echipe a scăzut poate cu 10% și și-a revenit în clipa în care au strâns gate-urile de plan mode și au trecut câteva skill-uri pe effort mai mare ca setare implicită.

Ăsta a fost experimentul rulând în producție. Echipele cu disciplină au absorbit mare parte din regresie. Echipele fără au resimțit imediat toată schimbarea de comportament, au pierdut săptămâni de avânt și au dat vina pe tool. Metodologia nu e o poliță de asigurare împotriva unei perioade proaste a modelului. E diferența dintre un agent care îți e coleg util și un agent care devine un risc în ziua în care vendorul livrează o regresie.

Dacă reții un singur lucru din acest capitol, reține-l pe ăsta: costul impunerii rigorii se plătește în prima lună. Beneficiul se încasează tot restul timpului. Matematica e de partea ta - dacă supraviețuiești primei luni.

O observație conexă, pentru că pe mine m-a costat timp până am învățat-o.

Practica nu trebuie să fie perfectă ca să înceapă să producă beneficii. Un AGENTS.md de cincisprezece linii e semnificativ mai bun decât niciun AGENTS.md. O notă de research pe jumătate terminată e semnificativ mai bună decât nicio notă de research. Un plan de două task-uri care ratează trei lucruri e semnificativ mai bun decât niciun plan. Perfect e dușmanul lui început.

Echipele care se blochează sunt deseori cele care încearcă să construiască workflow-ul agentic perfect înainte să-l ruleze. Vor AGENTS.md-ul exhaustiv, setul complet de skill-uri, configurația de hook-uri întreagă, înainte să livreze măcar un story condus de agent. Se îneacă în setup. Nu mai încep niciodată. Setup-ul se umflă până umple tot timpul disponibil, pentru că mereu mai e o regulă de adăugat, încă un skill de scris, încă un hook de configurat.

Începe cu practica minimă viabilă. Un schelet de AGENTS.md, cincisprezece linii, care prinde lucrurile despre care știi deja că sunt periculoase. Treci câteva story-uri prin agent. Observă ce merge prost. Adaugă regulile care ar fi prevenit exact acele eșecuri. Iterează. Practica crește din eșecuri reale, nu din unele imaginate. Și crește mai repede, pentru că fiecare regulă și-a câștigat locul.

Capitolul următor e forma operațională a practicii. Șase faze. Research, Plan, Execute, Review, Verify, Ship. Fiecare fază e un tip specific de muncă pe care agentul îl face bine când e formulat corect. Fiecare fază produce un artefact pe care îl poți revizui, îl poți pune într-un commit și îl poți audita. Bucla întreagă e echivalentul SDLC-ului pentru o singură modificare - Research e culegerea de cerințe, Plan e design-ul, Execute e implementarea, Review e code review-ul, Verify e testarea, Ship e deployment-ul.

Dacă ți-ai dorit vreodată un inginer junior care să urmeze procesul echipei absolut de fiecare dată - să nu sară niciodată peste pasul de design, să nu livreze niciodată fără teste, să nu închidă niciodată un story fără verificare - bucla în șase faze e răspunsul. Agentul va urma procesul dacă tu codifici procesul sub formă de cod. Plugin-ul la care ne uităm în capitolul următor exact asta face.

Dar mai întâi, un moment despre ce nu sunt cele șase faze.

Nu sunt singurul mod de a face livrare cu agenți. Există framework-uri concurente - Spec Kit de la GitHub, metodologii în stil BMAD, colecții de skill-uri pe care echipele și le construiesc singure. Le voi numi din nou în acest capitol și în următorul, pentru că lecția nu e „folosește acest plugin anume”. Lecția e bucla iterativă în sine. Plugin-ul e doar vehiculul; disciplina e ce călătorește.

Nu sunt nici un proces universal, bun pentru orice. Un bugfix de două linii nu are nevoie de toate cele șase faze. Un update trivial de documentație nu are nevoie de toate cele șase faze. Bucla în șase faze e pentru genul de schimbări la care câștigul adus de rigoare justifică fricțiunea - de regulă, orice atinge logică de business, modifică structuri de date, schimbă contracte de API sau afectează mai mult de câteva fișiere. Decizia despre ce muncă trece prin bucla completă și ce muncă sare peste ea face parte, ea însăși, din practică.

Nu sunt nici capătul muncii. Agentul livrează un pull request. Pull request-ul trece prin review-ul normal al echipei tale. Oamenii se uită pe diff. Oamenii aprobă. Oamenii fac merge. Agentul nu înlocuiește procesul de livrare existent al echipei; agentul îl alimentează.

Să trecem la cele șase faze.