От 7 лет к 7 дням с агентным ИИ

Если вы когда-нибудь смотрели на таблицу COCOMO II и видели, как она предсказывает 33 календарных месяца для проекта, который ваша команда выпустила за два спринта, вы уже знаете проблему: каждая модель оценки, применяемая сегодня, была откалибрована для мира, в котором разработчики набирают каждую строку вручную, переключение контекста обходится дорого, а рабочий день заканчивается в 17:00. Этого мира больше нет. Недавно мы с нуля разработали приложение объёмом 286 KLOC из 672 файлов и нескольких подсистем (протокольный уровень, уровень данных, движок отрисовки, интеграция с платформами) и довели его до альфа-версии, готовой к тестированию, за 7 дней. Полный набор моделей (COCOMO Basic/Intermediate/Post-Architecture, Function Points, базовый уровень SLOC, Putnam/SLIM) дал медианный прогноз 30,3 календарного месяца. Медианный множитель производительности: 4240×. Даже самый консервативный базовый уровень (25 SLOC на человеко-день для сложных систем) ошибся в 1433 раза. Модели не ошибочны. Их применяют не по назначению. Ниже приведены разбор по каждой модели, эмпирическая калибровка на работе того же автора и то, что на самом деле говорят рандомизированные контролируемые исследования 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 месяца	2282×
COCOMO Basic (Semi-Detached)	1696 человеко-месяцев	33,7 месяца	4240×
COCOMO Basic (Embedded)	3200 человеко-месяцев	33,1 месяца	8000×
COCOMO Intermediate (Semi-Det., с настройкой)	1259 человеко-месяцев	30,4 месяца	3148×
COCOMO Intermediate (Embedded, с настройкой)	2376 человеко-месяцев	30,1 месяца	5940×
COCOMO II Post-Architecture (с настройкой)	1703 человеко-месяца	30,3 месяца	4257×
Function Points (грубая оценка)	17,9 человеко-месяца	7,5 месяца	45×
Базовый уровень SLOC (25 SLOC на человеко-день)	573 человеко-месяца	573,3 месяца	1433×
Putnam/SLIM	пропущено (срок < 30 дней; T 4/3 расходится)	н/д	н/д

Медианный множитель производительности по всем моделям составляет 4240×. Даже самая консервативная модель предсказывает срок примерно в 1400 раз больше фактического. Самая оптимистичная, Function Points, всё равно предсказала 7,5 календарного месяца, то есть в 45 раз больше фактических 7 дней. Согласно моделям, проект должен был занять от 7 месяцев до 47 лет. Альфа-версия была готова к тестированию за 7 дней.

Модели расходятся между собой: в 50-8000 раз

Эти модели не согласуются друг с другом. На одной и той же кодовой базе прогнозы колеблются от 17,9 до 3200 человеко-месяцев, то есть разброс в 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%. Эти модели никогда не предназначались для проектов с помощью ИИ. Но величина разрыва, даже с учётом неточности моделей, говорит о том, что изменилось нечто структурное.

Что на самом деле говорят исследования об агентном ИИ и производительности разработчиков

Показатель 4240× экстремален, и я не хочу его преувеличивать. Создание каркаса с нуля раздувает объём изменений, а SLOC служит слабым заменителем ценности. Поэтому обратимся к рецензируемой литературе. Ассистенты в духе Copilot дают скромный, но реальный выигрыш. Peng et al. (2023) обнаружили, что разработчики, работавшие с ИИ-напарником, выполнили задачу на 55,8% быстрее (95% ДИ: от 21 до 89%). Рандомизированное исследование Microsoft/Accenture/Fortune 100 (2025), крупнейшее на сегодня, n=4867, показало рост числа выполненных задач на 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. Консенсус: ИИ очень помогает при разработке с нуля и структурированной разработке, умеренно помогает в задачах автодополнения и может снижать скорость на зрелых кодовых базах. Долг качества реален.

Почему модели ломаются: три структурных сдвига

Ни один из факторов затрат в классических моделях не предусматривает значения «у разработчика есть автономный агент, который никогда не спит и держит в контексте всю кодовую базу». Кривую сроков обрушивают три сдвига:

