ИИ в разработке дает в разы больше кода, но не в разы больше задач

ИИ в разработке дает в разы больше коммитов, но завершенных задач – на десятки процентов больше, а релизов еще меньше. Узким местом стали ревью, тесты, согласования и публикация.

Главное

• Наш замер. На выборке из 11 разработчиков AppCraft коммитов в месяц стало в 4,1 раза больше, принятых изменений (merge request) – в 5,9 раза. Закрытых задач на 100 часов работы стало на 10% больше по клиентским проектам и на 34% вместе с внутренними. Данные из Git и трекера задач, внутренний отчет от 03.11.2026.
• Прирост тает по дороге к пользователю. У более чем 500 000 разработчиков GitHub автономные агенты дали +240% коммитов, +80% проектов и +30% релизов (NBER).
• Код – малая часть работы. На написание кода уходит 16% рабочего времени разработчика (Atlassian). Если ускоряемая часть занимает 20% работы, даже ее мгновенное выполнение ускорит систему максимум в 1,25 раза (Atlassian).
• Проверка стала горлом. В командах с высоким использованием AI время ревью pull request выросло на 91% (Faros AI).
• Рекомендация. Требуйте от подрядчика даты по каждой задаче от постановки до выпуска, а не число коммитов. На своей стороне назначьте одного человека для решений, договоритесь о сроках ответа и запускайте юристов и дизайн параллельно с разработкой.

Содержание

1. Наш замер – коммитов в 4,1 раза больше, закрытых задач на 10-34%
2. Что измеряли другие: чем ближе к пользователю, тем меньше прирост
3. Где ИИ в разработке теряет прирост: закон Амдала
4. Где стоит проект: проверка у подрядчика, решения у заказчика, сроки у платформ
5. Что AI-подход меняет в смете
6. ИИ для тестирования и ревью – туда уходит освободившееся время
7. Что сделать заказчику
8. Частые вопросы

Наш замер – коммитов в 4,1 раза больше, закрытых задач на 10-34%

Цифры – из моего итогового отчета за шесть месяцев системного перехода AppCraft на AI-агентов, он вышел внутри компании 03.11.2026. Для замера мы взяли контрольную выборку из 11 разработчиков, которые работают и на клиентских, и на внутренних проектах, и сравнили их показатели до и после перехода. Коммиты и принятые изменения взяты из статистики Git, закрытые задачи – из трекера с августа 2026 года. У всех 11 разработчиков агенты стали основным способом работы, доля кода, который пишет AI, – около 96%.

Это три разные метрики. Коммит – запись очередной правки в репозитории, агент делает их десятками в день. Merge request, в других командах pull request, – законченное изменение, которое прошло ревью и влито в основную ветку. Закрытая задача – единица работы в трекере, мы считаем ее в пересчете на 100 часов.

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

Замер AppCraft, 2026: коммиты и merge request – по статистике Git, закрытые задачи на 100 часов работы – по трекеру с августа 2026. Метрики считаются по разным периодам и не образуют одну воронку.

По клиентским проектам прирост задач меньше, и это ожидаемо: в них больше этапов, которые от разработчика не зависят, – согласования, приемка, ответы заказчика. Узким местом стали постановка задач, ревью и тестирование, а не написание кода.

Что измеряли другие: чем ближе к пользователю, тем меньше прирост

Исследования 2025-2026 годов в таблице сгруппированы по тому, что именно считали: от активности в коде до времени выхода на рынок.

