Когда компания Okta предоставила инженерам доступ к GitHub Copilot во второй половине 2024 года, ожидания были высокими. Отраслевые тренды обещали мгновенный рост производительности. Мы выяснили, что инженеры почувствовали разницу: выросла мотивация, улучшились воспринимаемые навыки, а написание шаблонного кода и тестов стало проще. Тем не менее, когда мы измерили организационные результаты, количество ежемесячных пул-реквестов, строк кода и время цикла на одного инженера существенно не изменились.
Почему индивидуальная эффективность не сразу привела к росту пропускной способности организации?
Приведенные ниже результаты основаны на исследовании, недавно опубликованном нами в издании Communications of the ACM, «Beyond the Hype: The Efficiency-Throughput Gap with GitHub Copilot,», в котором мы изучили, что происходит, когда корпоративные инженерные команды массово внедряют инструменты ИИ.
Организационный закон Ома
Пять лет назад мы начали пристально изучать инженерную производительность — область с более чем полувековой историей, которая породила такие фундаментальные идеи, как книга Фредерика Брукса «Мифический человеко-месяц» и закон Конвея. Главное открытие Брукса заключается в том, что нельзя ускорить разработку ПО простым добавлением новых инженеров. Закон Конвея гласит, что архитектура создаваемого организацией программного обеспечения имеет тенденцию повторять структуру коммуникаций в этой организации.
В основе обеих концепций, как и многого из того, что последовало за ними, лежит так называемая проблема параллельно-последовательных вычислений: большая часть работы над ПО зависит от работы других людей, что ограничивает возможности ее параллельного выполнения.
Это понимание привело нас к предложению Организационного закона Ома. В рамках этой концепции производительность инженерной работы ведет себя как электрический ток, будучи пропорциональной индивидуальному потенциалу инженера (мотивации и навыкам) и обратно пропорциональной организационному сопротивлению. Это сопротивление исходит как от непосредственной работы инженера, такой как кодирование, так и от взаимодействия в команде, процессов и инфраструктуры.
Когда во второй половине 2024 года Okta начала внедрять такие инструменты ИИ, как GitHub Copilot, перед нами стоял практический вопрос: какого прироста производительности разработки и бизнес-результатов мы можем ожидать? Внедрение предоставило нам реальные условия для проверки этого вопроса с помощью Организационного закона Ома.
Прирост индивидуальной эффективности и узкие места пропускной способности организации
Мы опросили инженеров до и после получения доступа к Copilot, поинтересовавшись, как они распределяют свое время, насколько мотивированными себя чувствуют и как оценивают свои навыки. Затем мы сопоставили эти ответы с реальными данными об использовании Copilot и объективными инженерными метриками: пул-реквестами, строками кода, временем цикла и активностью ревью.
Индивидуальные результаты оказались положительными. Мотивация выросла. Воспринимаемые навыки улучшились. Инженеры сообщили, что стали тратить меньше времени на написание кода и тестирование, а среднее количество рабочих часов в неделю также сократилось. Респонденты отметили, что Copilot помогает, особенно с шаблонным кодом, тестами и конфигурацией.
Однако с точки зрения инженерных результатов количество ежемесячных пул-реквестов, строк кода и время цикла на одного инженера существенно не изменились. Экономия времени проявилась в написании кода и тестировании, но время, которое инженеры тратили на общение, ожидание решений и зависимостей, процессы и инфраструктуру, осталось прежним, составляя более половины их рабочего времени.
Три стадии влияния ИИ
Чтобы осмыслить этот разрыв между индивидуальной эффективностью и пропускной способностью предприятия, мы рассматриваем влияние ИИ в три этапа:
Этап 1: Прирост эффективности (на индивидуальном уровне)
- Статус: Инструменты вроде стандартных ИИ-ассистентов сокращают время, затрачиваемое на написание шаблонного кода и тестирование. Наши данные за 2024 год относятся к Этапу 1.
- Влияние: Инженеры сообщают о росте мотивации и навыков, но общие результаты организации не меняются.
Этап 2: Прирост производительности (на уровне рабочих процессов)
- Статус: Повышение квалификации инженеров и реорганизация рабочих процессов в соответствии с возможностями, расширенными за счет ИИ.
- Влияние: Заметный рост инженерных результатов.
Этап 3: Организационная оптимизация (на системном уровне)
- Статус: Перестройка организационной структуры для снижения человеческого фактора сопротивления, включая поиск эффективных режимов взаимодействия людей и ИИ.
- Влияние: Более автономные команды с расширенными индивидуальными зонами ответственности, сокращающие издержки на коммуникацию и принятие решений.
От ассистентов кодирования к агентам кодирования
Мы продолжили мониторинг инженерных метрик после завершения исследования, поскольку наши инструменты расширились от ИИ-ассистентов до агентов с внедрением Claude Code в начале 2026 года. Ниже представлен предварительный взгляд на влияние агентских инструментов для написания кода, основанный на непрерывном мониторинге нашего крупнейшего и наиболее активного репозитория. Остальные определения и методология остались прежними.
За примерно 18-месячный период использования ИИ-помощника Copilot количество пул-реквестов, строк кода и время цикла на одного инженера не улучшились по сравнению с базовыми показателями до появления Copilot. Само по себе время не привело к улучшению метрик.
Мы сравнили три месяца до внедрения Claude Code (с ноября 2025 года по январь 2026 года) с тремя месяцами после (с апреля по июнь 2026 года), исключив период активного развертывания в феврале и марте:
- Количество ежемесячных пул-реквестов на одного инженера выросло на 37% среди 295 инженеров, вносивших вклад в обоих периодах
- Среднее время цикла пул-реквеста сократилось на 16%, а самые долго выполняемые пул-реквесты стали закрываться еще быстрее
- Количество строк кода на одного инженера выросло на 90%, причем этот рост был неравномерным: 55% для продакшн-кода и 115% для тестового кода
Эти два сравнения опираются на разные выборки: участников опроса по всем репозиториям в 2024 году и контрибьюторов в наш крупнейший репозиторий в 2026 году. Каждое из них представляет собой сравнение «до и после» для одних и тех же инженеров.
Тем не менее, это показатели созданного кода, а не качества и ценности, которые мы доставили пользователям. Инструменты ИИ могут изменить объем кода, требующийся для достижения определенной ценности, будь то за счет большего количества тестов, написанных к каждому изменению, большего объема доработок или других привычек. Если это так, то пул-реквесты, строки кода и время цикла больше не означают то же самое, что раньше. Сами по себе метрики не могут показать, как именно изменилось поведение инженеров при написании кода или какая доля изменений обусловлена Claude Code. Для получения полной картины требуются дополнительные исследования.
Мы также исключили из этих расчетов пул-реквесты, созданные агентами. По мере внедрения все большего числа агентов кодирования в продакшн, их совместная работа с людьми и влияние на разработку ПО представляют собой интересные направления для будущих исследований.
Преодоление разрыва требует большего, чем просто лучшие инструменты
Мы с оптимизмом смотрим на инструменты ИИ. Преимущества для отдельного инженера, которые мы измерили в 2024 году, были реальными, и инструменты, которыми наши инженеры пользуются сейчас, значительно мощнее тех, что мы изучали. Но разрыв между преимуществами, которые инженеры ощущают индивидуально, и тем, что отражается на результатах организации, не сократился. Более того, он увеличился.
Возможности этих инструментов для отдельного инженера колоссально выросли с момента проведения нашего исследования. Метрики производительности нашей организации изменились далеко не в такой степени. Ликвидация этого разрыва не произойдет сама по себе за счет лучших технологий. Она требует совместного развития инструментов, команды, процессов и инфраструктуры.
Если вы хотите оценить этот показатель в своей компании, мы создали базовую методологию максимально простой, чтобы любая инженерная команда могла применять ее в процессе реального развертывания или мониторинга без ущерба для работы команды, объединив короткий опрос с метриками, которые вы, вероятнее всего, уже собираете. Если вы попробуете внедрить что-то подобное у себя или столкнетесь с похожим пробелом, мы будем рады услышать ваши отзывы.
Читайте полное исследование
Чтобы подробнее ознакомиться с набором данных, статистическим анализом и нашей моделью «Организационного закона Ома», прочитайте нашу научную работу «», опубликованную в журнале Communications of the ACM (октябрь 2026 г.) в цифровой библиотеке ACM.
