În acest articol
Dacă ați privit vreodată o foaie de calcul COCOMO II care estima 33 de luni calendaristice pentru un proiect pe care echipa dumneavoastră l-a livrat în două sprinturi, cunoașteți deja problema: toate modelele de estimare folosite astăzi în producție au fost calibrate într-o lume în care dezvoltatorii tastează fiecare linie, schimbarea contextului are un cost, iar calendarul se oprește la ora 17. Acea lume nu mai există. Am dezvoltat recent de la zero o aplicație de 286 KLOC, cu 672 de fișiere și mai multe subsisteme (strat de protocol, strat de date, motor de randare, integrare cu platforma) și am ajuns la o versiune alpha pregătită pentru testare în 7 zile. Setul complet de modele (COCOMO Basic/Intermediate/Post-Architecture, Function Points, referința SLOC, Putnam/SLIM) a dat o estimare mediană de 30,3 luni calendaristice. Multiplicatorul median de productivitate: 4.240×. Chiar și cea mai prudentă referință (25 SLOC pe zi-dezvoltator pentru sisteme complexe) a greșit de 1.433×. Modelele nu sunt greșite. Sunt aplicate greșit. Mai jos găsiți analiza model cu model, calibrarea empirică pe proiectele aceluiași autor și ce spune de fapt literatura RCT din perioada 2024-2026 despre situațiile în care IA agentică scurtează durata proiectelor, și despre cele în care nu o face.
Proiectul care a dat peste cap estimările
La RIADVICE am dezvoltat recent o aplicație complexă și bogată în funcționalități, de tipul celor care coordonează mai multe subsisteme într-o arhitectură distribuită, ca mediu nativ multiplatformă pentru mobil și desktop dintr-o singură bază de cod, la cererea pieței, care avea nevoie de o nouă implementare. Baza de cod arată amploarea:
- 286.662 SLOC (~286 KLOC), repartizate în 672 de fișiere sursă
- 1.329.399 de linii modificate în total: 862.488 de inserări și 466.911 ștergeri
- 700 de commituri în 7 zile active de dezvoltare până la prima versiune alpha pregătită pentru testare
- Internaționalizare completă în zeci de limbi
- Mai multe subsisteme fără nicio legătură între ele (gestionarea protocolului, gestionarea datelor, randarea și integrarea cu platforma), toate construite de la zero pentru mediul țintă
Nu a fost un wrapper sau o simplă schimbare de aspect. A fost o implementare nativă construită de la zero pentru a satisface cerințe ale pieței pe care soluțiile existente nu le puteau acoperi. Înainte de a scrie o singură linie, am conectat la proiect un instrument de analiză propriu, care rulează setul complet de modele standard din industrie pentru estimarea efortului software pe baza de cod, pe măsură ce aceasta crește. Scopul a fost unul onest: să măsurăm distanța dintre ce prezic modelele clasice și ce produce efectiv o livrare asistată de IA. Rezultatele nu sunt o eroare de rotunjire. Sunt o ruptură de categorie.
Ce au prezis modelele de estimare și ce s-a întâmplat de fapt
Instrumentul rulează toate modelele de estimare importante din literatura de inginerie software: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached și Embedded, ajustate), COCOMO II Post-Architecture (ajustat), Function Points, referința de productivitate SLOC și Putnam/SLIM, calibrate pentru tipul de proiect cu constantele publicate în literatura de origine.
| Model de estimare | Efort estimat | Durată calendaristică estimată | Accelerare față de realitate |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 om-luni | 33,3 luni | 2.282× |
| COCOMO Basic (Semi-Detached) | 1.696 om-luni | 33,7 luni | 4.240× |
| COCOMO Basic (Embedded) | 3.200 om-luni | 33,1 luni | 8.000× |
| COCOMO Intermediate (Semi-Det., ajustat) | 1.259 om-luni | 30,4 luni | 3.148× |
| COCOMO Intermediate (Embedded, ajustat) | 2.376 om-luni | 30,1 luni | 5.940× |
| COCOMO II Post-Architecture (ajustat) | 1.703 om-luni | 30,3 luni | 4.257× |
| Function Points (calcul aproximativ) | 17,9 om-luni | 7,5 luni | 45× |
| Referința de productivitate SLOC (25 SLOC/zi) | 573 om-luni | 573,3 luni | 1.433× |
| Putnam/SLIM | omis (durată < 30 de zile; T 4/3 explodează) | n/a | n/a |
Multiplicatorul median de productivitate pentru toate modelele este 4.240×. Chiar și cel mai prudent model estimează un termen de livrare de aproximativ 1.400 de ori mai lung decât cel real. Cel mai optimist, Function Points, a estimat totuși 7,5 luni calendaristice, adică de 45 de ori mai mult decât cele 7 zile reale. Potrivit modelelor, proiectul ar fi trebuit să dureze între 7 luni și 47 de ani. O versiune alpha a fost pregătită pentru testare în 7 zile.
Modelele nu se pun de acord între ele: diferențe de la 50× la 8.000×
Aceste modele nu concordă între ele. Pe aceeași bază de cod, estimările variază între 17,9 și 3.200 de om-luni, o dispersie de 178×. Studiul comparativ SEAA 2013 al modelelor COCOMO II, SEER-SEM, SLIM și TruePlanning pe 51 de proiecte reale a găsit un MMRE între 50% și 100%. O evaluare din 2023 pe setul de date COCOMO NASA a găsit un MMRE de aproape 1,0 și PRED(0,25) = 0,0: niciun proiect nu a fost estimat în intervalul de eroare de 25%. Modelele nu au fost concepute niciodată pentru un proiect asistat de IA. Dar mărimea diferenței, chiar ținând cont de imprecizia modelelor, ne arată că ceva s-a schimbat structural.
Ce spun cu adevărat cercetările despre IA agentică și productivitatea dezvoltatorilor
Cifra de 4.240× este extremă și nu vreau să o exagerez. Proiectele pornite de la zero umflă volumul de modificări, iar SLOC este un indicator slab al valorii. Să ne uităm, așadar, la literatura evaluată de experți. Asistenții de tip Copilot aduc câștiguri modeste, dar reale. Peng et al. (2023) au constatat că dezvoltatorii care foloseau un programator-pereche bazat pe IA au finalizat o sarcină cu 55,8% mai repede (IÎ 95%: între 21% și 89%). RCT-ul Microsoft/Accenture/Fortune 100 (2025), cel mai amplu studiu de până acum, cu n=4.867, a constatat o creștere de 26% a sarcinilor finalizate. RCT-ul intern al Google (2024) a constatat o reducere de ~21% a timpului petrecut pe sarcină. Experimentul de teren BIS/Ant Group (2024) a măsurat o creștere de 55% a volumului de cod produs de angajații juniori. Rezumatul onest: între 1,26× și 1,56× pe sarcinile potrivite. Real, dar nu transformator. IA agentică funcționează într-un alt regim. Analiza Cognition din 2025 despre Devin a raportat rezultate la clienți de 10× la migrările ETL, 14× la migrările de versiune Java și 20× la corecturile de securitate. Nubank a raportat o creștere de 12× a eficienței și economii de costuri de 20× la un refactoring de câteva milioane de linii, estimat anterior ca un efort de mai mulți ani pentru o mie de ingineri. Proiectul nostru se încadrează exact în acest interval: histograma commiturilor arată vârfuri dense la 22:00, 00:00 și 01:00, semnătura sesiunilor conduse de agenți. Dovezile contrare sunt reale. RCT-ul Metr.org din 2025 (16 dezvoltatori cu experiență, 246 de sarcini pe proiecte mature) a constatat că IA a crescut timpul de finalizare cu 19%: i-a încetinit pe dezvoltatorii cu experiență pe baze de cod pe care le cunoșteau. Un studiu din 2026 de tip diferență în diferențe pe 807 depozite GitHub care adoptaseră instrumente de IA (He et al., MSR ’26) a constatat o accelerare „tranzitorie” și o creștere „persistentă” a complexității codului, care a dus la o încetinire pe termen lung. Titlul spune totul: Speed at the Cost of Quality. Consensul: IA ajută mult la dezvoltarea de la zero și la cea structurată, ajută modest la sarcinile de completare și poate frâna viteza pe bazele de cod mature. Datoria de calitate este reală.
De ce cedează modelele: trei schimbări structurale
Niciunul dintre factorii de cost ai modelelor clasice nu are o setare pentru „dezvoltatorul are un agent autonom care nu doarme niciodată și ține întreaga bază de cod în context”. Trei schimbări prăbușesc curba duratei:
- Blocajul tastării a dispărut.
Modelele presupun că o parte importantă a efortului este mecanică: cod repetitiv, scheletul aplicației, refactorizări repetitive, resurse de localizare și alte date structurate. În acest proiect, o mare parte din volum este text foarte regulat și cod de legătură pe care un agent îl poate genera sau transforma în bloc. Codul scris de mână propriu-zis (schelet, constructori, cod de legătură cu platforma) este acum generat în rafale, nu tastat linie cu linie.
- Costul schimbării contextului se prăbușește.
Un om care trece de la stratul de protocol la stratul de date și la motorul de randare plătește de fiecare dată un cost de reîncărcare a contextului. Un agent care a citit întregul depozit de 672 de fișiere îl plătește o singură dată. Această asimetrie se acumulează rapid pe o bază de cod de asemenea dimensiuni.
- Calendarul nu mai este blocajul.
Modelele convertesc om-lunile în luni calendaristice printr-o ecuație de alocare a personalului care presupune o zi de lucru umană. Sesiunile agenților rulează peste noapte. Histograma commiturilor arată o producție susținută de la 07:00 până la 01:00: 18 ore active, nu 8.
Calibrarea empirică pe proiectele aceluiași autor
Modelele parametrice diferă între ele cu ordine de mărime, așa că am rulat și o calibrare empirică între proiecte, comparând volumul meu de modificări de cod pe zi-om înainte și după adoptarea unui instrument de IA agentică, pe alte trei depozite de producție din același ecosistem:
| Proiect | Modificări/zi înainte de IA | Modificări/zi în era IA | Multiplicator |
|---|---|---|---|
| Proiectul A (load balancer) | 673 | 2.056 | 3,1× |
| Proiectul B (serviciu de raportare) | 239 | 2.127 | 8,9× |
| Proiectul C (serviciu de procesare) | 1.322 | 982 | 0,7× |
| Total (medie / mediană) | n/a | n/a | 4,2× / 3,1× |
Același autor, același domeniu, muncă reală de mentenanță. Multiplicatorul empiric este între 3× și 9×, mult mai prudent decât cifra de 4.240× pentru dezvoltarea de la zero și în acord cu partea superioară a cercetărilor publicate despre IA agentică. Un proiect a devenit chiar mai lent: câștigurile depind de sarcină, nu sunt universale.
Ce înseamnă acest lucru pentru planificarea proiectelor
Dacă estimați în continuare proiecte software cu modele necalibrate și o referință de 25 SLOC pe zi, veți greși cu unul până la trei ordine de mărime în cazul muncii asistate de IA. Iată ce facem la RIADVICE:
- Calibrați pe propriul istoric. Comparați volumul propriu de cod pe zi-om cu și fără IA. Este mai ieftin, mai onest și oferă un interval între 3× și 9× pe care îl puteți susține într-un plan de proiect.
- Separați dezvoltarea de la zero de mentenanță. Multiplicatorul IA agentice este cel mai mare la dezvoltarea de la zero și la cea structurată și cel mai mic (uneori negativ) la mentenanța bazelor de cod mature. Nu aplicați aceeași cifră ambelor situații.
- Bugetați datoria de calitate. Viteza adusă de IA vine cu creșteri persistente ale complexității. Planificați o fază de consolidare și instrumentați-o: urmăriți complexitatea ciclomatică și rulați detecția codului duplicat la fiecare versiune.
- Estimați întreaga curbă, nu doar începutul ei. Un câștig de viteză de 10× care vă dublează densitatea defectelor nu este un câștig de 10×: este un calendar adus înainte cu prețul unei perioade de stabilizare mai lungi.
Concluzia
Un proiect pentru care toate modelele de estimare prevedeau între 7 luni și 47 de ani a ajuns la o versiune alpha pregătită pentru testare în 7 zile. Multiplicatorul median de 4.240× nu ar trebui să devină planul de proiect al nimănui. Este însă un semnal clar că durata dezvoltării de software complex este comprimată de aceeași forță care comprimă efortul. Cercetările publicate arată că IA aduce orice, de la un mic impuls de 1,26× la un salt de 20×, cu un risc real de randament negativ pe bazele de cod mature și cu un cost de calitate măsurabil. Modelele care ne spuneau că acest proiect ar trebui să dureze decenii sunt aceleași care rulează și astăzi în foile de calcul de estimare ale întreprinderilor. Întrebarea nu este dacă IA agentică schimbă durata proiectelor: cercetările au răspuns deja. Întrebarea este dacă practica dumneavoastră de estimare a ținut pasul cu dovezile. Dacă cifrele dumneavoastră vin încă dintr-un model din 1981 calibrat pe COBOL și assembler, este timpul să recalibrați sau măcar să nu mai credeți calendarul pe care îl afișează.
„Există încă un spațiu semnificativ de îmbunătățire pentru a aborda mai bine provocările de predicție întâlnite în practică.”
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Expertiză de încredere în inginerie și cloud
RIADVICE, partenerul dumneavoastră de încredere în ingineria software
Proiectăm, construim și implementăm sisteme software complexe, cu disciplina inginerească și instrumentele necesare pentru a livra în era IA: la termen, în buget și la calitatea promisă.
Aflați mai multe despre serviciile noastre
📚 Surse și lecturi suplimentare
Acest articol se bazează pe cercetări evaluate de experți, studii randomizate controlate și rapoarte din industrie privind productivitatea dezvoltării software asistate de IA și estimarea efortului software:
- Studii de productivitate IA (RCT-uri și experimente de teren)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: reducere de 55,8% a timpului de finalizare a sarcinii
- Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers Microsoft Research: n=4.867, +26,08% sarcini finalizate
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: RCT Google, n=96, reducere de ~21% a timpului petrecut pe sarcină
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: RCT, n=16, 246 de sarcini; IA a crescut timpul de finalizare cu 19%
- He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, arXiv:2511.04427: studiu de tip diferență în diferențe pe 807 depozite GitHub; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Replicare: +13% (nesemnificativ)
- Rapoarte din industrie despre IA agentică
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× la migrările ETL, 14× la migrările Java, 20× la corecturile de securitate
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× la orele de inginerie, economii de costuri de 20× la un refactoring de câteva milioane de linii
- BIS / Ant Group (2024). Experiment de teren; +55% volum de cod, concentrat la angajații juniori
- Estimarea efortului software: fundamente și precizie
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: modelul COCOMO original
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: calibrat pe 161 de proiecte
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II, SEER-SEM, SLIM, TruePlanning pe 51 de proiecte; MMRE între 50% și 100%
- Kemerer, C. F. (1993). An empirical validation of software cost estimation models, Communications of the ACM
- Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibration Calibrare pe ferestre, pe 341 + 93 de proiecte
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort Estimation MMRE ~1,0, PRED(0,25) = 0,0
- Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE: modelul Putnam/SLIM
⚡ RIADVICE.com oferă inginerie de încredere, expertiză cloud și soluții software de nivel enterprise: la termen, în buget și la calitatea promisă.





