Ship It With AI Mihai Cvasnievschi
ENRO

Cuvânt înainte

16 min de citit

Manualul ăsta există pentru că m-am săturat să port aceeași discuție.

Discuția arată cam așa. Un senior engineer dintr-o companie al cărei business e să livreze software îmi spune că a încercat Claude Code, sau Codex, sau unul dintre celelalte vreo șase coding agents de pe piață, și că „n-a mers”. Când întreb ce anume n-a mers, răspunsul e o variațiune pe aceeași temă: agentul a generat cod care arăta corect, dar nu era; sau agentul a stricat ceva și nimeni n-a observat timp de două săptămâni; sau agentul a produs, cu toată încrederea din lume, un output care încălca o constrângere documentată de echipă în trei locuri diferite. Uneori răspunsul e și mai simplu: agentul a fost prea lent, sau prea scump, sau senior engineerul a ajuns să facă review la mai mult cod decât a scris.

Am auzit fraza asta în săli de ședință, în thread-uri pe Slack, la code review, în post-mortem-uri și în call-uri de procurement. Tool-urile s-au schimbat. Reproșul, nu.

Fiecare dintre răspunsurile astea e real. Fiecare descrie un mod de eșec real. Dar cele mai multe adopții ratate nu se explică doar prin slăbiciunea modelului. Sunt eșecuri ale structurii din jurul agentului: lipsește contextul, lipsesc constrângerile, lipsește procesul, lipsește disciplina de review.

Problema, în fiecare caz, e că echipa a tratat agentul ca pe un tool de evaluat, când agentul e de fapt un tip nou de coleg, care cere un tip nou de structură. Un ciocan îl iei din raft și îl folosești. Un inginer junior nu-l iei din raft să-l folosești. Trebuie să-i faci onboarding, să-i dai context, să pui la punct pattern-uri de review, să construiești încredere în timp. Agenții sunt mai aproape de inginerul junior decât de ciocan.

Despre structura asta e manualul de față.

Nu o să-ți spun ce agent să alegi. Agentul pe care îl alegi azi va fi deprecated, rebranduit sau înghițit de un produs mai mare în timpul în care un ciclu tipic de procurement enterprise apucă să se încheie. Peisajul agenților se mișcă în ritm de luni, nu de ani. Dacă asta ar fi un ghid de tool-uri, ar fi expirat înainte de publicare. Așa că scriu un manual despre cum să gândești livrarea de software cu agenți - arhitectura sistemelor ăstora, metoda prin care livrezi software cu ele și realitatea locurilor unde metoda funcționează și unde nu.

Schimbarea, pusă în context

Acum șaptezeci de ani, a programa însemna să perforezi cartele de carton și să aștepți până a doua zi ca să afli dacă programul tău a rulat. Acum șaizeci de ani au apărut editoarele de text și îți puteai vedea codul pe un ecran. Acum patruzeci de ani au venit mediile integrate de dezvoltare - syntax highlighting, debuggere, navigare prin proiect. Acum douăzeci de ani, IntelliSense a început să-ți sugereze următorul caracter pe care urma să-l tastezi. Acum trei ani, codingul asistat de AI a trecut pragul de la „util din când în când” la „poți livra cod cu el”. Iar apoi, în cele optsprezece luni dintre primăvara lui 2025 și primăvara lui 2026, livrarea de software cu agenți a trecut de la demo de research la capabilitate de producție.

Fiecare dintre tranzițiile astea a părut uriașă la momentul ei. Fiecare chiar a fost uriașă. Și fiecare a venit la pachet cu oameni care susțineau că generația anterioară de tool-uri e de-acum suficientă, iar cea nouă e doar hype.

Privind în urmă, fiecare generație a subestimat următoarea abstracțiune. Nici asta nu va face excepție.

Dar - și asta e partea pe care am avut nevoie de un deceniu în domeniu ca s-o învăț - nu tool-ul e cel care supraviețuiește tranzițiilor. Supraviețuiește felul în care gândești munca.

