Inginerie agentică: ADD — AI Driven Development
Cum lucrez cu 10 agenți AI în paralel pentru a construi Meshes Studio — un flux de lucru bazat pe specs, planuri verificate și checks automate care transformă haosul în producție reală.
Există un moment în care îți dai seama că nu mai ești programator în sensul clasic. Nu mai scrii fiecare linie de cod — orchestrezi agenți care o fac pentru tine. Meshes Studio este construit aproape în întregime astfel. Iată cum funcționează, ce am învățat și unde trebuie în continuare să fiu eu prezent.
Ce înseamnă ADD
ADD — AI Driven Development — nu înseamnă să ceri unui chatbot să îți scrie cod și să îl copiezi în editor. Înseamnă un flux structurat în care agentul AI parcurge întreg ciclul de dezvoltare: citește spec-ul, face un plan, implementează, rulează checks, face review și deschide PR-ul. Tu faci review pe plan, review pe diferența de cod și mergi mai departe.
Diferența față de „vibe coding” este disciplina. Fără structură, agenții produc cod care arată bine dar se rupe la primul colț neacoperit de spec. Cu structură, produc cod care trece CI, trece review și merge în producție.
Fundamentele
Specs — nu codul e sursa de adevăr
Primul lucru pe care l-am schimbat: spec-ul este sursa de adevăr, nu codul.
Codul generat de AI se schimbă repede și se poate „polua” — agenți diferiți lasă urme diferite, convenții inconsistente, logică duplicată. Dacă spec-ul e vag sau lipsește, agentul completează golurile cu presupuneri. Unele corecte, altele nu. Și nu vei ști care e care până când ceva se rupe.
Spec-ul scris clar și complet înseamnă că oricare agent, în orice moment, poate citi ce ar trebui să facă sistemul și poate verifica dacă implementarea respectă asta. Este și singurul loc unde input-ul uman contează cu adevărat — orice neclaritate din spec devine halucinație în cod.
Scriu specs folosind tot AI — încep cu ce vreau să construiesc în limbaj natural, cer agentului să îl structureze ca spec, apoi citesc fiecare rând și corectez. Citesc fiecare rând. Dacă sari peste asta, plătești mai târziu.
Teste bazate pe specs
Testele nu sunt opționale în ADD — sunt mecanismul prin care agentul se auto-corectează.
Când un agent scrie un test greșit sau uită să îl scrie, ciclul lui intern nu are feedback. Implementează, nimic nu pică, presupune că totul e bine. Testele scrise din spec creează un circuit închis: dacă implementarea deviază de la spec, testul pică, agentul vede eroarea și se corectează fără să fie nevoie să intervii.
Checks stricte — mai multe restricții înseamnă rezultate mai bune
Contra-intuitiv: cu cât adaugi mai multe restricții automatizate, cu atât agenții produc cod mai bun.
Avem checks pentru: tipuri TypeScript, format cod, dimensiunea fișierelor, câmpuri interzise în serializatori, migrări lipsă, schema API actualizată. Toate rulează și ca git hooks. Dacă agentul uită să ruleze make generate schema după o modificare API, hook-ul îl oprește și îi spune exact ce să facă.
Agenții răspund bine la feedback imediat și explicit. Un mesaj de eroare clar — „schema is stale, run make generate schema” — e mult mai eficient decât o descriere vagă a problemei în prompt.
Tooling clar și reproductibil
Un agent care nu știe cum să ruleze testele sau cum să deployeze pierde timp în loop-uri inutile. Tot tooling-ul din Meshes Studio trece prin make — un singur punct de intrare, cu comenzi clare: make check be, make check fe, make check build, make dev deploy.
Agentul nu ghicește niciodată cum se rulează ceva. Și dacă o comandă eșuează, eșuează cu un mesaj clar, nu cu un output ambiguu din care agentul trebuie să deducă ce s-a întâmplat.
Paralelizare — fiecare agent cu propriul worktree
Lucrez în mod normal cu 8–10 agenți în paralel. Fiecare agent primește propriul git worktree — o copie separată a repository-ului, cu propriul environment de development izolat. Porturile sunt generate dinamic per worktree, containerele sunt separate, baza de date e separată.
Asta înseamnă că zece agenți pot rula make dev deploy simultan fără să se interfereze. Tooling-ul trebuie să permită asta din start — dacă un make check îți pune output în același fișier indiferent de worktree, ai o problemă de concurență chiar înainte să începi.
Fluxul în practică
1. Spec-ul — singurul lucru pe care nu îl pot delega
Creez sau editez spec-ul pornind de la ce vreau să construiesc. Cer agentului să îl structureze, să identifice edge cases, să propună acceptance criteria. Apoi citesc tot. Nu sar peste nimic.
Orice lucru neclar din spec duce direct la halucinație și slăpiciune în implementare. A scrie un spec bun e mai greu decât a scrie cod bun — trebuie să știi ce vrei înainte să fi văzut cum arată.
2. Planul — review pe fiecare pas
Pornind din spec, cer agentului să intre în plan mode: să scaneze codul existent și să construiască un plan pas cu pas. Citesc planul la fel de atent ca spec-ul.
Artefactele nedorite din plan — un refactor nesolicitat, o abstracție prematură, o abordare care nu se potrivește cu arhitectura existentă — devin cod nedorit. E mai ușor să tai un rând din plan decât să revii pe cod deja scris și testat.
După ce planul e gata, îl trec printr-un al doilea agent specializat în code review (Codex) care îl analizează critic și poate identifica probleme de arhitectură înainte să se fi scris o linie de cod.
3. Implementarea cu checks
Agentul implementează planul și rulează checks după fiecare unitate logică de lucru. Nu la final — pe parcurs. Dacă un test pică la pasul 3, agentul se oprește și rezolvă înainte să continue.
Nu accept niciodată „am implementat, checks-urile par să treacă” ca răspuns. Trebuie să văd output-ul efectiv al comenzii cu toate testele verzi.
4. Verificarea completitudinii
Când agentul raportează că a terminat, îi cer explicit să verifice că a implementat tot planul. Agenții au tendința să uite pașii de la final sau să marcheze ca „done” lucruri pe care le-au făcut parțial. Un prompt simplu — „verifică fiecare pas din plan și confirmă că e implementat” — prinde de obicei 1–2 lucruri omise.
5. Review-ul AI
Trimit diff-ul unui agent specializat în review. Acesta returnează probleme categorizate: BUG, SECURITY, PLAN (ceva care nu respectă arhitectura), COMMENT (observații non-blocante).
Eu decid ce se implementează și ce nu. Nu tot ce găsește review-ul trebuie fix — uneori e over-engineering, uneori e outside scope. Dar bugs și security findings se implementează întotdeauna.
6. Checks verzi → merge
Dacă checks-urile sunt verzi și review-ul e aprobat, agentul deschide PR-ul. Eu fac merge manual. Nu deleghez asta — ultimul ochi pe diff înainte de merge e al meu.
Cea mai mare provocare
Nu e tooling-ul. Nu e AI-ul în sine.
E să ai specs gata înainte ca agenții să înceapă. Și să ții ritmul cu review-ul planurilor.
Pot rula 10 agenți în paralel. Fiecare termină un prompt în 5–10 minute. Asta înseamnă că la fiecare câteva minute am 2–3 planuri sau diff-uri care așteaptă review-ul meu. Dacă mă pun în urmă cu review-urile, îngheț tot pipeline-ul.
Bottleneck-ul nu e viteza agenților. E viteza cu care eu pot produce specs clare și cu care pot face review uman de calitate. Asta e munca reală în ADD.
Dacă vrei să aprofundezi ceva din ce am descris — tooling, workflow, cum structurez specs — mă găsești pe LinkedIn sau Instagram.