AL+

RO EN

Scrieți-ne

Agenți AI în programare: specificația este munca

Copilot Workspace punea planul înaintea codului în 2024. Doi ani mai târziu, agenții AI ajută unde specificația și verificarea ei sunt munca propriu-zisă.

. De . AI și programare cu agenți

Read this article in English

Când GitHub a deschis, pe 29 aprilie 2024, previzualizarea tehnică a Copilot Workspace, atenția s-a îndreptat mai ales spre promisiunea că poți ajunge de la un issue la un pull request scriind în limbaj natural. Ideea care a rezistat mai mult a fost ordinea ecranelor. Workspace îi arăta programatorului o specificație scrisă și un plan înainte să genereze vreo linie de cod și îi cerea să le corecteze și să le aprobe mai întâi.

La doi ani și jumătate distanță, tocmai această ordine merită păstrată. Echipele care câștigă ceva real de pe urma agenților AI de programare tratează specificația scrisă și verificarea ei ca muncă de inginerie. Codul generat e partea ieftină. Un furnizor care nu vă poate arăta cine a aprobat planul înainte să pornească agentul nu are un proces de verificare, oricât de bine ar arăta pull requestul de la final.

Ce propunea, de fapt, Workspace

Articolul de lansare al GitHub (29 aprilie 2024) descria un flux de lucru centrat pe sarcină, care pornește de la un repository sau de la un issue. Workspace propunea apoi un plan pas cu pas pentru rezolvarea issue-ului, lăsa totul editabil, de la plan până la cod, și se încheia cu pașii obișnuiți: deschiderea pull requestului, rularea GitHub Actions și a scanării de securitate, code review făcut de colegi.

Echipa GitHub Next a explicat structura mai în detaliu, în aceeași zi, într-un comentariu pe Hacker News. Specificația avea puncte „current”, adică felul în care agentul înțelege sistemul de azi, și puncte „proposed”, adică ce trebuie să fie adevărat după modificare. Planul făcea legătura dintre ele. Fiecare putea fi corectat înainte ca agentul să atingă vreun fișier. Același comentariu spune ceea ce susține și acest articol: un issue bine specificat contează la fel de mult pentru oameni ca pentru AI, iar „bine specificat” nu înseamnă „mai mult”, ci „mai clar”.

Ce au găsit primii utilizatori

Primele impresii au fost amestecate, iar tiparul din ele contează mai mult decât verdictul. Austin Henley, care lucrase anterior cu echipa GitHub Next, a descris câteva zile de folosire (29 aprilie 2024). Concluzia lui: planul generat era de obicei bun. Codul, nu. Henley a scris că instrumentul era lent, că codul generat era adesea plin de buguri sau nu avea legătură cu specificația și că ar fi folosit cod doar din 2 dintre cele 12 sesiuni ale sale.

Privit retrospectiv, planul era deja cel mai fiabil rezultat al sistemului. Modelele de atunci descriau des modificarea corectă, apoi nu reușeau s-o facă. Planul era locul unde un om putea aduce cea mai multă valoare cu cel mai mic efort.

Ce a supraviețuit

Workspace, ca produs, nu a supraviețuit. GitHub Next a încheiat previzualizarea tehnică pe 30 mai 2025 și le-a recomandat utilizatorilor modul agent din VS Code și noul Copilot coding agent, recunoscând deschis că acestea nu fac exact ce făcea Workspace.

Anunțul Copilot coding agent (19 mai 2025) a mutat punctul de plecare înapoi la issue: îi atribuiți issue-ul lui Copilot, iar acesta lucrează în fundal și face push într-un draft pull request. Editorul de plan din browser dispăruse, așa că textul issue-ului a devenit specificația. Același articol a pus a doua barieră în setările implicite: programatorul care îi cere agentului un pull request nu îl poate aproba tot el, iar workflow-urile din Actions nu rulează fără aprobare. GitHub a spus și unde se aștepta ca agentul să se descurce bine: la sarcini de complexitate mică și medie, în proiecte bine acoperite de teste.

În septembrie 2025, GitHub a publicat Spec Kit (2 septembrie 2025), un set de instrumente open source care împarte munca în patru etape (specificare, plan, sarcini, implementare), cu un punct de control după fiecare. Diagnosticul lui pentru munca ratată a agenților este că problema ține de felul în care lucrăm noi, nu de capacitatea agentului de a scrie cod, și că agenții se poartă ca niște parteneri de programare care iau totul ad litteram.

Puse în ordine, aceste evenimente sugerează că ecranul cu planul editabil a fost un experiment de produs care s-a încheiat, iar disciplina „întâi planul, apoi codul” s-a mutat în issue, în repository și în procesul echipei. Acolo îi este locul, pentru că e o decizie despre muncă, nu o funcție a unui instrument anume.