Dacă ai învățat să faci debugging mergând pas cu pas printr-un program, într-un debugger, în 1995, debuggerul acela concret a dispărut. Felul în care gândești izolarea unui bug - îngustezi inputurile, îngustezi starea, îngustezi fereastra de timp - e exact același. Dacă ai învățat să construiești pentru web în 2008, framework-ul concret pe care îl foloseai a dispărut, înlocuit de două ori între timp. Felul în care gândești separarea responsabilităților, structurarea fluxului de date, gestiunea stării - alea au rămas la fel, doar exprimate în altă sintaxă.

Livrarea de software cu agenți e acum în același tip de punct de inflexiune. Agentul concret pe care înveți să-l folosești va fi înlocuit. Felul în care gândești ce e un agent, ce poate face și ce trebuie să faci tu ca să-l controlezi va supraviețui următoarelor zece înlocuiri.

Peisajul se mișcă repede, dar metodologia rămâne.

În cele optsprezece luni dintre momentul în care mi-am construit primul workflow de programare cu agenți și momentul în care m-am așezat să scriu manualul ăsta, s-au întâmplat patru lucruri care, în orice deceniu anterior, ar fi fost știri de primă pagină în presa tech. Un model a urcat cu 7 puncte procentuale pe un benchmark de coding. Un marketplace oficial de plugin-uri pentru coding agents a devenit un canal real de distribuție. Un mare furnizor de cloud a anunțat end-of-support pentru unul dintre produsele lui de AI pentru developeri. Cel mai mare vendor de AI agentic a formalizat „skills” ca componentă principală pe care orice agent îl poate implementa. Patru schimbări. Patru luni. Oricare dintre ele, în 2015, ar fi alimentat un trimestru întreg de conference talks. În 2026, toate la un loc au fost ciclul de știri al unei singure săptămâni.

Nu există un tool corect pentru totdeauna. Echipele care gestionează bine lucrul ăsta și-au construit un framework de referință pentru evaluarea tool-urilor - ce e un agent din punct de vedere anatomic, ce ar trebui să poată face, ce refuză ele să-l lase să facă, cum îl leagă de procesele lor existente de review și de livrare. Când apare un tool nou, aplică acel framework. Framework-ul supraviețuiește chiar și atunci când fiecare tool concret e înlocuit.

Echipele care gestionează prost lucrul ăsta au ales un tool, l-au integrat adânc fără să se gândească la portabilitate, și acum reiau întregul ciclu de selecție-și-integrare ori de câte ori se mișcă peisajul. Costul nu e tool-ul cel nou. Costul e munca refăcută, reinstruirea oamenilor, migrările lăsate la jumătate, oboseala instituțională.

Mai rău, oboseala instituțională se acumulează de la un ciclu la altul. O echipă care a trecut prin trei adopții ratate de tool-uri în doi ani dezvoltă un scepticism justificat față de următoarea propunere de adopție. Scepticismul face următoarea adopție mai grea, chiar și atunci când următorul tool e cu adevărat mai bun decât cele dinainte. Refrenul echipei - „am încercat X, n-a mers” - devine șablonul aplicat fiecărui X care urmează. Așa ajung echipe bune să se blocheze.

Ieșirea din capcană e să nu mai optimizezi pentru tool-ul concret și să începi să optimizezi pentru framework. Framework-ul e capacitatea de evaluare a echipei - cât de repede poate echipa să ia un tool nou, să-l evalueze în raport cu constrângerile pe care le cunoaște, să-și dea seama dacă se potrivește și fie să-l adopte curat, fie să-l refuze curat. Echipele cu un framework bun pot schimba tool-uri pe bandă fără să-și macine propria disciplină. Echipele fără un framework bun își macină propria practică de fiecare dată când se schimbă tool-ul.

Manualul ăsta e despre construirea framework-ului. Tool-urile concrete pe care le numesc pe parcurs - Claude Code, Codex CLI, opencode, diversele plugin-uri și marketplace-uri - vor fi altele până la data la care ar fi scadentă ediția următoare. Framework-ul va fi același.

