Přejít na obsah
Všechny články

Ze 7 let na 7 dní díky agentní AI

autor: Ghazi Triki · 5 min čtení

Ze sedmi let na sedm dní
V tomto článku

Pokud jste někdy hleděli do tabulky COCOMO II a sledovali, jak předpovídá 33 kalendářních měsíců pro projekt, který váš tým dodal ve dvou sprintech, problém už znáte: každý model odhadu, který se dnes v praxi používá, byl kalibrován ve světě, kde vývojáři píšou každý řádek ručně, přepínání kontextu něco stojí a kalendář se zastaví v 17 hodin. Ten svět už neexistuje. Nedávno jsme od nuly vyvinuli aplikaci o 286 KLOC, 672 souborech a několika subsystémech, s protokolovou vrstvou, datovou vrstvou, vykreslovacím enginem a integrací s platformami, a za 7 dní jsme dosáhli alfa verze připravené k testování. Celá sada modelů (COCOMO Basic/Intermediate/Post-Architecture, Function Points, základní linie SLOC, Putnam/SLIM) vrátila medián předpovědi 30,3 kalendářního měsíce. Medián násobku produktivity: 4 240×. I ta nejkonzervativnější základní linie (25 SLOC na vývojáře a den pro složité systémy) se mýlila 1 433×. Modely nejsou chybné. Jsou nesprávně použité. Níže najdete rozbor model po modelu, empirickou kalibraci na práci téhož autora a to, co literatura randomizovaných kontrolovaných studií (RCT) z let 2024 až 2026 skutečně říká o tom, kde agentní AI zkracuje dobu trvání, a kde ne.

Projekt, který rozbil odhady

V RIADVICE jsme nedávno vyvinuli složitou aplikaci s bohatou funkčností, takovou, která koordinuje několik subsystémů v distribuované architektuře, jako nativní multiplatformní prostředí pro mobilní zařízení i počítače z jediné kódové základny. Novou implementaci si vyžádaly požadavky trhu. Rozsah ukazuje samotný kód:

  • 286 662 SLOC (~286 KLOC) v 672 zdrojových souborech
  • 1 329 399 řádků celkových změn: 862 488 přidaných a 466 911 odebraných
  • 700 commitů za 7 aktivních vývojových dní do první alfa verze připravené k testování
  • Plná internacionalizace do desítek jazykových verzí
  • Několik zcela nesouvisejících subsystémů, tedy zpracování protokolu, správa dat, vykreslování a integrace s platformami, vše postavené od nuly pro cílové prostředí

Nešlo o obal ani o tenký nový vzhled. Šlo o nativní implementaci od základů, vytvořenou tak, aby splnila požadavky trhu, které stávající řešení splnit nedokázala. Ještě před napsáním prvního řádku jsem do projektu zapojil vlastní analytický nástroj, který na rostoucí kódovou základnu spouští celou sadu oborově standardních modelů pro odhad pracnosti softwaru. Cíl byl poctivý: změřit rozdíl mezi tím, co předpovídají klasické modely, a tím, co skutečně přinese vývoj s pomocí AI. Výsledky nejsou chybou zaokrouhlení. Jsou kategoriálním zlomem.

Co modely odhadu předpověděly a co se skutečně stalo

Nástroj spouští všechny hlavní modely odhadu z literatury softwarového inženýrství: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached a Embedded, vyladěné), COCOMO II Post-Architecture (vyladěný), Function Points, základní linii produktivity SLOC a Putnam/SLIM, kalibrované podle typu projektu pomocí publikovaných konstant z původní odborné literatury.

Model odhaduPředpovězená pracnostPředpovězená dobaZrychlení oproti skutečnosti
COCOMO Basic (Organic)913 člověkoměsíců33,3 měsíce2 282×
COCOMO Basic (Semi-Detached)1 696 člověkoměsíců33,7 měsíce4 240×
COCOMO Basic (Embedded)3 200 člověkoměsíců33,1 měsíce8 000×
COCOMO Intermediate (Semi-Det., vyladěný)1 259 člověkoměsíců30,4 měsíce3 148×
COCOMO Intermediate (Embedded, vyladěný)2 376 člověkoměsíců30,1 měsíce5 940×
COCOMO II Post-Architecture (vyladěný)1 703 člověkoměsíců30,3 měsíce4 257×
Function Points (hrubý odhad)17,9 člověkoměsíce7,5 měsíce45×
Základní linie produktivity SLOC (25 SLOC na vývojáře a den)573 člověkoměsíců573,3 měsíce1 433×
Putnam/SLIMvynecháno (doba < 30 dní; T 4/3 exploduje)n/an/a

