A cikk tartalma
Ha nézett már egy COCOMO II táblázatot, és látta, ahogy 33 naptári hónapot jósol egy olyan projektre, amelyet csapata két sprint alatt leszállított, akkor már ismeri a problémát: minden ma használt becslési modellt egy olyan világra kalibráltak, amelyben a fejlesztők minden sort maguk gépelnek be, a kontextusváltásnak ára van, és a naptár délután 5-kor megáll. Ez a világ már nem létezik. Nemrég a nulláról fejlesztettünk ki egy 286 KLOC méretű, 672 fájlból álló, több alrendszerre épülő alkalmazást, protokollréteggel, adatréteggel, renderelőmotorral és platformintegrációval, és 7 nap alatt tesztelésre kész alfaverzióig jutottunk. A teljes modellpanel (COCOMO Basic/Intermediate/Post-Architecture, funkciópont, SLOC-alapvonal, Putnam/SLIM) mediánbecslése 30,3 naptári hónap lett. A medián termelékenységi szorzó: 4 240×. Még a legóvatosabb alapvonal (komplex rendszereknél napi 25 SLOC fejlesztőnként) is 1 433-szoros eltérést mutatott. A modellek nem hibásak. Rosszul alkalmazzák őket. Az alábbiakban modellenként bemutatjuk az eredményeket, az ugyanazon szerző munkáján alapuló empirikus kalibrációt, és azt, mit mond valójában a 2024 és 2026 közötti RCT-szakirodalom arról, hol sűríti össze az ágensalapú MI az átfutási időt, és hol nem.
A projekt, amely szétfeszítette a becsléseket
A RIADVICE-nál nemrég egy összetett, funkciókban gazdag alkalmazást fejlesztettünk, olyat, amely több alrendszert hangol össze egy elosztott architektúrában. Natív, platformfüggetlen környezetként készült, amely egyetlen kódbázisból célozza a mobil és az asztali eszközöket, és olyan piaci igények hívták életre, amelyek új implementációt követeltek. A kódbázis mutatja a léptéket:
- 286 662 SLOC (kb. 286 KLOC) 672 forrásfájlban
- 1 329 399 sornyi teljes változás: 862 488 beszúrás és 466 911 törlés
- 700 commit 7 aktív fejlesztési nap alatt, a tesztelésre kész első alfaverzióig
- Teljes nemzetköziesítés több tucat nyelvi változatra
- Több, egymástól mélyen független alrendszer, a protokollkezelés, az adatkezelés, a renderelés és a platformintegráció, mind a nulláról felépítve a célkörnyezethez
Ez nem egy burkoló réteg vagy egy vékony új felület volt. Az alapoktól felépített natív implementáció volt, amely olyan piaci követelményeknek felelt meg, amelyeket a meglévő megoldások nem tudtak teljesíteni. Mielőtt egyetlen sort is megírtam volna, egy saját elemzőeszközt kötöttem be a projektbe, amely a növekvő kódbázison lefuttatja az iparági szabványnak számító szoftverráfordítás-becslési modellek teljes panelét. A cél őszinte volt: megmérni a különbséget aközött, amit a klasszikus modellek jósolnak, és aközött, amit egy MI-támogatott fejlesztés ténylegesen előállít. Az eredmények nem kerekítési hibák. Kategóriaváltást jelentenek.
Mit jósoltak a becslési modellek, és mi történt valójában
Az eszköz a szoftverfejlesztési szakirodalom összes fontosabb becslési modelljét lefuttatja: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached és Embedded, hangolva), COCOMO II Post-Architecture (hangolva), funkciópont-elemzés, SLOC termelékenységi alapvonal és Putnam/SLIM, a projekttípusra kalibrálva, az eredeti forrásirodalomban közzétett állandókkal.
| Becslési modell | Becsült ráfordítás | Becsült naptári idő | Gyorsulás a tényleges időhöz képest |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 emberhónap | 33,3 hónap | 2 282× |
| COCOMO Basic (Semi-Detached) | 1 696 emberhónap | 33,7 hónap | 4 240× |
| COCOMO Basic (Embedded) | 3 200 emberhónap | 33,1 hónap | 8 000× |
| COCOMO Intermediate (Semi-Det., hangolva) | 1 259 emberhónap | 30,4 hónap | 3 148× |
| COCOMO Intermediate (Embedded, hangolva) | 2 376 emberhónap | 30,1 hónap | 5 940× |
| COCOMO II Post-Architecture (hangolva) | 1 703 emberhónap | 30,3 hónap | 4 257× |
| Funkciópont (gyors becslés) | 17,9 emberhónap | 7,5 hónap | 45× |
| SLOC termelékenységi alapvonal (napi 25 SLOC) | 573 emberhónap | 573,3 hónap | 1 433× |
| Putnam/SLIM | kihagyva (az időtartam < 30 nap; a T 4/3 elszáll) | nincs adat | nincs adat |
Az összes modell medián termelékenységi szorzója 4 240×. Még a legóvatosabb modell is nagyjából 1 400-szor hosszabb átfutási időt jósol, mint ami történt. A legoptimistább, a funkciópont-elemzés is 7,5 naptári hónapot jósolt, ami 45-ször hosszabb a tényleges 7 napnál. A modellek szerint ennek a projektnek 7 hónaptól 47 évig bármennyi ideig tarthatott volna. Egy alfaverzió 7 nap alatt készen állt a tesztelésre.
A modellek egymásnak is ellentmondanak, 50-szeres és 8 000-szeres eltéréssel
Ezek a modellek egymással sem értenek egyet. Ugyanezen a kódbázison a becslések 17,9 és 3 200 emberhónap között szórnak, ez 178-szoros különbség. A COCOMO II, a SEER-SEM, a SLIM és a TruePlanning 51 valós projekten végzett SEAA 2013 összehasonlító vizsgálata 50 és 100% közötti MMRE-t talált. Egy 2023-as értékelés a COCOMO NASA adatkészleten 1,0 körüli MMRE-t és 0,0 PRED(0,25) értéket kapott: egyetlen projekt becslése sem esett a 25%-os hibasávon belülre. A modelleket soha nem MI-támogatott projektekre tervezték. A különbség mértéke azonban, még a modellek pontatlanságát is figyelembe véve, azt mutatja, hogy valami szerkezetileg megváltozott.
Mit mond valójában a kutatás az ágensalapú MI-ről és a fejlesztői termelékenységről
A 4 240-szeres érték szélsőséges, és nem szeretném túlértékelni. A zöldmezős vázépítés felfújja a változások mennyiségét, a SLOC pedig gyenge helyettesítője az értéknek. Nézzük tehát a lektorált szakirodalmat. A Copilot-jellegű asszisztensek mérsékelt, de valós nyereséget hoznak. Peng és munkatársai (2023) azt találták, hogy az MI-alapú párprogramozót használó fejlesztők 55,8%-kal gyorsabban végeztek el egy feladatot (95%-os CI: 21 és 89% között). A Microsoft, az Accenture és egy Fortune 100-as vállalat RCT-je (2025), az eddigi legnagyobb vizsgálat (n = 4 867), 26%-kal több elvégzett feladatot mért. A Google belső RCT-je (2024) a feladatra fordított idő kb. 21%-os csökkenését találta. A BIS és az Ant Group terepkísérlete (2024) a junior munkatársaknál 55%-kal több kódkimenetet mért. Az őszinte összegzés: megfelelő feladatoknál 1,26× és 1,56× között. Valós, de nem átütő. Az ágensalapú MI egészen más tartományban működik. A Cognition Devinről szóló 2025-ös áttekintése szerint az ügyfelek 10-szeres eredményt értek el ETL-migrációknál, 14-szerest Java-verziómigrációknál és 20-szorost biztonsági javításoknál. A Nubank 12-szeres hatékonyságjavulásról és 20-szoros költségmegtakarításról számolt be egy több millió soros refaktorálásnál, amelyet korábban többéves, ezer mérnököt igénylő munkára becsültek. A mi portolásunk pontosan ebbe a tartományba esik: a commitok hisztogramja 22:00-kor, 00:00-kor és 01:00-kor sűrű kiugrásokat mutat, ami az ágensvezérelt munkamenetek jellegzetes nyoma. Az ellenbizonyítékok is valósak. A Metr.org 2025-ös RCT-je (16 tapasztalt fejlesztő, 246 feladat érett projekteken) azt találta, hogy az MI 19%-kal növelte a feladatok elvégzésének idejét: lelassította a tapasztalt fejlesztőket az általuk ismert kódbázisokon. Egy 2026-os, 807 MI-eszközt bevezető GitHub-tárolót vizsgáló különbségek különbsége (DiD) tanulmány (He et al., MSR ’26) „átmeneti” sebességnövekedést és a kód összetettségének „tartós” növekedését találta, amely hosszú távon lassuláshoz vezetett. A cím mindent elmond: Speed at the Cost of Quality. A konszenzus: az MI sokat segít a zöldmezős és strukturált fejlesztésben, mérsékelten segít a feladatok elvégzésében, és ronthatja a sebességet érett kódbázisokon. A minőségi adósság valós.
Miért mondanak csődöt a modellek: három szerkezeti változás
A klasszikus modellek egyetlen költségtényezőjében sincs olyan beállítás, hogy „a fejlesztőnek van egy autonóm ágense, amely soha nem alszik, és a teljes kódbázist a kontextusában tartja”. Három változás omlasztja össze az átfutási idő görbéjét:
- Eltűnt a gépelés szűk keresztmetszete.
A modellek feltételezik, hogy a ráfordítás jelentős része mechanikus munka: sablonkód, vázépítés, ismétlődő refaktorálások, lokalizációs erőforrások és más strukturált adatok. Ebben a portolásban a mennyiség nagy része rendkívül szabályos szöveg és bekötés, amelyet egy ágens tömegesen tud előállítani vagy átalakítani. Maga a kézzel írt kód, a vázak, a konstruktorok és a platformot összekötő kód, most rohamokban generálódik, nem soronként gépelve.
- Összeomlik a kontextusváltás költsége.
Egy ember, aki a protokollréteg, az adatréteg és a renderelőmotor között vált, minden alkalommal megfizeti a kontextus betöltésének árát. Egy ágens, amely a teljes, 672 fájlos tárolót elolvasta, egyszer fizeti meg. Ez az aszimmetria egy ekkora kódbázison gyorsan halmozódik.
- Már nem a naptár a szűk keresztmetszet.
A modellek egy olyan létszámegyenlettel váltják át az emberhónapokat naptári hónapokra, amely emberi munkanappal számol. Az ágensek munkamenetei éjszaka is futnak. A commitok hisztogramja 07:00-tól 01:00-ig folyamatos kimenetet mutat: 18 aktív óra, nem 8.
Empirikus kalibráció ugyanazon szerző munkáján
A parametrikus modellek nagyságrendekkel térnek el egymástól, ezért empirikus, projekteken átívelő kalibrációt is végeztem: összevetettem saját, személynapra jutó kódváltozásomat egy ágensalapú MI-eszköz bevezetése előtt és után, ugyanabban az ökoszisztémában működő három másik éles tárolón:
| Projekt | Változás/fejlesztőnap MI előtt | Változás/fejlesztőnap MI-vel | Szorzó |
|---|---|---|---|
| A projekt (terheléselosztó) | 673 | 2 056 | 3,1× |
| B projekt (jelentéskészítő szolgáltatás) | 239 | 2 127 | 8,9× |
| C projekt (feldolgozó szolgáltatás) | 1 322 | 982 | 0,7× |
| Összesítés (átlag / medián) | nincs adat | nincs adat | 4,2× / 3,1× |
Ugyanaz a szerző, ugyanaz a szakterület, valódi karbantartási munka. Az empirikus szorzó 3 és 9× között van: jóval óvatosabb, mint a zöldmezős 4 240-szeres érték, és összhangban van az ágensalapú MI-ről közzétett kutatások felső tartományával. Az egyik projekt valójában lassabb lett: a nyereség feladatfüggő, nem általános.
Mit jelent ez a projekttervezés számára
Ha szoftverprojektjeit még mindig kalibrálatlan modellekkel és napi 25 SLOC-os alapvonallal becsüli, MI-támogatott munkánál egy-három nagyságrendet fog tévedni. A RIADVICE-nál a következőképpen járunk el:
- Kalibráljon a saját múltjához. Vesse össze a személynapra jutó saját kódkimenetét MI-vel és MI nélkül. Ez olcsóbb, őszintébb, és olyan 3 és 9× közötti tartományt ad, amelyet egy projekttervben meg tud védeni.
- Válassza külön a zöldmezős fejlesztést a karbantartástól. Az ágensalapú MI szorzója a zöldmezős és strukturált fejlesztésben a legnagyobb, érett kódbázisok karbantartásában a legkisebb (néha negatív). Ne alkalmazzon egyetlen számot mindkettőre.
- Számoljon a minőségi adóssággal. Az MI-vel elért sebesség a komplexitás tartós növekedésével jár. Tervezzen be egy stabilizálási szakaszt, és mérje: kövesse a ciklomatikus komplexitást, és minden kiadásnál futtasson kódismétlés-keresést.
- A teljes görbét becsülje, ne csak az elejét. Az a 10-szeres sebességnövekedés, amely megduplázza a hibasűrűséget, nem 10-szeres nyereség, hanem előrehozott ütemterv, amelynek ára egy hosszabb stabilizációs szakasz a végén.
A lényeg
Egy projekt, amelyről minden becslési modell azt mondja, hogy 7 hónaptól 47 évig tartana, 7 nap alatt jutott el egy tesztelésre kész alfaverzióig. A 4 240-szeres medián szorzóból senkinek se legyen projektterve. Világos jelzés viszont arra, hogy az összetett szoftverfejlesztés átfutási idejét ugyanaz az erő sűríti újra össze, amely a ráfordítást is. A közzétett kutatások szerint az MI az 1,26-szoros enyhe lökéstől a 20-szoros ugrásig bármit hozhat, érett kódbázisokon valós kockázattal jár a negatív megtérülés, és mérhető minőségi árat kell érte fizetni. Azok a modellek, amelyek szerint ennek a projektnek évtizedekig kellett volna tartania, ugyanazok, amelyek ma is futnak a vállalati becslési táblázatokban. A kérdés nem az, hogy az ágensalapú MI megváltoztatja-e a projektek átfutási idejét: erre a kutatás már választ adott. A kérdés az, hogy az Ön becslési gyakorlata utolérte-e a bizonyítékokat. Ha számai még mindig egy COBOL-ra és assemblyre kalibrált 1981-es modellből származnak, ideje újrakalibrálni, vagy legalább nem hinni a naptárnak, amelyet kinyomtat.
„Még mindig jelentős a fejlődési lehetőség ahhoz, hogy jobban kezelni lehessen a gyakorlatban felmerülő előrejelzési kihívásokat.”
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Megbízható mérnöki és felhőszakértelem
RIADVICE: megbízható partnere a szoftverfejlesztésben
Összetett szoftverrendszereket tervezünk, építünk és telepítünk azzal a mérnöki fegyelemmel és eszközkészlettel, amellyel az MI korában is határidőre, a költségkereten belül és megfelelő minőségben szállítunk.
További információ szolgáltatásainkról
📚 Források és további olvasnivaló
Ez a cikk lektorált kutatásokra, randomizált kontrollált vizsgálatokra és iparági terepjelentésekre támaszkodik az MI-támogatott szoftverfejlesztés termelékenységéről és a szoftverráfordítás becsléséről:
- MI-termelékenységi vizsgálatok (RCT-k és terepkísérletek)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: a feladat elvégzési ideje 55,8%-kal csökkent
- 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% elvégzett feladat
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: Google RCT, n = 96, a feladatra fordított idő kb. 21%-os csökkenése
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: RCT, n = 16, 246 feladat; az MI 19%-kal növelte a feladatok elvégzésének idejét
- 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: DiD-vizsgálat 807 GitHub-tárolón; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Replikációs eredmény: +13% (nem szignifikáns)
- Iparági jelentések az ágensalapú MI-ről
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× ETL-migrációknál, 14× Java-migrációknál, 20× biztonsági javításoknál
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× mérnöki munkaóra, 20× költségmegtakarítás egy több millió soros refaktorálásnál
- BIS / Ant Group (2024). Terepkísérlet; +55% kódkimenet, főként a junior munkatársaknál
- Szoftverráfordítás-becslés: alapok és pontosság
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: az eredeti COCOMO
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: 161 projekten kalibrálva
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II, SEER-SEM, SLIM, TruePlanning 51 projekten; MMRE 50 és 100% között
- 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 Ablakalapú kalibráció 341 + 93 projekten
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort Estimation MMRE kb. 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: a Putnam/SLIM modell
⚡ A RIADVICE.com megbízható mérnöki munkát, felhőszakértelmet és vállalati szintű szoftvermegoldásokat nyújt, határidőre, a költségkereten belül és megfelelő minőségben.