De unde vorbesc

Scriu software profesionist din 2000 și construiesc sisteme AI de mai bine de un deceniu. Am folosit fiecare generație de asistent de coding, de la inteligența timpurie din IDE-uri la Copilot și până la coding agents de azi, și mi-am petrecut ultimele optsprezece luni urmărind echipe de producție care adoptă workflow-uri cu agenți - unele bine, altele prost. Manualul ăsta e suma pattern-urilor care au supraviețuit utilizării repetate în echipe reale.

Contextul complet: Despre autor.

Ce înseamnă „AI agentic” în acest manual

Tot spun „AI agentic” fără să fi definit termenul. Iată definiția.

Un sistem de AI agentic e unul care primește un obiectiv, decide ce acțiuni trebuie executate ca să-l atingă și le execută, cu o anumită doză de autonomie. Autonomia e partea care contează. Un plugin de IDE care îți sugerează următoarea linie de cod nu e agent - el sugerează, tu accepți sau respingi, fiecare pas e al tău. Un sistem de programare cu agenți e unul căruia îi dai un obiectiv - „adaugă un câmp Priority pe entitatea Opportunity din CRM” - iar el își dă seama singur ce fișiere să citească, ce fișiere să editeze, ce teste să ruleze, ce comenzi să execute. Tu supervizezi. Tu corectezi. Tu aprobi. Dar nu mai scrii tu fiecare apăsare de tastă.

Trecerea asta - de la a scrie fiecare tastă la a superviza munca - e schimbarea centrală. Tot restul manualului decurge din ea. Arhitectura, pentru că felul în care un agent ia decizii despre ce să facă determină cât de mult ar trebui să-l lași să se atingă de codul tău. Metoda, pentru că supervizarea muncii cere altă disciplină decât scrisul fiecărei taste. Realitatea, pentru că trecerea asta funcționează pentru unele tipuri de muncă și nu funcționează deloc pentru altele.

Majoritatea echipelor care eșuează cu livrarea cu agenți eșuează pentru că au încercat să folosească agentul ca pe un autocomplete pe steroizi. Voiau să tasteze mai repede. Doar că agenții nu asta oferă. Agenții oferă posibilitatea de a delega muncă bine formulată unui coleg care nu obosește, nu are nevoie de pauză de prânz și poate fi clonat ca să lucreze la trei lucruri în paralel. Dacă tratezi colegul ăsta ca pe un ciocan, vei fi dezamăgit. Dacă îl tratezi ca pe un coleg, poți livra lucruri pe care înainte nu ți le puteai permite.

Structura manualului

Trei părți. Arhitectura: cum sunt construiți agenții și cum îl evaluezi pe următorul când apare. Metoda: bucla iterativă care transformă „AI care generează cod” în „AI care livrează software”. Realitatea: unde funcționează asta, unde nu, și care sunt kill signals care îți spun în ce situație ești.

Ăsta e un manual practic, nu un tratat. Scriu la persoana întâi pentru că împărtășesc ce am văzut, nu ce am teoretizat. Exemplele sunt anonimizate, dar reale. Metodele sunt verificate în producție. Opiniile sunt ale mele, apărate cu experiență și oferite cu deplina conștiință că orice opinie concretă va trebui revizuită când vine următoarea schimbare majoră din peisaj - ceea ce se va întâmpla curând și exact ăsta e rostul metodologiei pe care urmează să o împărtășesc.

Dacă vrei o listă de tool-uri cu note, manualul ăsta te va dezamăgi. Dacă vrei un mod de gândire care să supraviețuiască următorilor cinci ani de agitație, citește mai departe.