1. Узкое место набора текста исчезло.

Модели исходят из того, что значительная часть трудоёмкости механическая: шаблонный код, каркасы, повторяющийся рефакторинг, ресурсы локализации и другие структурированные данные. В этой разработке большая часть объёма представляет собой очень регулярный текст и связующий код, которые агент может генерировать или преобразовывать массово. Сам код, прежде писавшийся вручную (каркасы, конструкторы, связка с платформой), теперь генерируется всплесками, а не набирается строка за строкой.

2. Стоимость переключения контекста стремительно падает.

Человек, переключающийся между протокольным уровнем, уровнем данных и движком отрисовки, каждый раз платит налог на загрузку контекста. Агент, прочитавший весь репозиторий из 672 файлов, платит его один раз. На кодовой базе такого размера эта асимметрия быстро накапливается.

3. Календарь больше не является узким местом.

Модели переводят человеко-месяцы в календарные месяцы с помощью уравнения укомплектования, которое предполагает рабочий день человека. Сессии агентов идут всю ночь. Гистограмма коммитов показывает непрерывную работу с 07:00 до 01:00: 18 активных часов, а не 8.

Эмпирическая калибровка на работе того же автора

Параметрические модели расходятся на порядки, поэтому я также провёл эмпирическую калибровку на других проектах, сравнив собственный объём изменений кода на человеко-день до и после внедрения инструмента агентного ИИ на трёх других продуктивных репозиториях той же экосистемы:

Проект	Изменения на человеко-день до ИИ	Изменения на человеко-день с ИИ	Множитель
Проект A (балансировщик нагрузки)	673	2056	3,1×
Проект B (сервис отчётов)	239	2127	8,9×
Проект C (сервис обработки)	1322	982	0,7×
Итог (среднее / медиана)	н/д	н/д	4,2× / 3,1×

Тот же автор, та же предметная область, реальная работа по сопровождению. Эмпирический множитель составляет от 3 до 9×, что гораздо консервативнее показателя 4240× для разработки с нуля и соответствует верхней границе опубликованных исследований агентного ИИ. Один проект даже стал медленнее: выигрыш зависит от задачи и не универсален.

Что это означает для планирования проектов

Если вы всё ещё оцениваете программные проекты некалиброванными моделями и базовым уровнем 25 SLOC в день, на работе с помощью ИИ вы ошибётесь на один-три порядка. Вот что мы делаем в RIADVICE:

1. Калибруйте по собственной истории. Сравните собственный объём кода на человеко-день с ИИ и без него. Это дешевле, честнее и даёт диапазон от 3 до 9×, который можно обосновать в плане проекта.
2. Разделяйте разработку с нуля и сопровождение. Множитель агентного ИИ максимален при разработке с нуля и структурированной разработке и минимален (иногда отрицателен) при сопровождении зрелых кодовых баз. Не применяйте одно число к обоим случаям.
3. Закладывайте бюджет на долг качества. Скорость, которую даёт ИИ, сопровождается устойчивым ростом сложности. Запланируйте этап стабилизации и обеспечьте его измерениями: отслеживайте цикломатическую сложность и проверяйте каждый выпуск на дублирование кода.
4. Оценивайте всю кривую, а не только её начало. Десятикратный прирост скорости, удваивающий плотность дефектов, не является десятикратным приростом: это график, сдвинутый вперёд ценой более длинного хвоста стабилизации.

Итог

Проект, который по всем моделям оценки должен был занять от 7 месяцев до 47 лет, дошёл до альфа-версии, готовой к тестированию, за 7 дней. Медианный множитель 4240× не должен становиться чьим-либо планом проекта. Но это ясный сигнал: сроки разработки сложного программного обеспечения сжимаются под действием той же силы, которая сжимает трудоёмкость. Опубликованные исследования показывают, что ИИ даёт что угодно, от лёгкого ускорения в 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=4867, +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 предлагает надёжную инженерию, экспертизу в облачных технологиях и программные решения корпоративного уровня: в срок, в рамках бюджета и с должным качеством.