Dacă ai petrecut timp cu asistenți AI de programare, cunoști modul în care lucrurile o iau razna: scrii un prompt vag, agentul generează un perete de cod plauzibil, iar douăzeci de minute mai târziu depanezi ceva ce nu ai proiectat și nu înțelegi pe deplin. Agentic engineering este pariul că soluția nu e un autocomplete mai deștept — ci să faci dintr-o specificație unitatea de lucru, în locul unui prompt.
În 2026, distincția dintre „AI coding" și „agentic engineering" a încetat să mai fie marketing. Este diferența dintre a accepta orice produce modelul și a conduce un agent cu disciplina pe care un inginer senior o aplică oricum: scrie ce construiești înainte să construiești, păstrează un traseu auditabil al deciziilor, și verifică intenția înainte de implementare. Acest ghid explică, practic, ce înseamnă asta și cum o aplici cu uneltele de azi.
De la „AI coding" la agentic engineering
Majoritatea uneltelor AI de programare optimizează pentru viteza până la prima tastă. Agentic engineering optimizează pentru altceva: corectitudinea față de intenție — se potrivește codul cu ceea ce ai vrut de fapt?
Diferența pare subtilă, dar schimbă fundamental fluxul de lucru. Într-un flux clasic, cererea ta devine direct cod. Într-un flux agentic matur, cererea devine întâi un set de artefacte revizuibile — cerințe, design, task-uri — și abia apoi cod. Agentul face tastarea; tu păstrezi judecata la fiecare etapă.
Aceasta nu e o întoarcere la documentația grea de tip „waterfall". Este recunoașterea unui adevăr simplu: gâtuirea în dezvoltarea asistată de AI nu a fost niciodată viteza de tastare — a fost distanța dintre ce ai vrut și ce a construit modelul. Specificația închide acea distanță înainte ca bug-ul să fie scris, nu după.
Spec-driven development: ideea de bază
Spec-driven development formalizează partea de inginerie pe care o sărim de obicei când ne grăbim: să scriem ce construim înainte de a construi. Când descrii o funcționalitate, un agent matur generează o specificație în trei faze.
1. Cerințe
Promptul tău devine user stories cu criterii de acceptare explicite. O tehnică reală și ușoară pentru asta este notația EARS (Easy Approach to Requirements Syntax) — tipare de forma „Când [trigger], sistemul trebuie [răspuns]". Valoarea e că ambiguitatea iese la suprafață înainte de a exista cod. Dacă promptul tău de o linie era subspecificat, vezi asta în ciornă și o corectezi în câteva secunde — nu după o sesiune de debugging.
Un exemplu concret: ceri „un endpoint care întoarce ultimele comenzi ale unui utilizator". Faza de cerințe te forțează să răspunzi la întrebarea pe care ai fi descoperit-o mai târziu: cinci comenzi în total, sau cinci pe pagină? Corectezi în specificație, unde nu costă nimic.
2. Design
Apoi vine designul tehnic: arhitectura, componentele, fluxul de date și abordarea de implementare. Este documentul pe care un inginer senior l-ar scrie (sau ar fi vrut ca un junior să-l fi scris) înainte de a atinge codul. Îl revizuiești, îl contești, îl rafinezi. Dacă designul propus nu se potrivește cu convențiile codebase-ului tău, e un semnal că agentul are nevoie de mai mult context persistent — revenim imediat la asta.
3. Task-uri
În final, designul devine o listă secvențială de task-uri — unități discrete și urmăribile de lucru pe care agentul le implementează în ordine. Pentru că task-urile sunt explicite, primești responsabilizare: vezi ce e gata, ce e în lucru și ce a rămas, în loc să te încrezi într-o cutie neagră.
Câștigul real este mentenabilitatea. O specificație care trăiește în repo-ul tău este documentație care nu se învechește, pentru că ea este exact lucrul din care a construit agentul. Peste șase luni, fișierele de cerințe și design explică de ce arată codul așa cum arată.
Agent hooks: automatizarea care se rulează singură
Al doilea pilon sunt agent hooks — declanșatoare automate care lansează prompturi de agent sau comenzi shell când se întâmplă ceva în mediul tău de lucru. În loc să-ți amintești să rulezi linterul, să regenerezi testele sau să cauți secrete expuse, legi acțiunile la evenimente o singură dată și uiți de ele.
Tipuri uzuale de declanșatoare:
- Evenimente de fișier — un fișier e creat, salvat sau șters
- Evenimente din ciclul de viață al agentului — la trimiterea promptului, la oprirea agentului, înainte/după folosirea unei unelte
- Evenimente legate de task-uri — înainte sau după ce un task se execută
- Declanșatoare manuale — un buton pe care îl apeși la cerere
Versiunea practică: de fiecare dată când salvezi un fișier, un hook poate rula testele și un scan de securitate automat, astfel încât problemele apar în momentul în care sunt introduse — nu peste o oră, în CI. Disciplina nu devine ceva ce trebuie să-ți amintești; devine parte din mediu.
Steering files: nu te mai repeta
Dacă ai lipit vreodată în chat „ține minte, folosim tab-uri nu spații, folosim Vitest nu Jest, și nu importa niciodată din modulul legacy" pentru a suta oară, steering files sunt soluția. Ele dau agentului cunoaștere persistentă despre proiectul tău prin fișiere Markdown, astfel încât convențiile, bibliotecile și standardele tale se aplică consecvent fără să le reexplici în fiecare sesiune.
Aceasta este, în esență, context engineering aplicat unui agent de cod — codificarea cunoașterii durabile de care agentul are nevoie ca să se comporte ca un coleg care ți-a citit ghidul de stil, nu ca un contractor care vede repo-ul pentru prima dată. Este una dintre cele mai subevaluate competențe ale momentului: un agent cu context bun gestionat face muncă de senior; același agent fără context produce cod plauzibil dar greșit.
Unde se încadrează: Claude Code, Cursor și uneltele agentice
Spațiul uneltelor agentice e aglomerat, iar ele se suprapun. Câteva distincții oneste:
- Cursor este un editor AI-native construit în jurul generării rapide în editor, al editărilor multi-fișier și al unui mod agent. Centrul lui de greutate este programarea fluidă, „în flux".
- Claude Code este o unealtă agentică orientată pe terminal, excelentă la schimbări multi-fișier, operații git și lucru conștient de CI din linia de comandă.
- Kiro, IDE-ul agentic de la AWS, se diferențiază făcând din specificație artefactul central — încarcă în față cerințele și designul înainte de implementare.
Pe partea de modele, în 2026 favoritul pentru sarcini de programare în interiorul uneltelor ca Claude Code și Cursor este Claude Opus 4.8, care conduce la momentul scrierii clasamentele de coding (de exemplu pe SWE-bench Verified), cu GPT-5.5 și Gemini 3.1 Pro ca alternative puternice, fiecare cu punctele lui forte. Diferența la vârf între modele e cea mai mică de până acum — așa că factorii care decid sunt costul, fereastra de context, ecosistemul și sarcina concretă care îți pasă. Verifică mereu lineup-ul curent înainte de a alege, pentru că versiunile evoluează lunar.
Aceste unelte nu se exclud reciproc. Mulți ingineri folosesc mai multe și comută în funcție de sarcină. Meta-competența nu e loialitatea față de un editor, ci fluența în întreaga categorie.
MCP și chat agentic: restul ecosistemului
Pe lângă specificații, hooks și steering, uneltele agentice mature includ și ceea ce aștepți de la un editor AI modern: suport pentru Model Context Protocol (MCP), standardul deschis care conectează unelte și surse de date externe la agent, plus un chat agentic cu furnizori de context (fișiere, URL-uri, documente) pentru munca ad-hoc care nu justifică o specificație completă.
MCP contează mai mult decât pare. Este standardul care lasă un agent să-ți atingă baza de date, sistemul de ticketing sau documentația internă — fără glue cod scris manual pentru fiecare integrare. Practic, transformă agentul dintr-un model izolat într-unul care operează în contextul real al organizației tale. Construirea și integrarea serverelor MCP este o competență de sine stătătoare, iar pentru proiecte serioase devine la fel de importantă ca scrierea specificațiilor.
Prima ta oră cu un flux spec-driven
Cel mai rapid mod de a înțelege fluxul este să simți bucla o dată, pe o funcționalitate mică și reală. În practică arată așa: descrii funcționalitatea în limbaj clar (nu „construiește o aplicație", ci ceva concret); revizuiești cerințele și prinzi ambiguitatea acolo unde nu costă nimic; verifici designul față de convențiile codebase-ului; lași agentul să lucreze lista de task-uri, intervenind unde e nevoie de judecată; și legi un singur hook — fie și doar „rulează testele la salvare". Fă asta o dată și pitch-ul abstract — „specificațiile ca unitate de lucru" — devine concret. Disciplina nu e grea; e încărcată în față, iar acea încărcare în față e exact locul unde bug-urile pe care nu le-ai livrat au fost evitate în tăcere.
Vibe coding nu e dușmanul — e un mod
„Vibe coding" — să prompți pe instinct până iese o aplicație, acceptând ce produce modelul — este genuin util pentru prototipuri, scripturi de aruncat și învățare. Este și locul unde multe echipe se ard, când acel „prototip" devine pe tăcute producție.
Spec-driven development este, într-un fel, opusul structurat. Dar asta nu face vibe coding-ul greșit — le face unelte pentru momente diferite. Să scrii o specificație completă pentru un script de o singură folosință e exagerat; să faci vibe coding la un flux de plăți e o invitație la dezastru. Adevărata competență e să știi care mod se potrivește cărei sarcini — iar asta e o decizie de inginerie, nu o preferință de unealtă.
Cum te ajută cursurile Cursuri AI
Uneltele agentice scad costul de a face inginerie ca la carte, dar răsplătesc oamenii care înțeleg deja specificațiile, arhitectura de agenți, managementul contextului și ecosistemul din spate. Exact pe acel fundament sunt construite cursurile noastre, în română, pe repo-uri și proiecte reale, cu un profesor AI integrat în fiecare lecție care îți răspunde la întrebări pe loc.
- Pentru fluxul terminal-first, operații git și schimbări multi-fișier, cursul de Claude Code te duce prin workflow-uri pe repo-uri reale, nu pe demo-uri de jucărie.
- Pentru disciplina din spatele steering files și a memoriei persistente, cursul de context engineering și memorie pentru agenți acoperă end-to-end strategia de context pentru agenți.
- Pentru a învăța când să prompți rapid și când să treci la inginerie structurată, cursul de vibe coding tratează viteza prompt-la-aplicație și ingineria riguroasă ca filozofii complementare, nu rivale.
Toate cursurile vin cu evaluări care îți arată progresul real și conținut actualizat pe măsură ce uneltele evoluează — pentru că într-un domeniu care se schimbă lunar, un curs care „se învechește" e mai rău decât niciun curs.
Întrebări frecvente
Î: Ce este, mai exact, agentic engineering? Este practica de a dezvolta software împreună cu agenți AI, aplicând disciplina inginerească — specificații, design, verificare a intenției, context persistent — în loc să accepți orice cod generează un model dintr-un prompt vag. Mută unitatea de lucru de la prompt la specificație.
Î: Spec-driven development nu e doar „waterfall" cu alt nume? Nu. Waterfall presupunea faze rigide, lungi, fără buclă de feedback. Aici specificația e ușoară, generată de agent în secunde și revizuită de tine la fiecare pas; o ajustezi continuu. Scopul e să surprinzi ambiguitatea devreme, nu să congelezi cerințele luni întregi.
Î: Ce este notația EARS? Easy Approach to Requirements Syntax — o tehnică reală și ușoară de a scrie cerințe testabile, cu tipare ca „Când [trigger], sistemul trebuie [răspuns]". Ajută la formularea unor criterii de acceptare clare, fără ambiguitate.
Î: Ce model AI e cel mai bun pentru programare agentică în 2026? La momentul scrierii, Claude Opus 4.8 conduce clasamentele de coding și e favoritul din Claude Code și Cursor, cu GPT-5.5 și Gemini 3.1 Pro ca alternative solide. Diferența la vârf e mică — verifică lineup-ul curent și alege în funcție de cost, context și sarcină.
Î: Merită overhead-ul specificației pentru proiecte mici? Nu întotdeauna. Pentru un script de aruncat sau o schimbare de un fișier, scrierea specificației costă mai mult decât scrierea codului. Spec-driven strălucește la software durabil, întreținut, atins de mai mulți oameni — și e friction pur la lucru de unică folosință.
Concluzie
Pariul central al agentic engineering este simplu și, cred, corect: gâtuirea în dezvoltarea asistată de AI nu a fost niciodată viteza de tastare — a fost distanța dintre ce ai vrut și ce a construit modelul. Făcând din specificații unitatea de lucru, adăugând agent hooks pentru automatizare și steering files pentru context persistent, transformi „AI coding" în ceva mai aproape de inginerie reală cu un agent.
Nu va înlocui judecata și nu e unealta potrivită pentru orice sarcină. Dar pentru software durabil, construit cu un AI în buclă, disciplina spec-driven este un mod genuin diferit — și mai responsabil — de a lucra. Iar disciplina aceasta se învață: cu cât înțelegi mai bine specificațiile, arhitectura de agenți și managementul contextului, cu atât un IDE agentic devine din „autocomplete mai rapid" o pârghie reală.