Что измерено	Кто мерил	Выборка	Результат	Ограничение
Активность	NBER	более 500 000 разработчиков GitHub	коммиты +240% (NBER)	наблюдательные данные, не эксперимент
Активность	Мандат «2x» в одной компании	802 разработчика, 196 212 PR, 364 репозитория, 01.2024-04.2026	производительность на разработчика – 2,09x к уровню до мандата (arXiv)	одна компания, метрику выбирала она сама
Активность и задачи	Faros AI, 2025	более 10 000 разработчиков, 1 255 команд	разработчики с AI закрывают на 21% больше задач и вливают на 98% больше PR (Faros AI)	средние по пользователям AI, причинность не доказана
Задачи и путь до слияния	Jellyfish, рабочий документ Fiona Chen и James Stratton	718 фирм, более 725 000 работников, 01.2021-03.2026	кода и PR больше, решенные задачи и эпики в Jira статистически значимо не выросли; путь PR до слияния +3,45 дня, или +49% к 7,03 дня (Reasoncore)	пересказ рабочего документа, первоисточник в сети не найден
Ревью	Faros AI, 2025	команды с высоким использованием AI	время ревью PR +91% (Faros AI)	только эта группа команд
Ревью	Faros AI, 2026	22 000 разработчиков, более 4 000 команд, два года	медианное время в ревью PR +441,5% (Faros AI)	сравнение периодов минимального и максимального использования AI внутри организаций
Время на задачу	METR	16 опытных open-source разработчиков, 246 задач, 2025	с AI задачи заняли на 19% больше времени (METR)	маленькая выборка, инструменты начала 2025 года
Сквозной эффект	DORA, 2025	опрос разработчиков	90% используют AI ежедневно, большинство организаций не видят заметного сквозного улучшения (Scrum.org)	самооценка респондентов
Проекты и релизы	NBER	более 500 000 разработчиков GitHub	проекты +80%, релизы +30% (NBER)	число релизов, а не длительность одного
Время выхода на рынок	McKinsey	около 300 публичных компаний	лидеры внедрения AI улучшили time to market на 16-30% (McKinsey)	только лидеры внедрения
Сроки релизов	Дмитрий Пшиченко, РАНХиГС	экспертная оценка	разработчик экономит 20-40% на типовых задачах, релизы ускорились максимум на 5-10%, иногда не изменились (Ведомости)	оценка эксперта, не замер
Распространение агентов	Т1	190 программистов, 21-30.09.2026	25% уже используют агентные системы или оркестрацию нескольких AI (CNews)	опрос через Telegram-каналы

У METR есть и второй результат: участники оценили, что AI ускорил их на 20%, хотя по замеру работали на 19% медленнее (Simon Willison о METR). Поэтому опрос «насколько AI вам помогает» не заменяет даты в трекере.

Еще одна ловушка – слово «релизы»: у NBER это число выпусков, а не срок одного релиза. Ближе к календарю оценки McKinsey и Пшиченко – единицы и десятки процентов.

Где ИИ в разработке теряет прирост: закон Амдала

Прирост теряется на этапах, где код не пишут. По опросу Atlassian, в котором участвовали 3 500 разработчиков и менеджеров из шести стран, на написание кода уходит 16% рабочего времени разработчика. Половина разработчиков теряет 10 и более часов в неделю, в основном из-за того, как устроена работа в организации (Atlassian). Эти часы AI не возвращает.

Механику описывает закон Амдала. Atlassian посчитала пример, где индивидуальная работа занимает 20% цикла. Ускорьте ее вдвое – система ускорится в 1,11 раза. В десять раз – в 1,22. Сделайте мгновенной – в 1,25, и это потолок.

На заводах это знают давно. Теория ограничений говорит, что поток идет со скоростью самого узкого участка, а ускорение любого другого участка только копит незавершенку перед ним. В разработке это очередь изменений на ревью.

Калькулятор ниже ускоряет только написание кода, остальные этапы остаются как есть.

Наш расчет по закону Амдала, все три значения условные: релиз за 12 недель, на код уходит 30% срока, AI пишет код вдвое быстрее. Срок станет 10,2 недели, то есть сократится на 1,8 недели, или на 15%. Даже бесконечно быстрый код не опустит его ниже 8,4 недели. Модель не учитывает параллельные этапы и растущую очередь на ревью, так что это оптимистичная оценка, а не прогноз вашего релиза.

Долю кода возьмите из последнего релиза: по датам в трекере посчитайте, сколько недель шла разработка, а сколько задачи ждали ревью, тестов, ответов и публикации. Исследований о доле кода именно в календарном сроке проекта мы не нашли.

Где стоит проект: проверка у подрядчика, решения у заказчика, сроки у платформ