Medián násobku produktivity napříč všemi modely je 4 240×. I nejkonzervativnější model předpovídá dobu dodání zhruba 1 400krát delší, než jaká skutečně byla. Nejoptimističtější z nich, Function Points, stále předpověděl 7,5 kalendářního měsíce, tedy 45krát déle než skutečných 7 dní. Podle modelů měl tento projekt trvat někde mezi 7 měsíci a 47 lety. Alfa verze byla připravena k testování za 7 dní.

Modely se neshodnou ani mezi sebou, a to 50× až 8 000×

Tyto modely se mezi sebou neshodují. Na téže kódové základně se předpovědi pohybují od 17,9 do 3 200 člověkoměsíců, což je 178násobný rozptyl. Srovnávací studie SEAA 2013, která hodnotila COCOMO II, SEER-SEM, SLIM a TruePlanning na 51 skutečných projektech, zjistila MMRE 50 až 100 %. Hodnocení na datové sadě COCOMO NASA z roku 2023 zjistilo MMRE blízko 1,0 a PRED(0,25) = 0,0: ani jeden projekt nebyl odhadnut v rámci 25% pásma chyby. Modely nikdy nebyly navrženy pro projekt vyvíjený s pomocí AI. Velikost rozdílu ale, i se započtením nepřesnosti modelů, ukazuje, že se změnilo něco zásadního.

Co výzkum skutečně říká o agentní AI a produktivitě vývojářů

Číslo 4 240× je extrémní a nechci ho přeceňovat. Zakládání nového projektu od nuly nafukuje objem změn a SLOC je slabým ukazatelem hodnoty. Podívejme se proto na recenzovanou literaturu. Asistenti typu Copilot přinášejí skromné, ale skutečné zisky. Peng et al. (2023) zjistili, že vývojáři s AI asistentem pro párové programování dokončili úlohu o 55,8 % rychleji (95% CI: 21 až 89 %). RCT Microsoftu, Accenture a firmy z Fortune 100 (2025), dosud největší studie s n = 4 867, zjistila nárůst dokončených úloh o 26 %. Interní RCT Googlu (2024) zjistila zkrácení času stráveného úlohou o ~21 %. Terénní experiment BIS a Ant Group (2024) naměřil u juniorních pracovníků nárůst objemu kódu o 55 %. Poctivé shrnutí: 1,26× až 1,56× u vhodných úloh. Skutečné, ale ne převratné. Agentní AI funguje v jiném režimu. Hodnocení Devinu za rok 2025 od společnosti Cognition uvádí výsledky zákazníků 10× u migrací ETL, 14× u migrací verzí Javy a 20× u bezpečnostních oprav. Nubank uvedl 12násobné zvýšení efektivity a 20násobnou úsporu nákladů u refaktoringu několika milionů řádků, jehož pracnost byla dříve odhadována na několik let a tisíc inženýrů. Náš port leží přímo v tomto pásmu: histogram commitů ukazuje husté vlny ve 22:00, 0:00 a 1:00, typický podpis relací řízených agenty. Protichůdné důkazy jsou skutečné. RCT Metr.org z roku 2025 (16 zkušených vývojářů, 246 úloh na vyspělých projektech) zjistila, že AI prodloužila dobu dokončení o 19 %: zkušené vývojáře na známých kódových základnách zpomalila. Studie typu difference-in-differences z roku 2026, která sledovala 807 repozitářů na GitHubu po zavedení AI nástroje (He et al., MSR ’26), zjistila „přechodné“ zrychlení a „trvalý“ nárůst složitosti kódu, který vedl k dlouhodobému zpomalení. Název mluví za vše: Speed at the Cost of Quality. Shoda zní: AI výrazně pomáhá při vývoji nových projektů a strukturovaném vývoji, mírně pomáhá u dokončovacích úloh a na vyspělých kódových základnách může rychlost snížit. Dluh na kvalitě je skutečný.

Proč modely selhávají: tři strukturální posuny

Žádný z nákladových faktorů klasických modelů nemá nastavení pro situaci, kdy „vývojář má autonomního agenta, který nikdy nespí a drží celou kódovou základnu v kontextu“. Křivku doby trvání hroutí tři posuny:

  1. Úzké hrdlo psaní zmizelo.

Modely předpokládají, že značná část pracnosti je mechanická: šablonovitý kód, kostry projektu, opakované refaktoringy, lokalizační zdroje a další strukturovaná data. V tomto portu tvoří velkou část objemu vysoce pravidelný text a propojovací kód, které agent dokáže hromadně generovat nebo transformovat. Samotný ručně psaný kód, tedy kostry, konstruktory a lepidlo mezi platformami, se dnes generuje ve vlnách, ne řádek po řádku.

  1. Náklady na přepínání kontextu se hroutí.

Člověk, který přechází mezi protokolovou vrstvou, datovou vrstvou a vykreslovacím enginem, pokaždé platí daň za načtení kontextu. Agent, který přečetl celý repozitář o 672 souborech, ji zaplatí jednou. Na kódové základně této velikosti se tato asymetrie rychle sčítá.

  1. Kalendář už není úzkým hrdlem.

