Cum folosim agenți AI ca să livrăm software de trei ori mai repede

Să începem cu titlul, fiindcă merită demontat înainte de orice altceva.

„De trei ori mai repede“ nu e o măsurătoare pe care am făcut-o și nu o prezentăm ca atare. E felul în care se vorbește despre subiectul ăsta, iar noi îl folosim aici ca să spunem exact opusul: accelerarea e reală, dar e neuniformă, se aplică doar unor părți din muncă, și nu se traduce niciodată direct în „proiectul se termină de trei ori mai devreme“.

Ce urmează e o descriere onestă a ce facem cu agenți AI, ce nu facem și unde se duce, de fapt, timpul pe care îl economisim.

Ce e, concret, un „agent“ în fluxul nostru

Nu e un chat în care ceri cod și copiezi răspunsul. Un agent, în sensul practic, e un model care are acces la unelte: poate citi fișierele proiectului, poate căuta în ele, poate rula comenzi, poate scrie modificări și poate citi rezultatul testelor. Diferența e că lucrează în interiorul proiectului, cu contextul lui, nu pe fragmente scoase din context.

Asta schimbă tipul de sarcini care pot fi delegate. Un chat poate scrie o funcție. Un agent poate parcurge treizeci de fișiere ca să răspundă unde e definit un comportament, poate aplica o schimbare consecventă în toate și poate rula verificările după.

Unde câștigăm timp, realist

Explorarea unui cod necunoscut. E cel mai mare câștig și cel mai puțin discutat. Când preiei o aplicație scrisă de altcineva acum șase ani, prima săptămână se duce în întrebări de tipul „unde se calculează asta?“. Un agent care caută în tot proiectul răspunde în minute. Nu înțelege sistemul în locul tău, dar îți dă hărțile mult mai repede.

Munca repetitivă și consecventă. Adăugarea unui câmp care trebuie să apară în model, în validare, în formular, în export și în teste. Traducerea unui set de componente către o convenție nouă. Adăugarea aceluiași tip de log în douăzeci de locuri. Sunt sarcini în care greșeala umană apare din plictiseală, nu din lipsă de pricepere.

Prima versiune a testelor. Scrierea cazurilor evidente de test e muncă mecanică. Un agent le produce rapid, iar omul adaugă cazurile care contează cu adevărat — cele de la margini, pe care modelul nu le intuiește pentru că nu cunoaște domeniul.

Documentația care rămâne în urmă. Comentarii, README-uri, descrieri de API generate din codul real. Nu e conținut strălucit, dar e infinit mai bun decât documentația inexistentă.

Traducerea între tehnologii. „Cum se face echivalentul acestui lucru în framework-ul X?“ — o întrebare la care răspunsul dura o oră de citit documentație și acum durează câteva minute, cu verificare.

Unde nu câștigăm nimic

La fel de important, și mai puțin spus.

Deciziile de arhitectură. Un model îți va propune o structură plauzibilă. Plauzibil nu e același lucru cu potrivit pentru firma ta, pentru echipa care întreține codul și pentru ce urmează peste doi ani. Alegerea asta rămâne integral la oameni, fiindcă implică lucruri care nu sunt în cod: bugete, competențe, planuri.

Înțelegerea domeniului. De ce firma calculează comisionul altfel pentru un anumit tip de client e o informație care nu există nicăieri scrisă. Se obține vorbind cu oameni. Nu există unealtă care să scurteze pasul ăsta.

Depanarea problemelor reale. Bug-urile grele nu sunt de sintaxă. Sunt condiții de cursă, presupuneri greșite despre date, comportamente care apar doar în producție. Un agent ajută la explorat ipoteze rapid, dar formularea ipotezei corecte e încă muncă de om cu experiență.

Ultimii douăzeci la sută. Cazurile particulare, integrările care se comportă altfel decât zice documentația, migrările de date pe date murdare. Partea în care software-ul devine de fapt utilizabil nu se accelerează aproape deloc.

Prețul, pe care îl plătim și noi

Nu e gratis. Câștigul vine cu costuri concrete.