Două întrebări distincte la verificare

Pentru modificările importante scrise de un agent, recomand verificarea separată a planului și a implementării. Sunt întrebări diferite; același lider tehnic poate face ambele verificări dacă este independent de implementare și de persoana care a cerut modificarea.

Aprobarea planului stabilește dacă aceasta este modificarea potrivită. Descrie specificația sistemul așa cum este azi? Starea propusă corespunde nevoii firmei? Sunt numite cazurile-limită? Responsabilul este cel care înțelege domeniul și sistemul: de multe ori liderul tehnic, uneori un product owner care lucrează alături de un inginer.

Code review-ul pe pull request stabilește dacă modificarea este corectă și sigură. Face codul ce spune specificația aprobată, și nimic în plus? Acoperă testele comportamentul nou? S-a modificat ceva ce nu trebuia atins? Responsabilul este un reviewer care nu a cerut modificarea. Regula implicită a GitHub, prin care cel care cere modificarea nu o poate aproba, exact asta face.

Greșeala frecventă este contopirea celor două aprobări. Când singura verificare are loc la pull request, reviewerul trebuie să reconstituie intenția din diff. Un issue vag, de tipul „adaugă reduceri la checkout”, produce atunci un pull request sigur pe el, care compilează, trece testele scrise tot de agent și implementează doar unul dintre sensurile rezonabile ale cuvântului „reducere”. Review-ul prinde probleme de stil și ratează faptul că s-a construit altceva decât trebuia. Un issue clar numește regula (ce clienți, ce produse, dacă reducerile se cumulează, ce se întâmplă la retur) și spune cum arată succesul. Scrierea acestui text este munca de inginerie. Este și partea pe care o poate citi clientul.

Cea mai puternică obiecție

Critica lui Henley este cel mai bun argument împotriva lucrului cu agenți pornind de la specificație și rămâne parțial valabilă. El susținea că fluxul dintr-o singură trecere sare peste toți pașii în care programatorul intră în cod și își construiește un model mental al felului în care funcționează, iar varianta corectă este una iterativă: formulezi sarcina, rafinezi planul, alegi modificările, verifici și o iei de la capăt. Din acest unghi, o specificație mare scrisă dinainte este waterfall sub alt nume, iar înțelegerea care face o specificație bună vine doar din lucrul efectiv în cod.

Are dreptate că specificația nu se poate scrie izolat și nici nu poate fi înghețată. Din același motiv, Spec Kit numește specificațiile documente „vii”. Iterația privește însă felul în care se scrie specificația, nu dacă ea este verificată înainte de generarea codului. Bucla ieftină este să revizuiți un paragraf. Bucla scumpă este review-ul unui diff de 600 de linii construit pe o neînțelegere.

Unde concluzia nu se aplică

În unele situații, pornirea de la specificație e instrumentul greșit, iar asta face parte din argument.

  • Investigația. Când încă nu știți de ce apare un bug, nu aveți ce specifica. Munca este diagnosticul, iar agentul este, cel mult, un asistent de cercetare.
  • Prototipurile de unică folosință. Dacă prototipul există doar ca să răspundă la o întrebare de design și va fi șters, o specificație formală costă mai mult decât economisește.
  • Proiectele fără teste. Afirmația GitHub privea proiecte bine acoperite de teste. Fără teste, review-ul pe pull request nu se poate sprijini pe nimic automat, iar un plan aprobat nu face sigură o modificare pe care nu o puteți verifica. Testele vin primele.
  • Modificările mici și evidente. O greșeală de tipar sau actualizarea unei versiuni nu cer aprobarea unui plan. Disciplina crește odată cu costul unei greșeli.

Un test pentru cine cumpără software construit cu agenți

Dacă un furnizor vă spune că folosește agenți AI de programare, cereți-i să vă arate o modificare recentă: specificația aprobată, pull requestul, cine le-a verificat și ce teste au rulat. Verificați dacă intenția a fost analizată înaintea implementării și dacă persoana care verifică codul este independentă de implementare și de cel care a cerut modificarea. Același lider tehnic poate aproba planul și verifica pull requestul; două nume diferite nu dovedesc singure independența. Software-ul construit cu AI are nevoie de un inginer (în engleză) care să răspundă pentru el.

Copilot Workspace avea dreptate în privința ordinii ecranelor. De atunci, agenții au ajuns să scrie cod mult mai bine, iar asta face specificația și verificarea ei și mai importante, pentru că ele decid acum dacă acel cod valorează ceva.

Surse

Toate sursele sunt în limba engleză.