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

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

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

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

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

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

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

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

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

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

Как же так?

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

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

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

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

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

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

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

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

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

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

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

Метрики, которые раскрывают правду: 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 году, показали, что 90  разработчиков чувствуют себя более удовлетворенными, а число pull request на одного разработчика увеличилось на 8.7% после внедрения ИИ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор статьи @DariaEmacs

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