Programare cu agenți AI: am șters 40% din cod și aplicația a devenit mai bună

La începutul lui octombrie am pornit un proiect intern: un sistem care rulează zilnic, adună informații din multe surse, le verifică și publică rezultatul. L-am construit cu agenți de programare în Visual Studio Code și am folosit agenți AI și în interiorul aplicației.

În șase zile am făcut 192 de commituri și am trecut prin trei arhitecturi. Versiunea finală are cu aproximativ 40% mai puțin cod decât versiunea a doua. În schimb, are un folder cu peste 200 de fișiere text și zero linii de cod. Mai bună înseamnă două lucruri concrete. Când ceva nu merge, vedem în loguri exact pasul unde s-a stricat. Și când vrem să schimbăm o regulă, modificăm un fișier text și gata, fără să recompilăm.

În articolul ăsta analizez cum am ajuns aici și ce spune asta despre felul în care se construiesc aplicațiile acum, în plină evoluție a AI.

Prototipul care merge e un început bun

Andrej Karpathy a numit „vibe coding” felul de a construi software în care descrii ce vrei, iar AI-ul scrie codul.¹ Într-un discurs din 2025 a spus și ce aduce asta: programăm acum calculatoarele în engleză (și nu numai în engleză, n.n.), deci dintr-odată toată lumea e programator.² Oameni care ieri nu puteau face o aplicație o pot face azi.

Și noi am construit MVP-ul tot așa, foarte repede: 78 de commituri în prima zi. Numai că destul de curând am ajuns la întrebarea la care ajunge oricine are un prototip care funcționează: cum îl faci să ruleze în fiecare zi, corect, fără să stai cu ochii pe el, și cât de repede îl poți modifica și îmbunătăți? Răspunsul nostru s-a limpezit în trei etape, iar fiecare dintre ele ne-a schimbat punctul de vedere.

Actul 1: garduri în jurul agentului

Agentul produce repede, dar prima lecție a fost că tot ce produce trebuie verificat de ceva care nu e un agent (cunoaștem și teoria conform căreia agenții ar trebui să se verifice singuri, dar, sincer, nu prea credem în ea). Așa că am scris cod obișnuit, determinist, care verifică ieșirile agenților:

• citatele există cu adevărat în sursă;
• linkurile duc unde spun;
• cifrele au o proveniență;
• textul citit de pe internet nu poate strecura instrucțiuni agentului.

Sunt aceleași verificări pe care le facem când verificăm afirmații cu surse pentru clienți sau în FactCompass: fiecare afirmație trebuie să aibă o sursă pe care o poți deschide și citi.

Istoricul arată cât a costat asta. Din cele 192 de commituri, 66 sunt reparații și doar 35 sunt funcții noi; restul sunt refactorizări, documentație și configurare. Fiecare review extern, făcut întâi de alt model și apoi de oameni, a găsit probleme noi. Și așa am învățat că un agent nu e un om: nu își poate verifica singur munca, iar când o face, poate fi subiectiv (sau, mai rău, poate strica ce nu era sarcina lui). Dacă nu-l verifici tu, nu poți avea încredere în el.

Birgitta Böckeler, de la Thoughtworks, numește asta harness engineering, adică ingineria hamului: hamul e tot ce stă în jurul modelului, iar noi, utilizatorii agenților, construim partea lui din afară.³ Ea împarte hamul în două:

• ghiduri, care acționează înainte: reguli, instrucțiuni, specificații;
• senzori, care acționează după: teste, linteri, review.

Noi am început cu senzorii, pentru că acolo ne-a durut întâi. Iar lecția cu care am rămas e una simplă: în producție, ce scoate agentul e material de verificat, nu adevăr.

Actul 2: agentul nu mai decide

În a doua zi am scris în documentație un principiu care a schimbat tot ce a urmat: agenții nu decid ce e necesar și când. Modelele pot grupa, extrage, clasifica și propune, dar decizia o ia o regulă scrisă de om.

Concret, nu mai cerem agentului „alege ce e important”. Agentul face munca grea de sortare, iar alegerea finală o face o regulă cu praguri configurabile, pe care o putem citi, discuta și schimba. Pentru munca în volum folosim un model ieftin. Unul puternic intră doar acolo unde chiar contează. E principiul după care construim și agenții AI pentru firme: AI-ul propune, omul aprobă, sistemul execută.

