De ce agentul tău de cod eșuează în producție (și cum să-l repari)

Să fim onești pentru un moment. Probabil ai încercat un agent de cod, ai văzut că scrie o funcție sau două, și te-ai gândit: „Interesant." Apoi ai încercat să-l folosești pentru ceva real—ceva care contează—și te-ai lovit de un zid.

Poate a început să inventeze API-uri care nu există. Poate a reparat un bug într-un loc și a stricat alte trei. Poate doar a stat acolo, așteptând să-i explici ceea ce vrei de fapt. Îți sună cunoscut?

Iată adevărul inconfortabil: agentul nu e stricat. Doar nu știi să-l folosești.

Mai exact, tragi de un singur pârghie când ai de fapt trei disponibile.

Cele Trei Pârghii despre care Nimeni nu Vorbește

Fiecare agent de cod, fie că folosești Claude Code, Cursor, Copilot sau altceva, funcționează pe aceeași logică fundamentală. Preia informații, face ceva cu ele, apoi primește feedback. Atât. Gata, asta e toată mașinăria.

Dar iată unde greșesc majoritatea—optimizează una sau două dintre aceste pârghii și ignoră complet a treia. Și în ingineria de producție, acea pârghie uitată devine tavanul tău.

Să detaliez ce înțeleg prin asta.

VEZI: Ce știe de fapt agentul tău?

Din start, agentul tău vede codul tău și terminalul. Atât. Nu știe despre standardele de codare ale echipei tale. Nu știe despre acele soluții ciudate pe care inginerul senior le-a adăugat acum trei ani pentru o integrare legacy. Nu știe ce înseamnă „gata" pentru proiectul tău specific.

Când vorbesc cu echipe care se luptă cu dezvoltarea asistată de AI, problema este aproape întotdeauna contextul. Agentul zboară orbește. Scrie cod care tehnic funcționează dar nu se potrivește cu tiparele din codebase-ul tău, ignoră convențiile de numire, sau reinventează roți pe care echipa ta le-a rezolvat deja.

Soluția? Împachetează contextul ca și cum ai preda treaba unui junior nou. Ce fișiere ar trebui să citească mai întâi? Ce convenții contează? Cum arată arhitectura ta? Majoritatea tool-urilor au modalități de a injecta asta—prompts de sistem, referințe către documentație, fișiere de skill-uri. Folosește-le.

ACȚIONEAZĂ: Ce poate face de fapt agentul tău?

Aici devine interesant. Un agent de bază poate edita fișiere și rula teste. Un agent configurat poate interoga API-uri, verifica statusul CI, citi thread-uri din Slack, sau interacționa cu infrastructura ta cloud.

Cu cât mai multe acțiuni disponibile pentru agentul tău, cu atât mai puțin trebuie să faci tu manual. Vrei ca agentul tău să verifice că un deployment a funcționat înainte să închizi un ticket? Trebuie să poată accesa consola ta cloud. Vrei să coordoneze cu colegii? Trebuie să aibă acces la canalele tale de comunicare.

Nu e vorba despre construirea unui AI sci-fi care să domine tot. E vorba despre eliminarea muncii manuale de a comuta între tool-uri. Fiecare alt-tab e un moment în care contextul se pierde. Cu cât poate face mai multe autonom agentul tău în workflow-ul tău, cu atât mai strânsă devine bucla.

CORECTEAZĂ: Cum știe agentul tău că a greșit?

Aceasta e pârghia pe care majoritatea echipelor o ignoră complet, și e motivul pentru care agenții lor par nesiguri.

Agentul tău are nevoie de feedback. Nu doar „acest cod nu funcționează" ci semnale nuanțate despre calitate, stil și intenție. Linterele prind problemele de sintaxă. Testele prind eșecurile funcționale. Code review-ul prinde problemele arhitecturale. Dar agentul tău nu poate acționa pe baza unui feedback pe care nu l-a primit niciodată.

Gândește-te așa: fiecare corecție automată pe care agentul tău o întâlnește e un moment de învățare. Fiecare eroare ignorată e o oportunitate ratată. Cu cât buclele tale de feedback sunt mai strânse, cu atât mai rapid se îmbunătățește agentul tău.

Aici multe echipe rămân în urmă. Rulează testele manual, verifică linterele sporadic, și revizuiesc codul când își amintesc. Dar pentru ca agentul tău să fie de încredere, aceste verificări trebuie să fie automate și rapide. Pipeline-uri CI care durează 45 de minute sunt moarte pentru productivitatea agentului. Feedback instant? Aici se întâmplă magia.

Principiul Verigii Celei Mai Slabe

Iată modelul mental care mi-a schimbat perspectiva:

Imaginează-ți trei bare. Una pentru Vezi, una pentru Acționează, una pentru Corectează. Capacitatea generală a agentului tău e limitată de cea mai scurtă bară.

Am văzut echipe investind resurse în a face agenții să scrie cod mai bun (Acționează), dar care nu i-au dat agentului contextul potrivit (Vezi), așa că acesta continua să facă aceleași greșeli. Am văzut echipe construind sisteme elaborate de feedback (Corectează), dar agentul nu putea accesa informațiile necesare pentru a aplica acel feedback (Vezi). În fiecare caz, gâtul de sticlă era pârghia la care nimeni nu se gândise să tragă.

Nu e doar intuiție. E o constrângere structurală a oricărui sistem care percepe un mediu, acționează asupra lui și se ajustează. Think despre sistemele de reinforcement learning—au nevoie de observație (Vezi), spațiu de acțiune (Acționează), și semnale de recompensă (Corectează). Eliminați oricare dintre ele, și sistemul se degradează. Agentul tău de cod e același lucru.

Ce Înseamnă Asta pentru Echipa Ta

Dacă evaluezi agenți de cod pentru muncă în producție, nu te opri la probleme de jucărie. Rulează-i prin scenarii care pun presiune pe toate cele trei pârghii:

• Poate agentul accesa contextul necesar pentru a înțelege codebase-ul tău?
• Poate agentul să ia acțiuni care se potrivesc în workflow-ul tău real?
• Primește agentul feedback suficient de rapid pentru a corecta cursul?

Dacă răspunsul la oricare dintre aceste întrebări e „nu prea," acolo trebuie să investești.

Pentru tech lead-uri și arhitecți: nu e vorba despre găsirea tool-ului potrivit. E vorba despre construirea sistemului potrivit. Tool-ul e doar motorul. Pârghiile sunt transmisia, sistemul de alimentare, sistemul de răcire. Un Ferrari cu o roată lipsă nu e o supermașină—e o mașină stricată.

Imaginea de Ansamblu

Suntem încă la începutul erei dezvoltării asistate de AI. Echipele învață că a arunca un agent de cod la o problemă nu e de ajuns. Echipele care vor obține cea mai mare valoare nu sunt cele cu cele mai inteligente modele—sunt cele care construiesc cele mai strânse bucle între a vedea, a acționa și a corecta.

Așa că înainte să învinovățești tool-ul pentru rezultate dezamăgitoare, aruncă o privire sinceră la pârghiile tale. Care e cea mai scurtă? Acolo e oportunitatea ta.