Un angajament legat de cititor. Manualul ăsta e pentru oricine vrea să livreze software cu AI - un founder, un product engineer, un data scientist, un designer care scrie cod sau inginerul care livrează de douăzeci de ani. E scris în primul rând pentru un singur cititor: senior engineerul - staff, principal sau tech lead - care va pune practica asta pe picioare într-o echipă reală și apoi o va apăra în sus, în fața managementului, pentru că azi obișnuința de a citi cod e încă un avantaj, iar exemplele se sprijină pe ea. Avantajul ăsta e temporar. Programarea urcă în continuare spre niveluri tot mai înalte de abstractizare, iar următorul nu îți va mai cere deloc să citești codul. Ce supraviețuiește urcușului e exact partea despre care e manualul ăsta: să înțelegi problema, să formulezi munca, să constrângi execuția, să verifici rezultatul - iar astea pot fi învățate de oricine, și ăsta e tot rostul. Părțile I și II sunt locul unde faci munca propriu-zisă. Partea a III-a e felul în care câștigi discuția cu oamenii care semnează. Capitolul 10 îl numește pe cititorul principal championul. Dacă ești managerul sau directorul de partea cealaltă a discuției, drumul tău e mai scurt; îl găsești în secțiunea următoare.

O convenție de încadrare. Felul în care vorbesc despre agent ca despre un coleg, pe tot parcursul manualului, e o poziție de lucru, nu o afirmație despre natura agentului. Agentul e software. Poziția e următoarea: investește în el cum ai investi într-un coleg junior - onboarding, infrastructură comună, bucle de feedback, răbdare cu greșelile - și rezultatele operaționale se compun în timp. Sari peste investiție și agentul rămâne un tool, cu randament de tool.

Afirmația centrală a manualului e simplă: livrarea de software cu agenți nu e în primul rând o problemă de tooling. E o problemă de control. Controlează contextul, acțiunile, verificarea și suprafața de adopție, și agentul devine util. Nu le controla, și agentul devine zgomot scump sau risc operațional.

Două idei străbat tot ce urmează și merită spus explicit cum se leagă între ele. Durabilitatea e de ce-ul: tool-urile se schimbă trimestrial, o practică legată de tool-ul lunii moare odată cu tool-ul lunii, iar singura practică pe care merită s-o construiești e cea care supraviețuiește schimbării. Controlul e cum-ul: cele trei părți ale manualului sunt trei forme de control pe care le iei înapoi, în ordine. Arhitectura e controlul capabilității: ce poate ști și ce poate face agentul. Metoda e controlul workflow-ului: cum se formulează, se execută și se verifică munca. Realitatea e controlul adopției: unde aplici metoda și unde n-ar trebui s-o aplici. Durabilitatea e motivul pentru care îți pasă. Controlul e felul în care e construit manualul.

Capitolele care urmează sunt felul în care am învățat să fac afirmația asta să dea rezultate. Prologul e ce se întâmplă când niciunul dintre straturi nu există.

Cum se citește manualul

Ăsta e un manual practic. Prima dată citește-l cap-coadă; după aceea folosește-l ca material de referință.

Traseul principal e al championului și e simplu: tot, în ordine. Capitolele 1, 2, 4, 5, 6, 7 și 8 sunt coloana vertebrală tehnică - anatomie, formulare, buclă, instrucțiuni de echipă, review-ul ca instrument de diagnostic, pregătire. Capitolele 3, 9 și 10 sunt guvernanța, pattern-urile de brownfield și adopția - capitolele de care ai nevoie în clipa în care practica atinge mai mulți oameni decât pe tine.

Două scurtături pentru toți ceilalți. Dacă ești engineering manager sau director: citește Cuvântul înainte, Aria de acoperire și limitele, Capitolele 3, 8 și 10 și Anexa A - postura de risc, clasificarea portofoliului, rollout-ul și costurile. E oricum pachetul pe care ți-l va pune în mână championul tău. Dacă facilitezi adopția: Anexa B e setul de artefacte; Capitolele 7-10 sunt secvența de facilitare.

Poți oricând să sari înapoi. Fiecare capitol presupune capitolul dinaintea lui, dar template-urile și framework-urile sunt gândite să fie luate și folosite direct.

