У цій статті
Якщо ви колись дивилися на таблицю COCOMO II і бачили, як вона прогнозує 33 календарні місяці для проєкту, який ваша команда випустила за два спринти, ви вже знаєте проблему: кожну модель оцінювання, яку сьогодні використовують на практиці, відкалібровано для світу, де розробники набирають кожен рядок, перемикання контексту має свою ціну, а календар зупиняється о 17:00. Цього світу більше не існує. Нещодавно ми з нуля розробили застосунок обсягом 286 KLOC, що складається з 672 файлів і кількох підсистем (рівень протоколу, рівень даних, рушій рендерингу, інтеграція з платформою), і досягли альфа-версії, готової до тестування, за 7 днів. Повний набір моделей (COCOMO Basic/Intermediate/Post-Architecture, Function Points, базовий рівень SLOC, Putnam/SLIM) дав медіанний прогноз 30,3 календарного місяця. Медіанний множник продуктивності: 4 240×. Навіть найконсервативніший базовий рівень (25 SLOC на день розробника для складних систем) помилився в 1 433×. Моделі не хибні. Їх застосовують не за призначенням. Нижче наведено розбір за кожною моделлю, емпіричне калібрування на роботі того самого автора і те, що насправді кажуть рандомізовані контрольовані дослідження 2024-2026 років про те, де агентний ШІ скорочує тривалість робіт, а де ні.
Проєкт, який зламав оцінки
Нещодавно в RIADVICE ми розробили складний, багатофункціональний застосунок, з тих, що координують кілька підсистем у розподіленій архітектурі, як нативне кросплатформне середовище для мобільних і настільних пристроїв з єдиної кодової бази. Цього вимагав ринок, якому потрібна була нова реалізація. Масштаб видно з кодової бази:
- 286 662 SLOC (~286 KLOC) у 672 файлах вихідного коду
- 1 329 399 рядків загальних змін: 862 488 додавань і 466 911 видалень
- 700 комітів за 7 активних днів розробки до першої альфа-версії, готової до тестування
- Повна інтернаціоналізація десятками мов
- Кілька зовсім не пов’язаних між собою підсистем (обробка протоколів, керування даними, рендеринг та інтеграція з платформою), усі створені з нуля для цільового середовища
Це не була обгортка чи поверхове переоформлення. Це була нативна реалізація з нуля, створена, щоб задовольнити ринкові вимоги, яким не відповідали наявні рішення. Ще до першого рядка коду я підключив до проєкту власний інструмент аналізу, який у міру зростання кодової бази запускає на ній повний набір галузевих стандартних моделей оцінювання трудомісткості розробки програмного забезпечення. Мета була чесною: виміряти розрив між тим, що прогнозують класичні моделі, і тим, що насправді дає розробка за допомогою ШІ. Результати не є похибкою округлення. Це якісний розрив.
Що прогнозували моделі оцінювання і що сталося насправді
Інструмент запускає всі основні моделі оцінювання з літератури з програмної інженерії: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached і Embedded, налаштовані), COCOMO II Post-Architecture (налаштована), Function Points, базовий рівень продуктивності SLOC і Putnam/SLIM. Усі вони відкалібровані відповідно до типу проєкту з використанням опублікованих констант з оригінальних першоджерел.
| Модель оцінювання | Прогнозована трудомісткість | Прогнозований календарний строк | Прискорення порівняно з фактом |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 людино-місяців | 33,3 місяця | 2 282× |
| COCOMO Basic (Semi-Detached) | 1 696 людино-місяців | 33,7 місяця | 4 240× |
| COCOMO Basic (Embedded) | 3 200 людино-місяців | 33,1 місяця | 8 000× |
| COCOMO Intermediate (Semi-Det., налаштована) | 1 259 людино-місяців | 30,4 місяця | 3 148× |
| COCOMO Intermediate (Embedded, налаштована) | 2 376 людино-місяців | 30,1 місяця | 5 940× |
| COCOMO II Post-Architecture (налаштована) | 1 703 людино-місяці | 30,3 місяця | 4 257× |
| Function Points (приблизна оцінка) | 17,9 людино-місяця | 7,5 місяця | 45× |
| Базовий рівень продуктивності SLOC (25 SLOC на день розробника) | 573 людино-місяці | 573,3 місяця | 1 433× |
| Putnam/SLIM | пропущено (тривалість < 30 днів; T 4/3 вибухає) | н/д | н/д |
Медіанний множник продуктивності за всіма моделями становить 4 240×. Навіть найконсервативніша модель прогнозує строк постачання приблизно в 1 400 разів довший, ніж вийшло насправді. Найоптимістичніша, Function Points, усе одно прогнозувала 7,5 календарного місяця, тобто в 45 разів довше за фактичні 7 днів. За моделями цей проєкт мав би тривати від 7 місяців до 47 років. Альфа-версія була готова до тестування за 7 днів.
Моделі не погоджуються одна з одною: розбіжність від 50× до 8 000×
Ці моделі не узгоджуються між собою. На тій самій кодовій базі прогнози коливаються від 17,9 до 3 200 людино-місяців, тобто розкид у 178 разів. Порівняльне дослідження SEAA 2013, що оцінювало COCOMO II, SEER-SEM, SLIM і TruePlanning на 51 реальному проєкті, виявило MMRE від 50 до 100%. Оцінювання 2023 року на наборі даних COCOMO NASA виявило MMRE близько 1.0 і PRED(0.25) = 0.0: жоден проєкт не було оцінено в межах 25% похибки. Ці моделі ніколи не призначалися для проєктів, що виконуються за допомогою ШІ. Але розмір розриву, навіть з урахуванням неточності моделей, свідчить, що змінилося щось структурне.
Що насправді кажуть дослідження про агентний ШІ та продуктивність розробників
Показник 4 240× екстремальний, і я не хочу його перебільшувати. Створення проєкту з нуля роздуває обсяг змін, а SLOC слабко відображає цінність. Тож погляньмо на рецензовану літературу. Асистенти на кшталт Copilot дають помірний, але реальний виграш. Peng et al. (2023) з’ясували, що розробники, які використовували ШІ як напарника з програмування, виконали завдання на 55,8% швидше (95% ДІ: від 21 до 89%). Рандомізоване контрольоване дослідження Microsoft/Accenture/Fortune 100 (2025), найбільше на сьогодні, n=4 867, виявило збільшення кількості виконаних завдань на 26%. Внутрішнє рандомізоване дослідження Google (2024) виявило скорочення часу на завдання приблизно на 21%. Польовий експеримент BIS/Ant Group (2024) зафіксував збільшення обсягу коду на 55% серед молодших співробітників. Чесний підсумок: від 1,26× до 1,56× на відповідних завданнях. Реально, але не революційно. Агентний ШІ працює в іншому режимі. Огляд Devin від Cognition за 2025 рік повідомляв про результати клієнтів: 10× на міграціях ETL, 14× на міграціях версій Java і 20× на виправленнях безпеки. Nubank повідомив про 12-кратне підвищення ефективності і 20-кратну економію витрат на рефакторингу кількох мільйонів рядків коду, який раніше оцінювали як багаторічну роботу тисячі інженерів. Наш проєкт перенесення лежить саме в цьому діапазоні: гістограма комітів показує щільні сплески о 22:00, 00:00 і 01:00, характерну ознаку сесій, які ведуть агенти. Контраргументи також реальні. Рандомізоване дослідження Metr.org 2025 року (16 досвідчених розробників, 246 завдань у зрілих проєктах) виявило, що ШІ збільшив час виконання на 19%: він уповільнив досвідчених розробників на знайомих кодових базах. Дослідження 2026 року за методом «різниця різниць» на 807 репозиторіях GitHub, що впровадили інструменти ШІ (He et al., MSR ’26), виявило «тимчасове» прискорення і «стійке» зростання складності коду, яке в довгостроковій перспективі призвело до уповільнення. Назва говорить сама за себе: Speed at the Cost of Quality. Консенсус: ШІ дуже допомагає в розробці з нуля та структурованій розробці, помірно допомагає з доповненням коду і може шкодити швидкості на зрілих кодових базах. Борг якості реальний.
Чому моделі ламаються: три структурні зрушення
Жоден із чинників вартості в класичних моделях не має налаштування для ситуації «розробник має автономного агента, який ніколи не спить і тримає в контексті всю кодову базу». Три зрушення обвалюють криву тривалості:
- Вузьке місце набору тексту зникло.
Моделі припускають, що значна частка трудомісткості механічна: шаблонний код, каркаси, повторювані рефакторинги, ресурси локалізації та інші структуровані дані. У цьому проєкті перенесення значна частина обсягу це дуже одноманітний текст і зв’язувальний код, який агент може масово генерувати чи перетворювати. Навіть код, що раніше писався вручну (каркаси, конструктори, зв’язки з платформою), тепер генерується сплесками, а не набирається рядок за рядком.
- Ціна перемикання контексту стрімко падає.
Людина, яка перемикається між рівнем протоколу, рівнем даних і рушієм рендерингу, щоразу сплачує податок на завантаження контексту. Агент, який прочитав увесь репозиторій із 672 файлів, сплачує його один раз. На кодовій базі такого розміру ця асиметрія швидко накопичується.
- Календар більше не є вузьким місцем.
Моделі перетворюють людино-місяці на календарні місяці через рівняння укомплектування штату, яке передбачає людський робочий день. Сесії агентів тривають уночі. Гістограма комітів показує стабільну роботу з 07:00 до 01:00: 18 активних годин, а не 8.
Емпіричне калібрування на роботі того самого автора
Параметричні моделі розходяться на порядки, тож я також провів емпіричне міжпроєктне калібрування, порівнявши свій власний обсяг змін коду на людино-день до і після впровадження інструмента агентного ШІ на трьох інших робочих репозиторіях у тій самій екосистемі:
| Проєкт | Зміни на день розробника до ШІ | Зміни на день розробника з ШІ | Множник |
|---|---|---|---|
| Проєкт A (балансувальник навантаження) | 673 | 2 056 | 3,1× |
| Проєкт B (сервіс звітності) | 239 | 2 127 | 8,9× |
| Проєкт C (сервіс обробки) | 1 322 | 982 | 0,7× |
| Загалом (середнє / медіана) | н/д | н/д | 4,2× / 3,1× |
Той самий автор, та сама предметна галузь, реальна робота із супроводу. Емпіричний множник становить від 3 до 9×: це значно консервативніше, ніж показник 4 240× для розробки з нуля, і узгоджується з верхньою межею опублікованих досліджень агентного ШІ. Один проєкт навіть сповільнився: виграш залежить від завдання і не є універсальним.
Що це означає для планування проєктів
Якщо ви досі оцінюєте програмні проєкти за невідкаліброваними моделями та базовим рівнем 25 SLOC на день, на роботі за допомогою ШІ ви помилятиметеся на один-три порядки. Ось що ми робимо в RIADVICE:
- Калібруйте за власною історією. Порівняйте власний обсяг коду на людино-день з ШІ і без нього. Це дешевше, чесніше й дає діапазон від 3 до 9×, який можна обґрунтувати в плані проєкту.
- Відокремлюйте розробку з нуля від супроводу. Множник агентного ШІ найбільший у розробці з нуля та структурованій розробці і найменший (іноді від’ємний) у супроводі зрілих кодових баз. Не застосовуйте одне число до обох.
- Закладайте бюджет на борг якості. Швидкість завдяки ШІ супроводжується стійким зростанням складності. Плануйте фазу стабілізації та вимірюйте її: відстежуйте цикломатичну складність і запускайте виявлення копіювання коду в кожному випуску.
- Оцінюйте всю криву, а не лише її початок. Десятикратне прискорення, яке подвоює щільність дефектів, не є десятикратним виграшем: це графік, зсунутий уперед ціною довшого хвоста стабілізації.
Підсумок
Проєкт, який, за всіма моделями оцінювання, мав тривати від 7 місяців до 47 років, досяг альфа-версії, готової до тестування, за 7 днів. Медіанний множник 4 240× не повинен ставати чиїмось планом проєкту. Але це чіткий сигнал, що тривалість розробки складного програмного забезпечення стискається під дією тієї самої сили, яка стискає трудомісткість. Опубліковані дослідження показують, що ШІ дає від легкого поштовху в 1,26× до стрибка в 20×, з реальним ризиком від’ємної віддачі на зрілих кодових базах і вимірюваним податком на якість. Моделі, які казали нам, що цей проєкт триватиме десятиліттями, це ті самі моделі, що й сьогодні працюють у корпоративних таблицях оцінювання. Питання не в тому, чи змінює агентний ШІ тривалість проєктів: дослідження вже на нього відповіли. Питання в тому, чи встигла ваша практика оцінювання за фактами. Якщо ваші цифри досі походять із моделі 1981 року, відкаліброваної на COBOL і асемблері, час перекалібруватися або принаймні перестати вірити календарю, який вона видає.
«Залишається значний простір для вдосконалення, щоб краще відповідати на виклики прогнозування, з якими стикаються на практиці.»
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Надійна інженерія та хмарна експертиза
RIADVICE: ваш надійний партнер у програмній інженерії
Ми проєктуємо, створюємо та розгортаємо складні програмні системи з тією інженерною дисципліною та інструментами, які дають змогу постачати результат в епоху ШІ: вчасно, в межах бюджету і якісно.
Дізнатися більше про наші послуги →
📚 Джерела та додаткове читання
Ця стаття спирається на рецензовані дослідження, рандомізовані контрольовані дослідження та галузеві звіти про продуктивність розробки програмного забезпечення за допомогою ШІ й оцінювання трудомісткості розробки:
- Дослідження продуктивності з ШІ (рандомізовані контрольовані дослідження та польові експерименти)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: скорочення часу виконання завдання на 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=4 867, +26,08% виконаних завдань
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: рандомізоване дослідження Google, n=96, скорочення часу на завдання приблизно на 21%
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Metr.org: рандомізоване дослідження, n=16, 246 завдань; ШІ збільшив час виконання на 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: дослідження за методом «різниця різниць» на 807 репозиторіях GitHub; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasks Відтворення дало +13% (статистично незначуще)
- Галузеві звіти про агентний ШІ
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work 10× на міграціях ETL, 14× на міграціях Java, 20× на виправленнях безпеки
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin 12× за інженерними годинами, 20× економії витрат на рефакторингу кількох мільйонів рядків
- BIS / Ant Group (2024). Польовий експеримент; +55% обсягу коду, переважно серед молодших співробітників
- Оцінювання трудомісткості розробки: основи та точність
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: оригінальна модель COCOMO
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: відкалібровано на 161 проєкті
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation Models COCOMO II, SEER-SEM, SLIM, TruePlanning на 51 проєкті; MMRE від 50 до 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 Калібрування на основі вікон на 341 + 93 проєктах
- 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: модель Putnam/SLIM
⚡ RIADVICE.com надає надійну інженерію, хмарну експертизу та програмні рішення корпоративного рівня: вчасно, в межах бюджету і якісно.
