Откуда берется цифра «40 %»? Из правильно поставленного, но узкого эксперимента. Контролируемое исследование Microsoft Research и MIT Sloan зафиксировало ускорение разработчиков с GitHub Copilot на 55,8 % — но на изолированной задаче: написать HTTP-сервер на JavaScript с нуля. Условия лабораторные, задача хорошо специфицирована, код новый. McKinsey в 2024 году оценивает потенциал ускорения для задач генерации кода и документирования в 35-50 % — тоже корректные данные, но с оговоркой: «потенциал», «при правильном применении», «для определенного класса задач». Когда эти цифры попадают в презентации для менеджмента, оговорки теряются. Остается «ИИ ускоряет разработку на 40-55 %». И руководитель искренне в это верит.
Директор по развитию ИИ ПАО «Группа Астра» Станислав Ежов
Источник: ПАО «Группа Астра»
Дальше начинается реальность. Независимая лаборатория METR в 2025 году провела рандомизированный контролируемый эксперимент не на изолированной задаче, а на реальных задачах из живых проектов с открытым кодом: кодовая база от миллиона строк, не менее 22 тыс. звезд в репозитории. Опытные разработчики, работавшие с этим кодом в среднем пять лет, получили доступ к самым мощным доступным инструментам. Результат: при использовании инструментов задачи выполнялись на 19 % медленнее, чем без них. При этом до начала эксперимента разработчики прогнозировали ускорение на 24 %, а после завершения субъективно оценивали свою работу как более быструю на 20 %. Разрыв между ощущением и фактическим замером составил почти 40 процентных пунктов.
Это не значит, что ИИ не работает. Это значит, что он работает иначе, чем принято думать, и его эффект сильно зависит от типа задачи. На новом, хорошо описанном коде ускорение реально. На знакомом унаследованном коде, на задачах с высокой архитектурной неопределенностью, на работе, где понять задачу сложнее, чем ее выполнить — картина другая. В большинстве корпоративных команд таких задач большинство.
Ошибка руководителя не в том, что он верит в ИИ. Ошибка в том, что он считает средний эффект по всей команде и закладывает его в P&L. Средний эффект — это не ваш эффект. Это взвешенная смесь из задач, которые ИИ ускоряет в полтора раза, задач, где эффект нулевой, и задач, где он создает дополнительную нагрузку на проверку и переделки. Когда их усредняют, получается красивое число. Когда бизнес его закладывает в план, получается кассовый разрыв.
Параллельно с вопросом производительности есть вопрос, который в корпоративной среде задают реже, чем следует: что происходит с качеством кода? GitClear в 2025 году проанализировал 211 млн строк кода и зафиксировал рост дублирования в восемь раз, а доля кода, который пишется и сразу переписывается, выросла с 3,1 % до 5,7 %. Это не просто технический долг: это прямые операционные затраты на поддержку, рост числа дефектов в промышленной эксплуатации и более долгое погружение новых сотрудников в проект. В пересчете на крупную команду это не экономия фонда оплаты труда — это скрытые издержки, которые проявятся через 12-18 месяцев.
Есть еще один риск, о котором не принято говорить на уровне директора по ИТ: безопасность цепочки поставок кода. Исследование USENIX Security 2025 охватило 576 тыс. образцов кода от 16 языковых моделей. Вывод: 19,7 % зависимостей, которые рекомендуют инструменты на основе ИИ, не существуют. Несуществующие пакеты — это не просто ошибка сборки. Это вектор атаки: злоумышленник регистрирует пакет с именем, которое модель предсказуемо генерирует, и ждет, пока разработчик его установит. Для организаций, работающих с объектами критической информационной инфраструктуры или обрабатывающих персональные данные, это уже не теоретический риск, а реальный сценарий компрометации.
Я говорю об этом не для того, чтобы призвать отказаться от ИИ в разработке — ровно наоборот. Компании, которые внедряют ИИ правильно, получают реальный измеримый эффект. Те, кто внедряет «средний процент», получают пилоты, которые не выходят в промышленную эксплуатацию, технический долг и проблемы с безопасностью. Разница — в методологии измерения и в архитектуре самого внедрения.
Правильный подход начинается с сегментации задач. Не «ИИ в разработке», а «ИИ на задачах генерации шаблонного кода», «ИИ при работе с документацией», «ИИ для понимания унаследованного кода». У каждого сценария — свои исходные показатели и своя встречная метрика качества: частота переделок, число дефектов, доля кода, который сразу переписывается. Ускорение засчитывается только если качество не деградирует. Именно на этом построены методологические каркасы SPACE и DevEx — многомерные модели продуктивности, специально созданные для того, чтобы метрики скорости не вводили в заблуждение.
Следующий шаг — пилот с измеримыми условиями. Не «дадим инструмент всей команде и посмотрим», а контролируемый эксперимент на конкретном типе задач с фиксированной точкой отсчета и горизонтом не менее 8-12 недель: первые недели дают эффект новизны, а не производительности. И только после подтверждения результата — масштабирование с архитектурой, которая обеспечивает безопасность, управляемость и полный аудит: изолированный контур, журналирование каждого запроса, контроль исходящих соединений.
В корпоративной среде — особенно для организаций с чувствительными данными и регуляторными требованиями — это не опция. По данным отраслевых опросов 2025 года, более 60 % инженеров в закрытых контурах уже используют внешние инструменты через личные учетные записи. Это означает: код, схемы данных и архитектурные решения уходят за периметр без журналов, без аудита, без согласования службы безопасности. Запрещать в этой ситуации бессмысленно — инструменты уже внутри. Задача руководителя — легализовать их в управляемом контуре прежде, чем это станет инцидентом.
Прекратите считать средний эффект ИИ по команде. Это число не управляемо и не дает оснований для решений. Считайте эффект по сценариям — с исходными показателями, с контролем качества, с явными условиями достижения результата. Стройте внедрение как продукт: с архитектурой безопасности, метриками эксплуатации и разделением контуров разработки и боевого. Считайте полную стоимость владения, включая скрытые издержки на технический долг, переделки и потенциальные инциденты. Тогда ИИ в разработке начнет давать то, ради чего его внедряют: измеримый эффект в P&L, а не красивые цифры в презентации.
Автор: Станислав Ежов, директор по развитию ИИ, ПАО «Группа Астра»