Время после написания кода теряется в трех местах: на ревью и тестировании у подрядчика, на решениях, приемке и юристах у заказчика, на проверке у платформ.

Самый наглядный пример из нашей практики – вход через Госуслуги. Кнопку «Войти через Госуслуги» с получением профиля на тестовой среде мы собрали за 8-10 часов работы в ноябре 2025 года. Через 10 месяцев главным вопросом оставался не код, а заявки в Минцифры, работа юристов клиента и выбор сертифицированного крипторешения по требованиям ФСБ. Подробно – в статье про наш проект с входом через Госуслуги. Если AI сократит 8-10 часов кода до одного, срок такой интеграции почти не изменится.

Схема ниже показывает путь задачи до пользователя: кто владелец каждого этапа и насколько, по нашей оценке, AI помогает на нем сегодня. Оценки качественные, часть этапов может идти параллельно.

У подрядчика узкое место сместилось в проверку: агент пишет больше, чем человек успевает прочитать. В исследовании мандата «2x» нагрузка на одного проверяющего удвоилась, а автоматическое ревью за несколько месяцев обогнало человеческое по покрытию.

У заказчика свои этапы: согласование дизайна и требований, ответы на вопросы, приемка на живых людях, юристы и безопасность. В августе 2026 года технический анализ большой задачи подготовил агент, а «человеческий» отчет для заказчика – что переделать и чего требует бизнес – написали мы. Реализация началась после согласования: AI ускорил подготовку решения, но принимал его человек.

У платформ свои сроки. Apple ставит цель проверять не менее 50% заявок менее чем за 24 часа и 90% – менее чем за 48 часов. Это цель, а не гарантия. Личные аккаунты разработчиков Google Play, созданные после 13 ноября 2023 года, перед заявкой на рабочую публикацию должны провести закрытое тестирование минимум с 12 тестировщиками, непрерывно подключенными не менее 14 дней. В нашей практике бывают и отказы платформы с повторной подачей.

Что AI-подход меняет в смете

С 04.08.2026 в смете AppCraft стабилизация, то есть исправления после разработки, закладывается как 10% от объема разработки вместо 20%, а аналитика – как 5% всех часов вместо 10%. Стабилизацию мы уменьшили, потому что с AI-подходом ошибок должно стать меньше, а аналитику команда делает через AI. Коэффициенты сложности +7% и +14% мы убрали и считаем по базовой ставке. С июля 2026 года пресейл-оценку готовит внутренний инструмент на AI, и она занимает часы, а не дни.

Модель оплаты определяет, где заказчик увидит изменения. При fix price новые доли видны в смете сразу, а риск ошибки в оценке несет подрядчик. Общую скидку из меньших процентов отдельных статей не выведешь: итог зависит от всей сметы. При time & material сверяйте оплаченные часы с принятым объемом: сколько задач прошли приемку и сколько часов ушло на доработки. Как складывается цена в целом, мы разбирали в статье о том, сколько стоит разработка приложения.

Сэкономленные часы не превращаются в деньги сами. Они уходят в проверки, в новые функции или растворяются в ожидании ответов. Деньгами они становятся, когда релиз выходит раньше или в те же часы помещается больше принятой работы. Поэтому влияние AI на выручку нелинейное и часто небольшое.

Это верно не только для разработки. Юрист с AI готовит договор за час, но сделка ждет подписи контрагента. Маркетолог делает в пять раз больше креативов, но их согласует тот же один директор. Выручку двигает самое узкое место всего процесса, а не самое быстрое. Прямых данных о влиянии AI на выручку я в исследованиях не нашел, так что это моя позиция, а не результат замера.

Отказываться от AI из-за этого нельзя. Кто не ускорил свой этап, проигрывает по цене и срокам тем, кто ускорил, а узкое место потом все равно придется расшивать.

ИИ для тестирования и ревью – туда уходит освободившееся время

Время, которое освободили агенты, мы отдаем прежде всего тестированию и ревью, иначе быстрый код превращается в очередь на проверку. По итогам отчета достраиваем контуры автоматического тестирования, чтобы каждое изменение от агента проходило больше проверок до приемки.

