Агентство разобрало 4 910 смет: на авторизацию теперь закладывают в 2,2 раза меньше часов

Когда CEO говорят, что ИИ пишет 20%, 30% или даже 90% кода, у заказчика остаётся один вопрос: сколько теперь стоит приложение? Сергей Никоненко, руководитель агентства мобильной и веб-разработки, решил ответить на него в часах и рублях. Он взял внутренние данные: сметы, списания времени в Jira и коммиты GitLab. Проценты сгенерированного кода он в расчёт не брал.

Что показали сметы

В архиве 4 910 смет, но для сравнения подошли немногие: нужны документы с одинаковой структурой. Авторизацию удалось сопоставить в 12 сметах за 2025 год и в 19 за 2026-й. Медиана заложенных часов упала со 124 до 56, то есть в 2,2 раза. Сузился и разброс: центральные 50% оценок были 64–178 часов, стали 24–70.

Цена часа изменилась скромнее. По семи сметам каждого года медианная ставка разработки снизилась с 3 900 до 3 600 ₽, это около 8%. Автор не перемножает две медианы, чтобы получить цену фичи: часы и ставки взяты из разных выборок, а для такого расчёта нужны пары из одних и тех же смет.

На практике это значит, что знакомые задачи в шаблонах смет пора пересматривать. Но минимальные 12 часов на авторизацию в шаблон записывать нельзя: под одним названием эпика в разных продуктах скрываются разные реализации.

Jira и GitLab: где цифры хитрее

С фактом сложнее. Попадание в смету само по себе мало что говорит. Мобильное приложение с админкой уложилось в бюджет на 100% (1 359 из 1 360 часов). Продукт о развитии личности с расчётом на ИИ дошёл до 101% (520 из 515), хотя проект ещё идёт. Но его оценивали уже с учётом агентов: ожидаемую экономию могли вычесть заранее, и 101% не показывают, помог ИИ или нет. Проект с ростом скоупа вышел на 182%, но у него 23 переоценки, а в сравнении стоит исходный бюджет.

Ещё одна проблема учёта: у сервиса экспедиций в Jira нашлось 311 часов, а примерно 120 часов работы в трекер не попали. Автор добавил их оценочно. Без этой поправки экономия выглядела бы красивее, но расчёт был бы хуже.

GitLab нужен, чтобы увидеть участие агентов по трейлеру Co-Authored-By: Claude в сообщении коммита. У сайта косметики 92% из 802 коммитов помечены соавторством ИИ, а делал их один разработчик за 37 рабочих дней. В мобильном приложении картина показательнее: до июня 2026 года пометок нет, осенью они почти в каждом коммите. При этом трейлер говорит лишь о заявленном соавторстве. Сколько строк написал ИИ и сколько часов он сэкономил, по нему не узнать. А если разработчик использовал ИИ, но не поставил пометку, его работа остаётся за кадром. Поэтому проекты без трейлеров нельзя называть разработкой без ИИ.

Итоговые коэффициенты и их границы

Главный результат такой: бюджет делят на фактические часы. У сайта косметики получилось около 2,5× (594 часа бюджета против 240 фактических). Но 594 — это 80% от исходных 742 часов, а 80% готовности назвал владелец проекта, независимой сверки по закрытым задачам нет. У сервиса экспедиций 1 627 часов бюджета против примерно 431 факта дают около 3,8×. В выводе автор осторожно округлил до 3×, это его выбор, а не статистическая граница.

Ограничения он перечисляет сам:

• Проекты не распределяли случайно между работой с агентами и без них.
• ИИ-first кейсов, сравнимых со старыми бюджетами, только два. Оба веб, на Next.js и Nest.js.
• Менеджеры проектов исключены, так что это часы разработки, а не полная себестоимость.
• Календарные сроки поставки не сравнивались.

Есть и контраргумент. В рандомизированном эксперименте METR опытные разработчики с ИИ-инструментами на знакомых open-source задачах работали на 19% медленнее. Автор не утверждает, что опроверг это исследование: у него другой тип сравнения, и почему результаты расходятся, его данные не объясняют.

Что с этим делать

Для команд, которые считают сметы, вывод приземлённый. Первое: пересмотрите нормы часов на типовые задачи вроде авторизации и не тащите старые цифры в новые проекты автоматически. Второе: не обещайте клиенту, что всё подешевеет в разы, потому что цена часа двигается куда медленнее. Третье: заведите нормальный учёт. Если часть работы не попадает в трекер, любой коэффициент ускорения будет приукрашен. Четвёртое: не принимайте долю коммитов с пометкой ИИ за меру продуктивности. Это лишь след в истории репозитория.

Само исследование честное, потому что оно открыто показывает слабые места. Для индустрии оно полезно как пример: как проверять заявления про «ускорение в разы» на собственных данных и не выдавать сравнение со сметами за контролируемый эксперимент.