Agenții AI și viitorul dezvoltării de software

Ce s-a schimbat, concret

Acum un an, adăugarea unei a patra limbi pe site-ul acesta însemna o după-amiază lungă de modificări mecanice. Recent a fost o singură instrucțiune și o trecere de review. E o schimbare reală în ce poate produce o zi de lucru, și s-a întâmplat fără nicio schimbare în cât de bine înțeleg sistemul.

Părțile care s-au ieftinit sunt cele care nu mi-au plăcut niciodată: redenumirea unui concept peste tot, legarea unui câmp nou prin cinci straturi, scrierea aceluiași test într-o altă formă. Părțile care au rămas scumpe sunt cele care decid dacă software-ul e bun sau nu.

Blocajul s-a mutat la specificare și verificare

Când codul e abundent, raritatea e să știi exact ce construiești și să poți dovedi că există.

Petrec acum mai mult timp scriind o formulare precisă a problemei decât scriind cod și mai mult timp verificând comportamentul din producție decât un diff. De două ori în ultima lună, o schimbare a compilat, a trecut verificările de tip și nu a făcut nimic, pentru că un serializator a aruncat un câmp și pentru că un fișier generat a fost produs înainte să existe datele de care avea nevoie.

Un agent ar fi închis ambele tichete ca rezolvate. Niciunul nu era rezolvat.

Ce fac altfel

Schimbări mai mici. Un diff pe care îl citesc dintr-o singură trecere, verificat în producție înainte să înceapă următorul. Un rollback pe care chiar l-am testat. Teste care verifică un comportament pe care clientul îl observă, în loc de detalii de implementare care flattează un număr de acoperire.

Și o regulă clară despre fapte: nu las textul generat să afirme nimic la care nu pot arăta. Studiile de caz de pe site sunt compuse din date care existau deja, nu scrise din imaginație, pentru că un paragraf încrezător despre un client care nu există e mai rău decât o secțiune goală.

Ce încă nu pot face agenții

Nu pot decide ce ar trebui să fie produsul. Nu îți pot spune că funcționalitatea pe care ai cerut-o îl va încurca pe utilizator sau că regula de business e greșită. Nu pot ști că numărul din paragraf e fals, dacă nimic din repository nu spune altceva.

Nu te poți baza pe ele nici în privința eșecului. Un model raportează succes pentru că operațiile pe care le vede au reușit, în timp ce rezultatul real s-a pierdut trei straturi mai încolo.

Predicția pe care sunt dispus să o fac

Mă aștept ca echipele de software să se împartă după disciplină, nu după numărul de oameni. Echipele care aveau deja teste, review și o cale de rollback vor merge mai repede ca niciodată. Echipele care livrau după intuiție vor livra mai mult cod pe care nu îl înțeleg, iar eșecurile vor fi mai tăcute și mai scumpe.

Tehnologia nu schimbă ce înseamnă inginerie bună. Schimbă cât de repede ajung consecințele.

Ce i-aș spune acum unui inginer junior

Învață sistemul de sub unealtă. Înțelege cererea, coada, granița tranzacției, deployul. Modelul va scrie codul mai repede decât tine; persoana care poate spune de ce e greșit va rămâne cea care contează.