ИИ ускоряет работу, но замедляет проект?

Я — разработчик на C++, и да, я использую нейросети: спрашиваю у них про тонкости стандарта, нахожу нужные функции в библиотеках без документации, прошу сгенерировать простую функцию и даже — проверить мой код. Всё это быстро и удобно. Ощущение, будто работаешь на околосветовой скорости. Пришла уверенность, что вот оно, настоящее программирование, состояние потока, ощущение полёта! Но потом я заметила странную вещь: тикеты стали закрываться чаще, а релизы — наоборот, выходили медленнее.

Это как вырваться вперёд в командной гонке: ты едешь впереди, а ветер и рассинхронизация тормозят и путают остальных. В итоге — твой отрыв не помогает, а сбивает темп всей команды.

Меня это обескуражило. Я решила разобраться, почему ощущение продуктивности разработчика так отличается от реальных результатов команды, как связаны ИИ-инструменты с метриками времени и качества, а также почему высокая продуктивность требует чего-то большего, чем быстрого написания кода.

Управляемый эксперимент против реальности

Для начала давайте рассмотрим эксперимент, который провели GitHubNext ^[1] и Microsoft ^[2] с участием 95 профессиональных разработчиков. 

Половина из них получила доступ к Copilot, другая половина программировала без него. Задача была разработать HTTP-сервер на JavaScript как можно быстрее. Среднее время, которое программисты потратили на задачу:

• С Copilot: 1 час 11 минут
  

• Без Copilot: 2 часа 41 минуту

В результате эксперимента ^[3] разработка ускорилась на 55%! А 73% участников сообщили, что, используя Copilot, они чаще входят в состояние потока, когда полностью погружаются в задачу, теряют ощущение времени, испытывают удовольствие от процесса.

В противовес этому масштабный опрос ^[4] более 36 000 специалистов по программному обеспечению показывает: даже при активном использовании ИИ (+25%), рост продуктивности целой команды всего 2.1%. 

Как же так?

Продуктивность — это не то, что кажется

ИИ-инструменты, такие как GitHub Copilot, потрясающе ускоряют «внутренний цикл» разработки. Когда система за вас дописывает код, предлагает готовые решения, кажется, что работа идёт гораздо быстрее.

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

То, что вы быстро написали, нужно:

• Вписать в архитектуру проекта и протестировать

• Обсудить с коллегами на ревью

• Влить в основную ветку без конфликтов

• Деплоить, мониторить, поддерживать

А вот здесь волшебство заканчивается. Получается, что ИИ решает «проблему скорости набора текста», но не помогает (а иногда мешает ^[5]) в более важных фазах: коммуникации, согласовании, тестировании — это всё «внешний» цикл разработки. Именно на этом этапе возникает разрыв между ощущением продуктивности и тем, что показывают метрики.

Вы чувствуете: «я сделал много». А процессы вокруг говорят: «мы продвинулись чуть-чуть» или даже «затормозились».

Как же измерить эту реальную эффективность?

Метрики, которые раскрывают правду: DORA и SPACE

И тогда я узнала про объективные метрики. Сегодня существуют две важнейшие системы метрик в разработке ПО. Это DORA и SPACE.

Кратко напомню, о чем идет речь:

DORA (DevOps Research and Assessment) — это исследовательская группа, созданная для изучения и оценки эффективности DevOps-практик в ИТ-компаниях. Изначально DORA была стартапом, а затем в 2018 году Google Cloud ее купил. Ежегодно DORA проводит масштабные исследования среди десятков тысяч специалистов, собирая данные о главных факторах успеха в разработке и деплое программного обеспечения.

DORA-метрики измеряют скорость, стабильность и восстановление после сбоев:

1. Частота развертывания (Deployment Frequency) — как часто организация выпускает код в продакшен.

2. Время выполнения изменений (Lead Time for Changes) — время от коммита до развертывания в продакшен.

3. Частота отказов изменений (Change Failure Rate) — процент развертываний, вызывающих сбои в продакшене.

4. Время восстановления сервиса (Time to Restore Service) — как быстро сервис восстанавливается после сбоя.

5. Доля деплоев, которые не были запланированы, но потребовалось срочно выпустить новый релиз из-за устранения бага после предыдущего (Rework Rate).

SPACE (Satisfaction, Performance, Activity, Communication & Collaboration, Efficiency & Flow) — это фреймворк, который был разработан в 2021 году группой исследователей из GitHub, Microsoft и Канадского Университета Виктории. Традиционные методы, которые фокусировались только на объеме выпускаемого кода или количестве решенных задач приводили к нездоровой конкуренции и выгоранию, в отличие от SPACE. Он быстро получил признание благодаря целостному подходу.

SPACE-методика измеряет, как быстро и слаженно разработчики в процессе работают и  насколько им комфортно:

1. Довольны ли разработчики своей работой (Satisfaction).

2. Скорость выполнения задач (Performance).

3. Вовлеченность, инициатива (Activity).

4. Как налажены процессы в команде (Communication & Collaboration).

5. насколько гладко идёт работа (Efficiency & Flow).

Коротко SPACE — про ощущения, удобство и локальную активность. DORA — про результат, надежность и зрелость процессов.

Все SPACE-метрики, кроме коммуникации, показывают положительную динамику:

Satisfaction & Activity. Результаты совместного пилотного исследования GitHub и Accenture в 2024 году, показали ^[6], что 90 % разработчиков чувствуют себя более удовлетворенными, а число pull request на одного разработчика увеличилось на 8.7 % после внедрения ИИ.

Performance. 4867 разработчиков ^[7] в Microsoft, Accenture и анонимной компании из топ‑100 крупнейших компаний США по годовой выручке;  получили/не получили Copilot в обычной работе. Итог: +26% завершенных задач, +13,5% коммитов, +38% сборок у тех, кто реально пользовался ИИ. При этом прирост был выше у менее опытных инженеров.