Modely převádějí člověkoměsíce na kalendářní měsíce pomocí rovnice obsazení týmu, která předpokládá lidský pracovní den. Relace agentů běží přes noc. Histogram commitů ukazuje nepřetržitý výstup od 7:00 do 1:00: 18 aktivních hodin, ne 8.

Empirická kalibrace na práci téhož autora

Parametrické modely se rozcházejí o řády, proto jsem provedl také empirickou kalibraci napříč projekty, která porovnává objem mých vlastních změn kódu na člověkoden před zavedením agentního AI nástroje a po něm, na třech dalších produkčních repozitářích ve stejném ekosystému:

ProjektZměny na vývojáře a den před AIZměny na vývojáře a den s AINásobek
Projekt A (load balancer)6732 0563,1×
Projekt B (služba pro reporty)2392 1278,9×
Projekt C (zpracovatelská služba)1 3229820,7×
Souhrn (průměr / medián)n/an/a4,2× / 3,1×

Stejný autor, stejná oblast, skutečná údržbová práce. Empirický násobek je 3× až 9×, tedy mnohem konzervativnější než 4 240× u nového projektu a v souladu s horní hranicí publikovaného výzkumu agentní AI. Jeden projekt se dokonce zpomalil: přínosy závisejí na typu úlohy a nejsou univerzální.

Co to znamená pro plánování projektů

Pokud softwarové projekty stále odhadujete pomocí nekalibrovaných modelů a základní linie 25 SLOC na den, budete se u práce s pomocí AI mýlit o jeden až tři řády. V RIADVICE postupujeme takto:

  1. Kalibrujte podle vlastní historie. Porovnejte svůj vlastní objem kódu na člověkoden s AI a bez ní. Je to levnější, poctivější a dostanete rozpětí 3× až 9×, které obhájíte v plánu projektu.
  2. Oddělte nové projekty od údržby. Násobek agentní AI je největší u nových projektů a strukturovaného vývoje, nejmenší (někdy i záporný) u údržby vyspělých kódových základen. Nepoužívejte pro obojí jedno číslo.
  3. Počítejte s dluhem na kvalitě. Rychlost díky AI přináší trvalý nárůst složitosti. Naplánujte fázi stabilizace a měřte ji: sledujte cyklomatickou složitost a u každého vydání spouštějte detekci duplicitního kódu.
  4. Odhadujte celou křivku, ne jen její začátek. Desetinásobné zrychlení, které zdvojnásobí hustotu chyb, není desetinásobný zisk. Je to harmonogram posunutý dopředu za cenu delší fáze stabilizace.

Shrnutí

Projekt, který měl podle všech modelů odhadu trvat 7 měsíců až 47 let, dospěl k alfa verzi připravené k testování za 7 dní. Medián násobku 4 240× by se neměl stát ničím plánem projektu. Je to ale jasný signál, že dobu trvání vývoje složitého softwaru znovu stlačuje stejná síla, která stlačuje pracnost. Publikovaný výzkum ukazuje, že AI přináší cokoli od mírného zrychlení 1,26× po prudký nárůst 20×, se skutečným rizikem záporných výnosů na vyspělých kódových základnách a měřitelnou daní na kvalitě. Modely, podle kterých měl tento projekt trvat desítky let, jsou tytéž modely, které dodnes běží v podnikových tabulkách pro odhady. Otázkou není, zda agentní AI mění dobu trvání projektů: na to výzkum už odpověděl. Otázkou je, zda vaše praxe odhadů s těmito důkazy drží krok. Pokud vaše čísla stále pocházejí z modelu z roku 1981 kalibrovaného na COBOLu a assembleru, je čas na novou kalibraci, nebo alespoň na to přestat věřit kalendáři, který vám vypíše.

„Stále existuje značný prostor pro zlepšení, aby bylo možné lépe řešit problémy s předpovědí, se kterými se potýká praxe.“

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Spolehlivé inženýrství a odbornost v cloudu

RIADVICE: váš spolehlivý partner v softwarovém inženýrství

Navrhujeme, vyvíjíme a nasazujeme složité softwarové systémy s inženýrskou disciplínou a nástroji, které umožňují dodávat v éře AI: včas, v rámci rozpočtu a v odpovídající kvalitě.

Více o našich službách →

📚 Zdroje a další literatura

Tento článek vychází z recenzovaného výzkumu, randomizovaných kontrolovaných studií a oborových terénních zpráv o produktivitě vývoje softwaru s pomocí AI a o odhadu pracnosti softwaru:

⚡ RIADVICE.com dodává spolehlivé inženýrství, odbornost v cloudu a softwarová řešení podnikové úrovně: včas, v rámci rozpočtu a v odpovídající kvalitě.

Sdílet tento článek

Související články