O notă despre afirmațiile datate

Referințele la tool-uri specifice din manual sunt valabile la nivelul lunii iunie 2026. Framework-urile sunt gândite să supraviețuiască tool-urilor concrete. Acolo unde contează o capabilitate anume a unui produs cu nume și prenume, fie datez afirmația, fie o tratez ca exemplu, nu ca proprietate permanentă. Notele de sursă pentru afirmațiile factuale pe care se sprijină argumentul sunt în Anexa C.

Fac tot ce pot să țin manualul la zi și mențin un changelog cu actualizările care contează.

Stilul numerelor: statisticile și procentele sunt scrise cu cifre (19%, 43 de puncte); numerele mici, nestatistice, sunt scrise în litere.

Aria de acoperire și limitele

Un manual practic care nu-și numește propriile moduri de eșec va pierde în fața experienței cititorului în clipa în care experiența aceea se desparte de manual. Așa că iată locurile în care cred că manualul ăsta poate greși.

Tool-urile se vor schimba. Produsele concrete pe care le-am numit - Claude Code, Codex CLI, Cursor, hookify, Superpowers, Understand Anything, marketplace-ul de plugin-uri al Anthropic - vor arăta altfel peste doi ani. Unele vor fi mai bune. Unele vor fi deprecated. Unele vor fi înlocuite de tool-uri care funcționează altfel decât arhitectura descrisă în Capitolul 1. Dacă componentele principale rămân valabile, manualul are dreptate. Componentele principale sunt un set deschis - două dintre cele opt și-au câștigat locul abia recent. Dacă un agent viitor apare fără vreun mecanism care să corespundă unuia dintre componente principale, înseamnă că am ratat o invariantă pe care o credeam structurală. Dacă apare o componentă principală nouă, lista crește.

API-ul de guvernanță se va schimba. Formatele concrete de hook-uri, sintaxa concretă a regulilor de permisiuni, flag-urile concrete de sandbox - astea sunt specifice fiecărui vendor și fiecărei versiuni. Modelul în cinci straturi e ce mă aștept să reziste; detaliile de implementare sunt ce mă aștept să îmbătrânească.

Comportamentul modelelor se va îmbunătăți. Mai multe dintre kill signals sunt legate de limitări actuale ale modelelor - incapacitatea de a-și evalua output-ul, fragilitatea la viteza schimbării, problema potrivirii dintre model și context. Modelele viitoare vor închide o parte dintre golurile astea. Semaforul e calibrat pentru 2026; calibrarea corectă în 2028 s-ar putea să fie mai relaxată.

Prețurile se vor mișca. Structura pe tier-e și categoriile de TCO din Anexa A sunt durabile; ofertele concrete pe care le treci prin ele, nu.

Unele echipe vor obține valoare cu un proces mai lejer. Bucla în șase faze e disciplina pe care am văzut-o funcționând de la o echipă la alta. O echipă cu o cultură de engineering mai așezată, cu un scope mai mic și cu o povară de compliance mai ușoară poate obține mare parte din beneficii cu o buclă în trei faze sau cu un pattern de pair programming structurat. Disciplina completă e pariul sigur, nu singurul drum. Capitolul 5 arată o echipă care și-a câștigat dreptul la varianta mai lejeră - și cele trei condiții pe care le avea deja îndeplinite.

Unele workflow-uri sunt prea reglementate pentru setările astea implicite. Manualul presupune că echipa are autoritatea să instaleze hook-uri, să configureze AGENTS.md, să pună la punct sandbox-uri și să ruleze subagenți. Unele medii reglementate nu permit așa ceva fără architectural review boards, comitete de securitate sau procese de procurement cu vendorii care durează luni de zile. În mediile alea, manualul descrie destinația, nu drumul.

Cazurile folosite în manual

Fiecare dintre studiile de caz de mai jos revine în mai multe capitole. Lista există ca să poți naviga și după exemplu, nu doar după framework.