Pe principiul ăsta am construit versiunea a doua (ura!), pe care am aruncat-o în ziua următoare. Nu pentru că rezultatele erau proaste, ci pentru că nu vedeam ce face. Din eșecul ăsta a rămas o altă regulă pe care o aplicăm de atunci: ce nu se vede în backend nu există. Ce nu poți inspecta la un agent AI sau la o automatizare nu poți nici repara, nici crede.

Actul 3: codul se micșorează, textul crește

Versiunea a treia a pornit de la un nucleu simplificat. Codul Go a scăzut de la aproximativ 54.000 la aproximativ 33.000 de linii, testele incluse.

Nimic din ce știa aplicația să facă nu s-a pierdut. S-a mutat. Folderul de configurare are acum 209 fișiere Markdown și 36 de fișiere JSON, dar nicio linie de cod. Acolo stau:

• regulile de lucru și ghidurile de scriere;
• skill-urile, adică instrucțiunile pas cu pas după care lucrează agenții;
• setările și toate listele pe care înainte le-am fi scris direct în cod.

Codul doar le parcurge. Am unificat și structurile de date: unde existau mai multe variante ale aceluiași lucru, a rămas un singur tip, folosit de toți pașii, iar pașii au devenit piese interschimbabile, cu modelul AI ales pe fiecare pas.

Cineva ar putea spune: n-ați șters cod, l-ați mutat în fișiere text, și textul nu se poate testa. Răspunsul nostru are două părți.

Prima: fișierele text sunt tratate ca și codul. Stau în git, iar orice schimbare trece printr-un review, întâi de la alt model AI, apoi de la un om. Nimic nu ajunge în producție fără pasul ăsta.

A doua: e adevărat că o regulă scrisă în Markdown nu are teste unitare. Dar are verificările din primul act. Dacă o instrucțiune greșită face agentul să inventeze un citat sau să spună o cifră fără sursă, verificările deterministe o opresc la următoarea rulare. Logul ne arată ce s-a schimbat, iar fișierul se întoarce la versiunea de dinainte cu un singur revert.

La capătul etapei a treia, aplicația a devenit ca o trusă de unelte, iar know-how-ul s-a mutat în fișiere pe care developerul le citește, le versionează și le aprobă.

Cum arată acum o aplicație, pe straturi

Privind înapoi, schimbarea nu e doar la noi. Tot ce am făcut corespunde unor tendințe pe care industria le-a creat deja în 2026.

1. Codul devine un set de unelte. Funcțiile sunt mici, clare, fără suprapuneri, și le poate apela și un om, și un agent. Anthropic recomandă puține unelte bine gândite în locul unei unelte pentru fiecare endpoint,⁴ iar SDK-urile pentru agenți vin deja cu uneltele incluse.⁵ Salesforce a mers până la capăt cu Headless 360: toată platforma expusă ca API, unelte MCP și linie de comandă, fără să mai fie nevoie de browser.⁶
2. Configurația urcă în date. Liste, praguri, ordinea pașilor și alegerea modelului ies din cod și intră în fișiere JSON. Se schimbă fără recompilare și le poate citi oricine.
3. Instrucțiunile de lucru se scriu în Markdown. AGENTS.md, propus de OpenAI și găzduit acum de Linux Foundation, și SKILL.md, publicat de Anthropic ca standard deschis, sunt formate pe care le citesc un număr mare de unelte de programare cu agenți.⁷ Contează însă ce scrii în ele. Un studiu ETH Zurich arată că fișierele generale, care descriu proiectul la modul vag, nu-l ajută pe agent și doar cresc costul cu peste 20%.⁸ Cele care ajută sunt cele care spun lucruri specifice proiectului, pe care agentul n-ar avea de unde să le știe. Exact așa sunt scrise fișierele noastre: fiecare regulă a apărut dintr-o problemă reală, găsită în loguri. Pe aceeași idee am construit RagCode MCP: asistentul primește exact contextul din proiect de care are nevoie, nu tot codul.
4. Specificația vine înaintea codului. Instrumente precum GitHub Spec Kit fac din specificația scrisă punctul de pornire al întregului proces: din ea ies planul, sarcinile și abia apoi codul.⁹ La noi, fiecare etapă a avut întâi o specificație aprobată.
5. Ce citește agentul se proiectează, nu se lasă la întâmplare. Agentul lucrează doar cu informațiile pe care i le dai: ce documente primește, când și în ce ordine. Alegerea asta se numește context engineering și a devenit o parte de bază a felului în care se construiește un sistem. Thoughtworks, care publică de două ori pe an un clasament al practicilor din industrie, Technology Radar, a trecut-o în aprilie 2026 direct la „Adopt”, adică „folosiți-o”. A sărit peste treapta de „încercați-o”, prin care trec de obicei practicile noi.¹⁰
6. Hamul face parte din produs. Teste, verificări deterministe, loguri citite după fiecare rulare și review automat la fiecare push. Nu sunt accesorii, sunt structura de rezistență. E și ce lăsăm în urmă când ducem o aplicație făcută cu AI în producție: reguli și teste care opresc asistentul AI să strice aplicația atunci când clientul continuă să lucreze singur cu el, după ce proiectul nostru s-a încheiat.

