Tehnologie

Când IA scrie și livrează codul, dezvoltatorii experimentați devin cu 19% mai lenți

Susan Hill

Agenți software precum Devin, Claude Code și GitHub Copilot Workspace preiau acum o descriere a sarcinii, citesc o bază de cod, scriu cod care o rezolvă, execută teste până când acestea trec și deschid un pull request — fără ca un dezvoltator să tasteze măcar o linie. Devin, construit de Cognition AI, face acest lucru în medii cloud izolate. În baza sa de utilizatori din producție, 67% dintre pull request-urile pe care le deschide autonom sunt integrate. Claude Code citește întregul repository, planifică modificări în mai multe fișiere, rulează suita de teste și iterează fără instrucțiuni între fiecare pas. Aceste instrumente sunt utilizate în producție, nu în previzualizări de cercetare.

Ceea ce le diferențiază de instrumentele anterioare de generare a codului este bucla de feedback. Un motor de sugestii generează text și se oprește; un agent autonom generează cod, îl rulează, citește ceea ce primește înapoi și încearcă din nou. Scheletul subiacent este același la toate instrumentele: un model de limbaj mare citește contextul — baza de cod, descrierea problemei, jurnalul de erori — generează un plan, îl execută prin instrumente precum comenzi shell, editări de fișiere și operații git, citește rezultatul și revizuiește. Bucla continuă până când agentul reușește sau își epuizează bugetul de resurse.

Bucla care a înlocuit editorul

Gama de autonomie a instrumentelor disponibile se întinde pe trei niveluri. La capătul asistat, GitHub Copilot sugerează următoarele câteva linii pe măsură ce un dezvoltator tastează. Cu un nivel mai sus, editorii multi-fișier precum Cursor rescriu într-o bază de cod la direcția dezvoltatorului, făcând modificările pe care acesta le specifică. La capătul autonom, Devin și sistemele comparabile operează independent perioade îndelungate, luând decizii secvențiale despre ce să citească, ce să schimbe și ce să testeze, apărând doar pentru aprobări pe care sistemul nu le poate gestiona singur.

Cadrul de evaluare care măsoară progresul acestor instrumente este SWE-bench, creat de cercetători de la Princeton și Stanford. Testează agenții pe rapoarte reale de bug-uri din repository-uri open-source Python — Django, Flask, scikit-learn — și măsoară ce procentaj poate închide corect un agent. Cel mai mare scor publicat în prezent pe subsetul curated Verified, 96%, aparține lui Claude Opus 5. Acest număr reprezintă o capacitate reală: abilitatea de a diagnostica un bug software real, de a scrie o remediere și de a verifica dacă trece testele proprii ale proiectului.

Ce ascunde benchmark-ul

Scorul de 96% vine cu un asterisc important. SWE-bench Verified se bazează pe 500 de sarcini atent selectate. Când cercetătorii au aplicat o variantă rezistentă la contaminare — SWE-bench Pro, concepută folosind probleme care nu ar fi putut apărea în datele de antrenament ale niciunui model — un model anterior care obținuse peste 80% la Verified a scăzut sub 50% la Pro. O parte din performanța benchmark-ului reflectă familiaritatea cu setul de evaluare, nu o capacitate generalizată de rezolvare a problemelor. Decalajul este o provocare cunoscută în cercetare, nu o critică la adresa unui instrument anume.

Un studiu separat a descoperit ceva mai greu de explicat. METR, o organizație de cercetare în siguranța AI, a realizat un studiu controlat randomizat cu dezvoltatori open-source experimentați care lucrau pe propriile repository-uri. Dezvoltatorii care foloseau instrumente AI actuale de codare erau cu 19% mai lenți decât cei care lucrau fără ele — deși estimau independent că sunt cu 20% mai rapizi. Cauzele au fost specifice: timpul petrecut re-promptând când agentul producea rezultate incorecte, timpul petrecut verificând rezultatele înainte de integrare și costul cognitiv al comutării între dirijarea unui agent și urmărirea a ceea ce făcuse agentul. Un benchmark testează dacă un agent poate închide un bug bine specificat în izolare. Un studiu randomizat testează dacă un dezvoltator lucrează mai rapid pe parcursul unei zile reale. Măsoară lucruri diferite.

De ce o adoptare de 93% a produs doar un câștig de 10% în debit

Autonomia codului funcționează cel mai bine pe sarcini bine delimitate și specificate: un bug reproductibil cu intrări și ieșiri clare, o funcție cu o specificație precisă, o suită de teste pentru un modul cu comportament definit. Pe măsură ce domeniul se extinde la sarcini care necesită cunoștințe arhitecturale implicite, convenții de echipă nedocumentate sau decizii privind direcția produsului, fiabilitatea scade — nu pentru că modelele nu au capacitate, ci pentru că contextul de care au nevoie aceste decizii nu încape în sistem și nu poate fi derivat doar din fișierele bazei de cod.

Schimbarea practică constă în ceea ce necesită munca. Dezvoltatorii care lucrează cu agenți autonomi petrec mai mult timp scriind specificații suficient de precise pentru ca un agent să le execute: descrieri detaliate ale problemelor, contracte de test clare, criterii de acceptare explicite. Petrec mai mult timp revizuind cod pe care nu l-au scris, ceea ce necesită un alt tip de atenție decât scrierea codului — căutând erori logice, breșe de securitate și derive arhitecturale pe care agentul nu le va semnala singur. Un sondaj din 2026 pe 121.000 de dezvoltatori a constatat că 93% folosesc instrumente AI de codare în mod regulat; debitul de pull request-uri a crescut cu aproximativ 10% în același grup. Blocajul s-a mutat de la scrierea codului la revizuirea acestuia.

Următoarea etapă aflată în dezvoltare activă este reprezentată de agenții care își gestionează propriile cozi de sarcini: primesc o specificație de proiect, o descompun în subsarcini, deleagă între modele specializate și scot la suprafață doar deciziile care necesită judecata umană. Mai multe framework-uri open-source pentru orchestrarea codării multi-agent au fost lansate în 2026. Adoptarea în mediile de producție enterprise rămâne limitată. Gartner estimează că o parte semnificativă a proiectelor software agentice începute anul acesta vor fi întrerupte înainte de 2028, odată ce echipele vor descoperi distanța dintre ceea ce arată o demonstrație controlată și ceea ce necesită o implementare fiabilă la scară.

Etichete: , , , , ,

Discuție

Există 0 comentarii.