Cum construiesc software cu agenți AI care scriu cod

Ce deleg de fapt

Acum folosesc agenți de cod pentru aproape toată munca mecanică. Site-ul acesta e cel mai clar exemplu: în câteva săptămâni a primit un front end în patru limbi, o pagină de servicii, un formular de contact cu propriul endpoint API și propria stocare, studii de caz compuse din conținut care exista deja și un widget de progres alimentat de un profil Duolingo. Aproape nimic din toate astea nu mi-a cerut să scriu cod de mână.

Ce nu deleg niciodată este să știu ce ar trebui să existe. Un agent construiește cu plăcere lucrul greșit, foarte repede. Îndemânarea utilă e să scrii o specificație destul de precisă încât greșeala să se vadă.

Eșecul care m-a învățat să verific rezultatul

Când adăugam un badge de maturitate pe paginile de proiect, am făcut un câmp nou status scris în baza de date, tipul extins și componenta actualizată. A compilat. Pagina s-a randat. Badge-ul afișa „în dezvoltare” pe fiecare proiect.

Cauza era un controller care returna doar câmpurile dintr-o listă albă, așa că noul câmp nu ajungea niciodată în afara serverului. Sistemul de tipuri nu a obiectat nimic, pentru că fiecare strat era corect în sine.

Două zile mai târziu, același tipar a apărut în sitemap. Se genera în timpul construirii imaginii de container, când backend-ul nu e accesibil, așa că lista de ID-uri de proiect a venit goală, iar sitemap-ul a plecat fără niciun studiu de caz. Build-ul a trecut. Fișierul arăta bine.

Niciunul dintre bug-uri nu era exotic. Ambele erau invizibile dacă nu te uiți la ce emite de fapt sistemul din producție.

Unde agenții sunt cu adevărat puternici

În lățimea mecanică. Redenumirea unui concept în patruzeci de fișiere. Adăugarea unei a patra limbi în fiecare loc care avea deja trei. Scrierea scheletului de teste pentru un repository care nu are niciunul. Munca vastă, plictisitoare și ușor de verificat e acolo unde câștigul de viteză e real, pentru că verificarea e ieftină când schimbarea e uniformă.

Sunt buni și la lucrul pe care obișnuiam să îl amân: a doua trecere. Un model care își recenzează propriul diff prinde erori de tip, ramuri inaccesibile și importuri uitate mai repede decât mine la 11 noaptea.

Unde eșuează în tăcere

Nu știu ce este adevărat. Cere un studiu de caz și poți primi un paragraf încrezător despre un produs care nu există. Orice afirmație factuală are nevoie în continuare de o sursă, iar „testele trec” nu e o sursă.

Se opresc și la compilare. Un model declară o funcționalitate gata pentru că build-ul e verde, chiar dacă funcționalitatea nu e legată în pagină, câmpul e aruncat de un serializator sau migrarea nu a rulat niciodată.

Blocajul s-a mutat

Înainte, partea scumpă era scrisul codului. Acum e să decizi exact ce construiești și să dovedești că ce s-a construit e ce ai cerut. Zilele mele arată altfel: mai puțin scris, mai mult citit de diff-uri și mai multă verificare a rezultatului live.

Asta are o consecință pentru felul în care lucrez. Schimbări mici, verificate în producție, cu o cale de întoarcere. Un diff mare generat de un agent care „arată bine” e cel mai scump lucru pe care îl poți da merge.