Ce nu s-a schimbat: omul

Nimic din toate astea nu înseamnă că developerul iese din ecuație. Din contra, doar un developer cu experiență și pregătire poate scrie specificații complete. Tot developerul verifică prompturile, documentele pe care le primește agentul, ordinea lor și codul scris.

Simon Willison, care a preluat termenul agentic engineering propus de Karpathy și i-a scris un ghid,¹¹ are o regulă simplă: nu face commit la cod pe care nu l-ar putea explica exact altcuiva.¹² Addy Osmani, care a lucrat 14 ani la Google și acum la Anthropic, avertizează din cealaltă direcție: un junior care se sprijină pe AI înainte să-și construiască fundamentele ajunge să livreze cod pe care nu-l înțelege.¹³

Experiența noastră confirmă asta. Toate cele trei versiuni au depins de cunoștințe care nu vin de la agent:

• Nu poți scrie o regulă pentru o problemă pe care n-ai văzut-o. Regulile noastre s-au născut din erori reale, găsite în loguri.
• Nu poți face review la cod pe care nu-l înțelegi. Altfel review-ul e doar o semnătură.
• Nu poți simplifica o arhitectură pe care n-o vezi. Cele 40% de cod șters au fost o decizie de arhitectură, nu o sugestie a agentului.

Agentul nu înlocuiește inginerul. Îl mută la nivelul la care lucrează un arhitect.

Dacă ai un prototip făcut cu AI

Vibe coding e un punct de plecare excelent. Drumul de la prototip la producție nu e un salt, ci câteva straturi puse cu grijă. Cinci întrebări de la care să pornești:

1. Poți spune ce a făcut aplicația ieri, pas cu pas, fără să întrebi agentul?
2. Ce decizii ia agentul singur? Le poți scrie ca reguli?
3. Ce verifică ieșirea agentului, în afară de agentul însuși?
4. Unde stă know-how-ul: în cod, în prompturi risipite sau în fișiere versionate?
5. Ce poți schimba fără să recompilezi?

Dacă unele răspunsuri te-au pus pe gânduri, e normal: prin aceleași întrebări am trecut și noi. Iar dacă vrei să le treci mai ușor, exact asta facem în Vibe code → producție: evaluăm aplicația, punem verificările și regulile care lipsesc și o lansăm.

Concluzie

Aplicațiile construite cu agenți AI nu devin mai simple pentru că AI-ul scrie mai mult cod. Devin mai simple când codul face mai puțin: rămâne un set de unelte mici și clare, iar regulile, setările și instrucțiunile se mută în fișiere pe care oricine din echipă le poate citi și schimba. Agentul face munca de volum și găsește tiparele, deciziile se iau după reguli scrise de om, iar verificările automate prind ce scapă. Cine construiește așa are o aplicație pe care o înțelege și o poate repara. Cine sare peste pași are un prototip care merge până în ziua în care nu mai merge.

O mărturisire, la final: am dramatizat puțin. Nu am descoperit stilul ăsta de lucru în cele șase zile ale proiectului. Îl aplicam și înainte, doar că o poveste în trei acte se explică mai ușor decât o listă de principii. Cifrele, în schimb, sunt reale.

La DO IT MAGIC SOFTWARE construim software la comandă și sisteme cu agenți AI în care omul rămâne cel care decide. Dacă ai un prototip făcut cu AI sau vrei un sistem ca cel de mai sus, scrie-ne.

Surse

Întrebări frecvente