Разработчики работают через Claude Code и Codex CLI, у студии свой маркетплейс плагинов для агентов. Тестировщики тоже подключены к Claude Code. В QA мы обкатываем агентное тестирование мобильных приложений на удаленной виртуальной машине. На каждом проекте три контура: разработка, тестирование, демо или продакшн. Срочные исправления идут сразу, все остальное – через тестирование.

Отдельная компетенция – постановка задач для агентов. Возвраты на доработку – нормальная часть процесса, но от качества постановки зависит, сколько раз задачу вернут. Сюда мы тоже переносим усилия.

Похоже поступают и другие: в опросе BairesDev 78% из 41 технического директора увеличили расходы на ревью кода, QA и проверку работы, которую сгенерировал AI (BairesDev). В данных Faros 2026 года число завершенных эпиков на разработчика выросло на 66,2% (Faros AI). Причину этот рост не называет. Моя гипотеза: прирост доходит до задач там, где перестроили проверку. Если вы строите такие проверки в своей команде, посмотрите, как мы подходим к внедрению AI в процессы разработки.

Что сделать заказчику

Свою половину пути заказчик может ускорить еще до начала следующего этапа.

Шаг	Кто отвечает	Что получится
Назначить одного человека, который принимает решения по проекту	собственник или гендиректор	имя этого человека в договоре или уставе проекта
Записать срок ответа на вопросы подрядчика и на согласования	директор по продукту	порядок ответов, по которому видно, где задача ждет
Запустить юристов, безопасность и дизайн параллельно с разработкой	директор по продукту и юрист	требования к данным и договорам известны до готового кода
Завести аккаунты в сторах заранее и составить календарь проверок	заказчик вместе с подрядчиком	для личных аккаунтов Google Play, созданных после 13.11.2023, 14 дней закрытого теста стоят в плане (Google)
Мерить путь задачи по датам	директор по ИТ, отчет готовит подрядчик	видно, на каком этапе стоит каждая задача

Для последнего шага попросите подрядчика фиксировать по каждой задаче шесть дат:

• задача готова к работе;
• разработка начата;
• изменение передано на ревью;
• тестирование завершено;
• приемка завершена;
• выпуск состоялся.

Рядом с каждым ожиданием – причина и ответственный. Через месяц такой таблицы видно, где стоит ваш проект, лучше любого калькулятора.

Пять вопросов подрядчику, который обещает «в два раза быстрее с AI»:

1. Какую метрику вы ускорили: коммиты, принятые изменения, закрытые задачи или срок от постановки до выпуска? Покажите ее до и после на сопоставимых задачах за одинаковые периоды.
2. Как вы считаете доработки после приемки? Задача, которую вернули, остается закрытой?
3. Какие автоматические проверки проходит код от агента до ручного тестирования и кто делает ревью?
4. Какие статьи сметы изменились из-за AI и как сравнить итог при одинаковом объеме и требованиях к приемке?
5. Есть ли на проекте отдельные контуры разработки, тестирования и продакшна, и кто ставит задачи агентам?

Код теперь пишется быстрее, чем на него успевают ответить. Ускорять пора ответы.

Частые вопросы

Источники

1. nber.org — NBER
2. atlassian.com — Atlassian
3. atlassian.com — Atlassian
4. faros.ai — Faros AI
5. arxiv.org — arXiv
6. 243608892.fs1.hubspotusercontent-na2.net — Faros AI
7. reasoncore.dev — Reasoncore
8. faros.ai — Faros AI
9. metr.org — METR
10. scrum.org — Scrum.org
11. mckinsey.com — McKinsey
12. vedomosti.ru — Ведомости
13. cnews.ru — CNews
14. simonwillison.net — Simon Willison о METR
15. atlassian.com — Atlassian
16. alphaxiv.org — обогнало
17. developer.apple.com — цель
18. support.google.com — должны
19. bairesdev.com — BairesDev
20. faros.ai — Faros AI
21. comnews.ru — ComNews