W tym artykule
Każdy, kto kiedykolwiek patrzył w arkusz COCOMO II prognozujący 33 miesiące kalendarzowe dla projektu, który zespół dostarczył w dwa sprinty, zna ten problem: każdy model szacowania stosowany dziś w praktyce został skalibrowany w świecie, w którym programiści wpisują każdy wiersz ręcznie, przełączanie kontekstu ma swoją cenę, a kalendarz zatrzymuje się o 17:00. Ten świat już nie istnieje. Niedawno od zera stworzyliśmy aplikację liczącą 286 KLOC i 672 pliki, złożoną z wielu podsystemów (warstwa protokołu, warstwa danych, silnik renderowania, integracja z platformą), i w 7 dni doprowadziliśmy ją do wersji alfa gotowej do testów. Pełen zestaw modeli (COCOMO Basic/Intermediate/Post-Architecture, Function Points, wskaźnik bazowy SLOC, Putnam/SLIM) zwrócił medianę prognoz wynoszącą 30,3 miesiąca kalendarzowego. Mediana mnożnika produktywności: 4240×. Nawet najbardziej zachowawczy wskaźnik bazowy (25 SLOC na osobodzień dla systemów złożonych) pomylił się 1433-krotnie. Modele nie są błędne. Są źle stosowane. Poniżej przedstawiamy zestawienie model po modelu, empiryczną kalibrację na pracy tego samego autora oraz to, co literatura RCT z lat 2024 do 2026 faktycznie mówi o tym, gdzie agentowa AI skraca czas realizacji, a gdzie nie.
Projekt, który rozbił szacunki
W RIADVICE stworzyliśmy niedawno złożoną aplikację o bogatej funkcjonalności, taką, która koordynuje wiele podsystemów w rozproszonej architekturze, jako natywne środowisko wieloplatformowe dla urządzeń mobilnych i komputerów stacjonarnych z jednej bazy kodu. Nową implementację wymusiły wymagania rynku. Skalę pokazuje sam kod:
- 286 662 SLOC (~286 KLOC) w 672 plikach źródłowych
- 1 329 399 wierszy łącznych zmian: 862 488 dodanych i 466 911 usuniętych
- 700 commitów w ciągu 7 aktywnych dni pracy do pierwszej wersji alfa gotowej do testów
- Pełna internacjonalizacja na kilkadziesiąt wersji językowych
- Wiele zupełnie niezwiązanych ze sobą podsystemów (obsługa protokołu, zarządzanie danymi, renderowanie i integracja z platformą), wszystkie zbudowane od zera dla docelowego środowiska
Nie była to nakładka ani powierzchowna zmiana wyglądu. Była to natywna implementacja zbudowana od podstaw, aby spełnić wymagania rynku, którym istniejące rozwiązania nie sprostały. Zanim napisałem pierwszy wiersz, podłączyłem do projektu własne narzędzie analityczne, które w miarę rozrastania się kodu uruchamia na nim pełen zestaw standardowych w branży modeli szacowania pracochłonności oprogramowania. Cel był uczciwy: zmierzyć różnicę między tym, co przewidują klasyczne modele, a tym, co faktycznie daje realizacja wspierana przez AI. Wyniki to nie błąd zaokrąglenia. To zmiana kategorii.
Co przewidziały modele szacowania, a co wydarzyło się naprawdę
Narzędzie uruchamia każdy ważny model szacowania z literatury inżynierii oprogramowania: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached i Embedded, dostrojone), COCOMO II Post-Architecture (dostrojony), Function Points, wskaźnik bazowy produktywności SLOC oraz Putnam/SLIM, skalibrowane do typu projektu przy użyciu stałych opublikowanych w oryginalnej literaturze źródłowej.
| Model szacowania | Prognozowana pracochłonność | Prognozowany czas kalendarzowy | Przyspieszenie względem rzeczywistości |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 osobomiesięcy | 33,3 miesiąca | 2282× |
| COCOMO Basic (Semi-Detached) | 1696 osobomiesięcy | 33,7 miesiąca | 4240× |
| COCOMO Basic (Embedded) | 3200 osobomiesięcy | 33,1 miesiąca | 8000× |
| COCOMO Intermediate (Semi-Det., dostrojony) | 1259 osobomiesięcy | 30,4 miesiąca | 3148× |
| COCOMO Intermediate (Embedded, dostrojony) | 2376 osobomiesięcy | 30,1 miesiąca | 5940× |
| COCOMO II Post-Architecture (dostrojony) | 1703 osobomiesiące | 30,3 miesiąca | 4257× |
| Function Points (szacunek orientacyjny) | 17,9 osobomiesiąca | 7,5 miesiąca | 45× |
| Wskaźnik bazowy SLOC (25 SLOC na osobodzień) | 573 osobomiesiące | 573,3 miesiąca | 1433× |
| Putnam/SLIM | pominięty (czas trwania < 30 dni; T 4/3 eksploduje) | n/d | n/d |
Mediana mnożnika produktywności dla wszystkich modeli wynosi 4240×. Nawet najbardziej zachowawczy model przewiduje czas realizacji mniej więcej 1400 razy dłuższy niż rzeczywisty. Najbardziej optymistyczny, Function Points, wciąż przewidział 7,5 miesiąca kalendarzowego, czyli 45 razy dłużej niż faktyczne 7 dni. Według modeli projekt powinien był trwać od 7 miesięcy do 47 lat. Wersja alfa była gotowa do testów po 7 dniach.
Modele nie zgadzają się ze sobą, i to 50- do 8000-krotnie
Te modele nie są ze sobą zgodne. Dla tej samej bazy kodu prognozy wahają się od 17,9 do 3200 osobomiesięcy, co daje 178-krotny rozrzut. Benchmark SEAA 2013 obejmujący COCOMO II, SEER-SEM, SLIM i TruePlanning na 51 rzeczywistych projektach wykazał MMRE na poziomie od 50 do 100%. Ewaluacja z 2023 roku na zbiorze danych COCOMO NASA wykazała MMRE bliskie 1,0 i PRED(0,25) = 0,0: ani jeden projekt nie został oszacowany w granicach 25% błędu. Modele nigdy nie były projektowane z myślą o projektach wspieranych przez AI. Jednak wielkość tej różnicy, nawet po uwzględnieniu niedokładności modeli, mówi nam, że zmieniło się coś strukturalnego.
Co naprawdę mówią badania o agentowej AI i produktywności programistów
Wartość 4240× jest skrajna i nie chcę jej przeceniać. Tworzenie szkieletu nowego projektu od zera zawyża liczbę zmian, a SLOC to słaba miara wartości. Spójrzmy więc na recenzowaną literaturę. Asystenci w stylu Copilota dają umiarkowane, ale realne korzyści. Peng i in. (2023) wykazali, że programiści korzystający z programisty-partnera AI ukończyli zadanie o 55,8% szybciej (95% CI: od 21 do 89%). RCT Microsoft/Accenture/Fortune 100 (2025), największe dotąd badanie (n=4867), wykazało wzrost liczby ukończonych zadań o 26%. Wewnętrzne RCT Google (2024) wykazało skrócenie czasu pracy nad zadaniem o ~21%. Eksperyment terenowy BIS/Ant Group (2024) zmierzył wzrost ilości wytwarzanego kodu o 55% wśród młodszych pracowników. Uczciwe podsumowanie: od 1,26× do 1,56× przy odpowiednich zadaniach. Realnie, ale nie przełomowo. Agentowa AI działa w innym reżimie. Przegląd Devina opublikowany przez Cognition w 2025 roku podał wyniki klientów: 10× przy migracjach ETL, 14× przy migracjach wersji Javy i 20× przy poprawkach bezpieczeństwa. Nubank odnotował 12-krotną poprawę efektywności i 20-krotne oszczędności kosztów przy refaktoryzacji wielu milionów wierszy kodu, wcześniej szacowanej na wieloletnie przedsięwzięcie z udziałem tysiąca inżynierów. Nasz port mieści się dokładnie w tym przedziale: histogram commitów pokazuje gęste serie o 22:00, 00:00 i 01:00, typowe dla sesji prowadzonych przez agenty. Dowody przeciwne również są realne. RCT Metr.org z 2025 roku (16 doświadczonych programistów, 246 zadań w dojrzałych projektach) wykazało, że AI wydłużyła czas realizacji o 19%: spowolniła doświadczonych programistów pracujących ze znanym kodem. Badanie metodą różnicy w różnicach z 2026 roku, obejmujące 807 repozytoriów GitHub, w których wdrożono narzędzia AI (He i in., MSR ’26), wykazało „przejściowy” wzrost tempa i „trwały” wzrost złożoności kodu, który prowadził do długoterminowego spowolnienia. Tytuł mówi wszystko: Speed at the Cost of Quality. Konsensus: AI bardzo pomaga przy nowych projektach i ustrukturyzowanym wytwarzaniu oprogramowania, umiarkowanie przy zadaniach polegających na uzupełnianiu kodu i może obniżyć tempo pracy w dojrzałych bazach kodu. Dług jakościowy jest realny.
Dlaczego modele zawodzą: trzy zmiany strukturalne
Żaden z czynników kosztowych w klasycznych modelach nie przewiduje ustawienia „programista ma autonomicznego agenta, który nigdy nie śpi i trzyma w kontekście całą bazę kodu”. Trzy zmiany spłaszczają krzywą czasu realizacji:
- Wąskie gardło pisania zniknęło.
Modele zakładają, że znaczna część pracy jest mechaniczna: kod szablonowy, szkielety, powtarzalne refaktoryzacje, zasoby lokalizacyjne i inne dane ustrukturyzowane. W tym porcie duża część objętości to bardzo regularny tekst i połączenia, które agent może generować lub przekształcać hurtowo. Kod pisany ręcznie, czyli szkielety, konstruktory i warstwa łącząca z platformą, jest teraz generowany seriami, a nie wpisywany wiersz po wierszu.
- Koszt przełączania kontekstu gwałtownie spada.
Człowiek przełączający się między warstwą protokołu, warstwą danych a silnikiem renderowania za każdym razem płaci podatek za ładowanie kontekstu. Agent, który przeczytał całe repozytorium liczące 672 pliki, płaci go raz. Przy bazie kodu tej wielkości ta asymetria szybko się kumuluje.
- Kalendarz nie jest już wąskim gardłem.
Modele przeliczają osobomiesiące na miesiące kalendarzowe za pomocą równania obsady, które zakłada ludzki dzień pracy. Sesje agentów trwają przez noc. Histogram commitów pokazuje ciągłą produktywność od 07:00 do 01:00: 18 aktywnych godzin, a nie 8.
Empiryczna kalibracja na pracy tego samego autora
Modele parametryczne różnią się o rzędy wielkości, dlatego przeprowadziłem również empiryczną kalibrację międzyprojektową, porównując moją własną liczbę zmian w kodzie na osobodzień przed wdrożeniem agentowego narzędzia AI i po nim w trzech innych repozytoriach produkcyjnych z tego samego ekosystemu:
| Projekt | Zmiany na osobodzień przed AI | Zmiany na osobodzień w erze AI | Mnożnik |
|---|---|---|---|
| Projekt A (load balancer) | 673 | 2056 | 3,1× |
| Projekt B (usługa raportowania) | 239 | 2127 | 8,9× |
| Projekt C (usługa przetwarzania) | 1322 | 982 | 0,7× |
| Łącznie (średnia / mediana) | n/d | n/d | 4,2× / 3,1× |
Ten sam autor, ta sama dziedzina, rzeczywiste prace utrzymaniowe. Empiryczny mnożnik wynosi od 3 do 9×, czyli jest znacznie bardziej zachowawczy niż wartość 4240× dla nowego projektu i zgodny z górną granicą opublikowanych badań nad agentową AI. Jeden projekt faktycznie zwolnił: korzyści zależą od rodzaju zadania i nie są uniwersalne.
Co to oznacza dla planowania projektów
Jeśli nadal szacują Państwo projekty programistyczne za pomocą nieskalibrowanych modeli i wskaźnika bazowego 25 SLOC dziennie, przy pracy wspieranej przez AI pomylą się Państwo o jeden do trzech rzędów wielkości. Oto, jak postępujemy w RIADVICE:
- Kalibracja na własnej historii. Należy porównać własną ilość wytwarzanego kodu na osobodzień z AI i bez niej. To tańsze, uczciwsze i daje przedział od 3 do 9×, którego można bronić w planie projektu.
- Oddzielenie nowych projektów od utrzymania. Mnożnik agentowej AI jest największy przy nowych projektach i ustrukturyzowanym wytwarzaniu, a najmniejszy (czasem ujemny) przy utrzymaniu dojrzałych baz kodu. Nie należy stosować jednej liczby do obu przypadków.
- Budżet na dług jakościowy. Tempo pracy z AI idzie w parze z trwałym wzrostem złożoności. Warto zaplanować fazę utwardzania i ją opomiarować: śledzić złożoność cyklomatyczną i przy każdym wydaniu wykrywać kod kopiowany.
- Szacowanie całej krzywej, a nie tylko jej początku. Dziesięciokrotny wzrost tempa, który podwaja gęstość defektów, nie jest dziesięciokrotnym zyskiem: to harmonogram przesunięty do przodu kosztem dłuższego okresu stabilizacji.
Podsumowanie
Projekt, który według wszystkich modeli szacowania powinien trwać od 7 miesięcy do 47 lat, osiągnął wersję alfa gotową do testów w 7 dni. Mediana mnożnika 4240× nie powinna stać się niczyim planem projektu. Jest jednak wyraźnym sygnałem, że czas trwania złożonych projektów programistycznych ulega ponownej kompresji pod wpływem tej samej siły, która kompresuje pracochłonność. Opublikowane badania pokazują, że AI daje od lekkiego przyspieszenia rzędu 1,26× po 20-krotny skok, przy realnym ryzyku ujemnych zwrotów w dojrzałych bazach kodu i mierzalnym podatku jakościowym. Modele, według których ten projekt powinien trwać dziesięciolecia, to te same modele, które wciąż działają dziś w arkuszach szacunkowych przedsiębiorstw. Pytanie nie brzmi, czy agentowa AI zmienia czas realizacji projektów: badania już na nie odpowiedziały. Pytanie brzmi, czy Państwa praktyka szacowania nadąża za dowodami. Jeśli Państwa liczby wciąż pochodzą z modelu z 1981 roku skalibrowanego na COBOL-u i asemblerze, czas na ponowną kalibrację, a przynajmniej na to, by przestać wierzyć w kalendarz, który ten model drukuje.
„Wciąż pozostaje wiele do poprawienia, aby lepiej sprostać wyzwaniom prognostycznym, z jakimi mierzy się praktyka.”
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Zaufana wiedza inżynierska i chmurowa
RIADVICE: zaufany partner w inżynierii oprogramowania
Projektujemy, budujemy i wdrażamy złożone systemy oprogramowania z dyscypliną inżynierską i narzędziami pozwalającymi realizować projekty w erze AI: w terminie, w budżecie i z zachowaniem jakości.
📚 Źródła i dalsza lektura
Artykuł opiera się na recenzowanych badaniach, randomizowanych badaniach kontrolowanych i raportach branżowych dotyczących produktywności wytwarzania oprogramowania wspieranego przez AI oraz szacowania pracochłonności oprogramowania:
- Badania produktywności AI (RCT i eksperymenty terenowe)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: skrócenie czasu realizacji zadania o 55,8%
- 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=4867, +26,08% ukończonych zadań
- 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, skrócenie czasu pracy nad zadaniem o ~21%
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: RCT, n=16, 246 zadań; AI wydłużyła czas realizacji o 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: badanie DiD 807 repozytoriów GitHub; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Replikacja: +13% (wynik nieistotny statystycznie)
- Raporty branżowe o agentowej AI
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× przy migracjach ETL, 14× przy migracjach Javy, 20× przy poprawkach bezpieczeństwa
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× mniej roboczogodzin inżynierów, 20× oszczędności kosztów przy refaktoryzacji wielu milionów wierszy kodu
- BIS / Ant Group (2024). Eksperyment terenowy; +55% wytwarzanego kodu, głównie wśród młodszych pracowników
- Szacowanie pracochłonności oprogramowania: podstawy i dokładność
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: oryginalny model COCOMO
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: kalibracja na 161 projektach
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II, SEER-SEM, SLIM, TruePlanning na 51 projektach; MMRE od 50 do 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 Kalibracja okienkowa na 341 + 93 projektach
- 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: model Putnam/SLIM
⚡ RIADVICE.com dostarcza zaufaną wiedzę inżynierską, kompetencje chmurowe i oprogramowanie klasy enterprise: w terminie, w budżecie i z zachowaniem jakości.