Communication & Collaboration. Обширное исследование ^[8] KPMG / Университет Мельбурна, в 2025 году выявило, что 20 % сотрудников сообщили об ухудшении взаимодействия в команде после начала активного использования ИИ-инструментов. Опрашивали очень большое количество людей: 48 000, но это были не обязательно программисты. По разработчикам таких опросов пока не проводилось. Но есть данные ^[9] о том, что ведущие программисты open‑source проектов на GitHub сокращают свои команды в репозиториях на 79%, после того, как им бесплатно выдают Copilot.

Efficiency & Flow. По данным официального исследовательского отчёта ^[3] GitHub Next (обновлён 21 мая 2024 г.), 87% разработчиков, участвовавших в опросе (а это более 2 000 человек, использующих ИИ-помощника), согласились, что GitHub Copilot снижает когнитивную нагрузку, экономит умственные усилия на типовых, мало творческих задачах.

В отличие от SPACE, исследования DORA за 2024 ^[10] год фиксирует, что когда увеличивается использование ИИ на 25% (например, с 40% до 65%), общая скорость разработки падает на 1,5% (Deployment Frequency + Lead Time for Changes + Time to Restore Service), а также происходит падение общей стабильности на 7,2% (Change Failure Rate + ReworkRate).

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

Разработчики реже обсуждают детали с коллегами, обращаясь к ИИ — и именно это снижает качество коммуникации. Также падают скорость процессов разработки и стабильность ПО, потому что увеличивается объем некачественных изменений, команда физически не успевает провести глубокое исследование каждого крупного ИИ-сгенерированного фрагмента кода. 

Ошибки ^[11] всплывают позже (в сборках, тестах, на продакшене), и приходится «перерабатывать» уже принятый код, чаще перевыпускать релиз со срочными исправлениями.

Получается, что пока нет надежды на быстрый рост производительности?

Положительный пример интеграции ИИ в крупную компанию без падения показателей

Компания ZoomInfo — крупная B2B-платформа, которая помогает отделам продаж быстро находить нужных клиентов. В ней работает ^[12] более 400 разработчиков, распределенных по международным командам. Они подошли к этому сложному процессу по шагам:

Выполнили контролируемую поэтапную интеграцию:

• одну неделю 5 ведущих инженеров тестировали ИИ на реальных задачах, собирали телеметрию (сколько подсказок нейросети было принято, сколько кода написал ИИ и прочее), все участники подтвердили «хорошее или отличное» совпадение сгенерированного кода с код-стандартами;

• две недели 126 разработчиков-добровольцев* (32% компании) используют copilot для генерации кода в продакшене. 33% подсказок от ИИ принято и 20% строк кода были сгенерированы нейросетью;

• оценка результатов эксперимента. В итоге более 400 разработчиков используют Copilot.

Собрали объективные данные: как часто и как долго разработчики взаимодействуют с инструментом, какие типы функций или подсказок от ИИ принимаются, как часто возникают ошибки после ИИ-коммитов и прочее. Эти данные показывают, что реально происходит, и помогают выявить, где ИИ действительно экономит время, а где — создает лишнюю нагрузку. А также аккумулировали субъективные данные: опрашивали разработчиков.

*условия участия: пройти тренинг по безопасности, подписать политику использования ИИ, подтвердить готовность давать подробный отчет.

Почему эта схема работает:

• Постепенное масштабирование — каждая фаза дает данные для следующей, не дает быстро увеличиваться одному этапу (написание кода) в ущерб другому (ревью).

• Чёткие требования к участникам — безопасность и код-стандарты не «проседают» от резкого роста ИИ-кода.

• Смешанные метрики — телеметрия + опросы показывают и неумолимые цифры, и субъективный опыт ^[13].

Так ZoomInfo избежала хаоса при массовом внедрении Copilot. Ускорение личной работы (20% экономии времени) не привело к системным сбоям, потому что каждый этап сопровождался контролем качества, политикой безопасности и постепенным расширением лицензий на использование ИИ.

Но нужно иметь ввиду, что в компании ZoomInfo основной стек программирования включает Java, Python, JavaScript и TypeScript.

Именно эти языки Copilot поддерживает очень хорошо в отличие от того же С++, в котором качество подсказок часто хуже, а архитектурные предложения ошибочны и примитивны.

Все мы видели громкие заголовки ^[14] от технического директора этой компании о том, что ИИ в их бизнесе — это революция, и ошеломляющую цифру в 1.2 миллиарда дохода.

Но я рассмотрела динамику выручки за несколько лет. Темпы роста упали с «космических» 40-60% до слабых 13% после внедрения ИИ, а затем показали падение на 2%. Но это связывают с макро-циклами, компания целенаправленно перестала гнаться за каждой маленькой сделкой, а Copilot — это долгосрочная ставка. Эффект от его внедрения мы увидим в ближайшие годы.

Заключение: скорость — не всё, если она не приводит к результату

ИИ-инструменты действительно меняют подход к разработке: ускоряют, подсказывают, автоматизируют. Но настоящая производительность — это не просто «писать быстрее», а поставлять качественные решения быстрее, стабильнее.

Как говорит Джин Ким, ключевой идеолог и популяризатор DevOps, автор бестселлеров и признанный эксперт в области IT-операций, в книге «The Phoenix Project»: «Любые улучшения, сделанные где-либо, кроме узкого места, являются иллюзией».

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

Но зато теперь я не пребываю в иллюзии, что скорость развития проекта вырастет соразмерно моей.

Автор статьи @DariaEmacs ^[15]

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на заказ любого VDS ^[16] (кроме тарифа Прогрев) — HABRFIRSTVDS.