Studiul METR a separat impresia de viteză de timpul de finalizare
Studiul randomizat METR din 2025 a găsit timpi mai mari în proiecte cunoscute. Rezultatul măsoară un mod de lucru precis și are limite clare de aplicabilitate.
Un dezvoltator poate avea impresia că lucrează mai repede cu un asistent, deși îi ia mai mult să termine. Studiul randomizat METR a măsurat această diferență într-o situație precisă: contribuitori cu experiență, care lucrau în proiecte pe care le cunoșteau deja. Lecția practică este să comparați efortul de finalizare după un criteriu clar de acceptare, înainte să transformați ajutorul perceput într-o estimare de livrare.
Această retrospectivă din noiembrie 2026 privește studiul inițial, despre instrumentele de la începutul lui 2025. Anunțul METR este datat 10 iulie 2025, iar prima versiune a lucrării a fost depusă pe 12 iulie. Anunțul trimite acum și la o actualizare din februarie 2026. Aceasta este o dovadă ulterioară, nu o parte a rezultatului inițial discutat aici.
Permisiunea a fost atribuită sarcinilor
Studiul inițial a inclus 16 dezvoltatori și 246 de sarcini finalizate: 136 cu utilizarea AI permisă și 110 cu utilizarea AI interzisă. Participanții aveau, în medie, cinci ani de experiență în proiectele lor. Au propus probleme reale și au estimat timpii înainte de repartizare. Alegerea aleatorie privea permisiunea de a folosi asistența, nu obligația ca fiecare sarcină eligibilă să primească același model sau aceleași instrucțiuni. Detaliile provin din metodele și rezultatele versiunii întâi.
Metoda este utilă fiindcă nu îi întreabă pur și simplu pe utilizatorii entuziaști dacă sunt productivi. Repartizarea după definirea sarcinilor limitează posibilitatea de a alege lucrări ușoare pentru asistență și lucrări grele pentru comparație. Totodată, unitatea de analiză rămâne apropiată de decizia concretă a unui responsabil de proiect: finalizarea unei probleme într-un proiect existent.
Intervenția analizată rămâne un întreg mod de lucru. Instrumentele, alegerile dezvoltatorului și proiectul contribuie împreună la rezultat. Un rezultat despre permisiunea de a folosi instrumente nu poate izola calitatea intrinsecă a fiecărui model implicat. Nu stabilește nici ce ar fi obținut aceiași participanți cu o procedură obligatorie, atent optimizată.
Instrumentele istorice au fost în principal Cursor Pro cu Claude 3.5/3.7 Sonnet. Numele identifică situația studiată; nu reprezintă o recomandare sau executarea acelor instrumente aici. Dacă am înlocui situația istorică printr-un asistent nespecificat din noiembrie 2026, am schimba întrebarea. O decizie actuală de adoptare are nevoie de dovezi pentru modul actual de lucru.
Estimarea are o incertitudine și o bază de comparație
METR a raportat un timp de implementare cu 19% mai mare când AI era permis. Participanții preziseseră un timp cu 24% mai scurt, iar după studiu estimau o reducere de 20%. Sunt trei mărimi diferite: o estimare măsurată a efectului intervenției, o predicție și o convingere retrospectivă. Nu ar trebui reunite într-un singur scor de productivitate sau tratate ca trei măsurători independente ale vitezei reale.
Anexa D a lucrării descrie regresia pe logaritmul timpului de finalizare, ajustarea după dificultatea estimată și transformarea coeficientului și a intervalului său de încredere de 95% într-un raport al timpilor. Lucrarea prezintă și o verificare a robusteții prin raportul mediilor, cu intervale obținute prin bootstrap. Așadar, cifra de 19% este o estimare rezultată dintr-o analiză precizată, nu afirmația că fiecare contribuitor a încetinit exact atât.
Incertitudinea statistică și aplicabilitatea sunt limite separate. Un interval al efectului estimat nu face ca un grup selectat să reprezinte întreaga activitate software. Chiar și un efect estimat precis în proiecte cunoscute ar lăsa deschisă întrebarea despre un începător, un proiect necunoscut sau alt tip de sarcină. În sens invers, eșantionul mic nu justifică înlocuirea rezultatului unei repartizări aleatorii cu sondaje despre preferințe.
Și rezultatul măsurat cere o descriere exactă. Dezvoltatorii au raportat timpul de implementare și și-au înregistrat ecranele; cercetarea nu măsoară exhaustiv toate costurile unei firme. O companie care analizează adoptarea poate fi interesată și de efortul celui care verifică, de durata calendaristică a livrării sau de solicitarea mintală. Aceste rezultate suplimentare au nevoie de definiții proprii; nu pot fi atribuite implicit procentului raportat.
Cunoașterea proiectului schimbă comparația
Pentru un responsabil de mentenanță, faptul că știe unde se potrivește o modificare poate fi un avantaj considerabil. O sugestie plauzibilă a asistentului poate cere în continuare explicații, verificare și adaptare la convențiile proiectului. Aceasta este o interpretare a importanței modului de lucru, nu o nouă estimare cauzală a contribuției fiecărei activități la rezultat.
De aici rezultă că volumul de cod înlocuiește slab munca acceptată. Generarea unei modificări ample ar putea ajuta sau ar putea mări cantitatea de material de verificat. O comparație locală propusă ar trebui să păstreze criteriul de acceptare și să includă efortul de corectare a sugestiilor nepotrivite. Altfel, evaluarea poate recompensa producerea unui material pe care altcineva îl va elimina ulterior.
Păstrați vizibile și încercările abandonate. Dacă echipa măsoară numai modificările asistate acceptate, poate pierde timpul consumat cu asistența la care s-a renunțat. Comparația ar trebui să descrie începutul lucrului, momentul finalizării și tratarea întreruperilor. Acestea sunt recomandări pentru o evaluare viitoare; pentru acest articol nu a fost făcut niciun experiment sau test comparativ AL+.
Instrumentele mai bune sunt un contraargument serios
Obiecția cea mai puternică este că rezultatul de la începutul lui 2025 nu se menține neapărat. Alte instrumente, un context mai bun sau folosirea mai eficientă a acelorași instrumente ar putea schimba rezultatul. METR a avertizat explicit împotriva generalizării la majoritatea dezvoltatorilor sau la sistemele viitoare. Este un motiv pentru repetarea unei comparații relevante, nu pentru prezentarea estimării inițiale drept constatare despre modelele actuale.
Asistența poate merita și pentru alt rezultat decât viteza. Un dezvoltator poate aprecia solicitarea mai mică sau ajutorul la explorarea unei abordări necunoscute, acceptând un timp suplimentar. Precizați acest compromis. Confortul sporit nu dovedește o livrare mai scurtă, iar timpul suplimentar nu dovedește că orice utilizare ar trebui interzisă.
Studiul pune altă întrebare decât măsurile anterioare METR despre orizontul sarcinilor: ce s-a întâmplat cu timpul de finalizare când contribuitorilor care cunoșteau proiectele li s-a permis asistența? Pentru dezvoltare software la comandă, porniți de la această decizie concretă. Păstrați asistența acolo unde rezultatul acceptat și costul verificării o justifică și revizuiți estimările de livrare când efortul măsurat contrazice impresia de progres.
Paul