Revizuirea devine mai grea. Cod generat rapid înseamnă cod care trebuie citit atent. Un agent produce, cu ușurință, ceva care arată corect și nu e. Timpul economizat la scriere se mută parțial la citire — și dacă nu se mută, se va muta mai târziu, în depanare.

Riscul de omogenizare. Modelele tind spre soluția cea mai frecventă din datele lor. Uneori e exact ce vrei. Alteori e o abstracție inutilă într-un loc unde zece rânduri simple ar fi fost mai bune și mai ușor de întreținut.

Contextul se pierde. Un agent nu știe ce ați decis într-o discuție de acum trei luni. Dacă deciziile nu sunt scrise undeva, va reintroduce constant lucruri pe care le-ați respins deja. Efectul secundar util e că ne-a obligat să documentăm deciziile mai disciplinat decât înainte.

Verificarea nu se poate delega. Ce ajunge în producție rămâne responsabilitatea noastră. Nu există „așa a generat modelul“ ca explicație pentru un client.

Cum arată în practică

Fluxul nostru pe o funcționalitate obișnuită arată cam așa: omul stabilește ce trebuie construit și cum se încadrează în restul sistemului; agentul explorează codul existent și propune un plan; omul corectează planul, care e locul unde se prind cele mai multe greșeli, cel mai ieftin; agentul implementează și rulează verificările; omul revizuiește diferențele, nu descrierea lor.

Regula pe care o respectăm: agentul nu decide, agentul execută. Iar ce nu poate fi verificat automat sau citit de un om, nu se livrează.

Două obiceiuri fac diferența între un flux care ajută și unul care produce dezordine. Primul: sarcini mici și delimitate, cu un rezultat verificabil la final. O cerință vagă produce un rezultat vag, la fel ca atunci când o dai unui om. Al doilea: verificări automate care rulează după fiecare modificare — teste, verificare de tipuri, verificare de stil. Fără ele, viteza de scriere devine viteză de acumulare a problemelor, iar factura se plătește la integrare.

Ce nu trimitem niciodată unui model

Partea despre care se vorbește prea puțin în discuțiile despre productivitate: ce date ajung în unelte.

Codul unui proiect e proprietatea clientului. Datele din producție — nume, adrese, facturi, dosare — nu sunt material de lucru pentru nicio unealtă externă, indiferent cât ar ajuta la depanare. Când avem nevoie de date ca să testăm ceva, folosim seturi generate, nu extrase din baza reală. E aceeași regulă pe care o aplicăm și la capturile de ecran publicate: niciun pixel cu date reale.

La fel, credențialele, cheile de API și fișierele de configurare cu secrete stau în afara a ce citește un agent. Nu e o măsură simbolică: un agent care poate citi tot proiectul va citi și ce ai uitat că e acolo.

Regula, formulată scurt: uneltele văd cod, nu văd oameni.

Ce înseamnă pentru tine, ca și client

Trei lucruri care se schimbă efectiv:

Prototipurile vin mai devreme. O variantă funcțională pe care să o vezi și să o comentezi apare în zile, nu în săptămâni. Asta scurtează cel mai costisitor tip de întârziere — cea în care se construiește lucrul greșit.

Proiectele mici devin fezabile. Un instrument intern care ar fi costat cât să nu merite se încadrează acum într-un buget rezonabil.

Estimările rămân estimări. Partea de proiect care depinde de deciziile tale, de datele tale și de integrările cu sisteme externe nu s-a scurtat. Dacă cineva îți promite reduceri spectaculoase de termen pe baza AI-ului, întreabă-l care parte anume se scurtează. Răspunsul e revelator.

Formularea pe care o folosim intern e simplă: AI-ul accelerează munca, nu o înlocuiește. Ce livrăm rămâne evaluat după aceleași criterii ca înainte — funcționează, se poate întreține, și cineva își pune numele pe el.

Mai departe

Construim aplicații de business la comandă folosind fluxul descris mai sus, și site-uri rapide cu Astro cu aceeași disciplină de verificare. Dacă ai o idee de instrument intern pe care ai amânat-o pentru că părea prea scumpă, merită recalculată.

Scrie-ne cu o descriere de câteva rânduri — răspundem în maxim 8 ore lucrătoare.