Все три результата основаны на реальных измерениях, однако сравнивать их напрямую почти бессмысленно, потому что за словом разработка каждый раз скрывалась совершенно разная работа. В одном случае участникам нужно было с нуля написать небольшой сервер, в другом разобраться в проекте объёмом более миллиона строк, а в третьем ИИ стал частью специально построенной системы, где несколько агентов анализировали код, вносили изменения и проверяли друг друга.
Именно поэтому сегодня почти невозможно назвать одну цифру, которая показала бы реальную эффективность ИИ в разработке. Слишком многое зависит от самой задачи, качества проекта и того, что происходит после того, как модель сгенерировала код.
Разработчики были уверены, что ИИ экономит им время
Весной 2025 года исследователи METR пригласили 16 опытных разработчиков и предложили им решить 246 настоящих задач в проектах, над которыми они работали в среднем около пяти лет. Это были обычные исправления ошибок, доработки и рефакторинг, а не специально подготовленные упражнения.
Часть задач участники выполняли самостоятельно, а в остальных могли использовать Cursor с Claude 3.5 и 3.7 Sonnet. Перед началом эксперимента разработчики предполагали, что ИИ сократит время работы примерно на 24%, и даже после завершения продолжали считать, что сэкономили около 20%.
Объективные замеры показали, что с ИИ они, наоборот, работали в среднем на 19% дольше.
Модель быстро предлагала первый вариант, поэтому задача действительно ощущалась проще: не нужно было начинать с пустого экрана, искать синтаксис или вручную писать очевидные фрагменты. Однако затем разработчики тратили время на уточнение запросов, ожидание ответов, чтение предложенного кода и исправление ошибок. Только 44% созданных моделью решений были приняты, а выигрыш на первых этапах полностью исчезал во время проверки.
Самым интересным результатом исследования METR стало не само замедление, а разница между ощущениями участников и фактическими замерами. Даже опытные специалисты не заметили, что стали работать дольше, поскольку быстрые ответы модели создавали постоянное ощущение движения и снижали субъективную сложность задачи.
Переносить эти цифры на современные инструменты, впрочем, уже нельзя. Эксперимент проводился в первой половине 2025 года, когда разработчики в основном использовали ИИ как помощника внутри редактора. За следующий год появились полноценные агенты, способные самостоятельно изучать проект, менять несколько файлов, запускать сборку и исправлять найденные ошибки.
METR продолжила исследование с более современными инструментами, и на этот раз прежние участники выполняли задачи с ИИ ориентировочно на 18% быстрее. Надёжно подтвердить эффект не удалось, поскольку выборка изменилась, а результаты сильно различались. Некоторые разработчики запускали несколько агентов одновременно, поэтому измерять их время прежним способом стало сложно. Другие уже настолько привыкли к ИИ, что не соглашались выполнять половину задач без него даже за деньги.
Получилась довольно редкая ситуация: технология изменилась быстрее, чем исследователи успели придумать устойчивый способ измерения её эффективности.
Почему исследования GitHub показали совсем другой результат
Одна из самых известных цифр GitHub появилась ещё в 2022 году, когда участникам эксперимента предложили написать небольшой HTTP-сервер на JavaScript. Разработчики с Copilot завершили задание примерно на 55% быстрее контрольной группы.
В более позднем исследовании GitHub участвовали 202 разработчика с опытом от пяти лет. Им нужно было создать API для вымышленного сервиса ресторанных отзывов, после чего код проверяли автоматическими тестами и отдавали другим специалистам на слепое ревью. Участники с Copilot чаще проходили все тесты, а их решения получили немного более высокие оценки читаемости, надёжности и поддерживаемости.
Результаты выглядят намного лучше, чем у METR, но противоречие исчезает, если посмотреть на устройство задач.
В экспериментах GitHub участники начинали почти с чистого листа, заранее знали ожидаемый результат и могли проверить его с помощью небольшого набора тестов. Им не требовалось учитывать многолетнюю историю проекта, искать связи между несколькими системами и разбираться, почему очевидное изменение нарушает внутреннее правило, о котором нигде не написано.
В исследовании METR разработчики работали в знакомых им кодовых базах объёмом в среднем более миллиона строк. Они нередко сразу понимали, где искать проблему, тогда как модель ещё нужно было познакомить с устройством проекта. Чтобы получить полезный ответ, специалист сначала переводил собственное понимание системы в текст, показывал связанные файлы и объяснял ограничения, а затем проверял, не упустил ли ИИ то, что для человека давно стало очевидным.
Получалось, что разработчик не просто использовал инструмент, а вводил в курс дела нового исполнителя, который хорошо знает программирование вообще, но ничего не знает о конкретной компании.
Поэтому GitHub и METR измеряли разные виды работы. Когда основная сложность заключается в создании типового решения, ИИ действительно может сильно ускорить разработчика. Если же сначала нужно понять существующую систему и определить, какое изменение не повредит остальным её частям, результат становится гораздо менее предсказуемым.
Современные агенты лучше работают с большими проектами и способны самостоятельно собирать контекст, но фундаментальная разница между этими задачами сохраняется. Чем проще проверить результат, тем больше работы можно передать модели и тем выше потенциальная экономия времени.
Microsoft улучшила результат, не меняя модель
Команда .NET в течение десяти месяцев использовала Copilot Coding Agent в репозитории .NET Runtime, который лежит в основе приложений на C#. Агент получал задачу, самостоятельно изучал код и открывал готовый пул-реквест. За время эксперимента он подготовил 878 таких работ, но в первые месяцы успешно завершались только 38,1%.
Иногда Copilot действительно выбирал неудачное решение, однако многие провалы были связаны не со способностями модели, а с тем, что она не могла нормально работать внутри проекта.
Для разных частей .NET Runtime используются свои команды сборки, зависящие от платформы и типа изменения. Полная сборка даже на мощном компьютере занимает больше двадцати минут, но агент запускал её в ситуациях, когда хватило бы короткой проверки, упирался в ограничение времени и останавливался. Часть зависимостей была недоступна из его среды, а внутренние правила проекта оставались разбросаны по документации или существовали только в головах сотрудников.
Microsoft открыла доступ к необходимым пакетам, описала структуру репозитория и добавила точные инструкции для разных видов работы. Команда зафиксировала команды сборки, особенности кросс-компиляции, требования к документации и ошибки, которые Copilot уже совершал раньше.
После этого доля успешных работ выросла с 38,1 до 69%.
Авторы отчёта .NET отдельно отметили, что результат улучшился не после выхода новой модели, а благодаря подготовке проекта. Copilot не стал почти вдвое умнее, зато перестал тратить время на неправильные действия, получил доступ к нужным инструментам и начал учитывать правила конкретной команды.
Нового сотрудника тоже приходится знакомить с проектом, но обычно этот процесс устроен неформально: коллеги отвечают на вопросы, показывают внутренние инструменты и исправляют первые ошибки. В случае с агентом накопленные объяснения можно сохранить в инструкциях, после чего они будут использоваться при выполнении каждой следующей задачи.
Microsoft фактически автоматизировала не написание кода, а часть адаптации исполнителя к проекту, и именно это дало больший эффект, чем простая замена одной модели другой.
В Google одинаково высокая автоматизация дала разный эффект
Весной 2026 года Сундар Пичаи сообщил, что ИИ создаёт уже 75% нового кода Google. Эта цифра быстро разошлась по СМИ, хотя она ничего не говорит о том, сколько времени компания действительно экономит.
В одном из проектов Google требовалось перевести внутренние идентификаторы с 32 на 64 бита. Изменения затрагивали десятки тысяч участков в тысячах файлов, поэтому ручная миграция могла потребовать несколько инженерных лет.
ИИ помогал находить нужные места и готовить исправления, а в результате создал 80% изменений, которые вошли в итоговый код. Общая продолжительность работы при этом сократилась примерно вдвое.
Разница объясняется тем, что генерация была лишь одним из этапов. Инженерам всё ещё приходилось разбирать исключения, распределять изменения между владельцами разных систем, изучать ошибки сборки и согласовывать выпуск. Модель создавала большую часть кода, но не управляла всей миграцией.
Этот проект Google показал, почему процент машинных изменений плохо подходит для оценки производительности. Он сообщает, откуда появился код, но ничего не говорит о том, сколько человеческой работы осталось вокруг него.
В другом проекте Google переносила крупные производственные модели с TensorFlow на JAX. Если убрать технические названия, компании нужно было переписать сложную систему на другой технологии, полностью сохранив её прежнее поведение.
Заменить несколько команд было недостаточно, поскольку некоторые модели YouTube состоят из сотен связанных компонентов и тысяч строк кода. Ошибка могла не нарушить сборку, но незаметно изменить расчёты и повлиять на итоговые рекомендации.
Первые попытки поручить миграцию одному агенту оказались неудачными: он терял контекст, пропускал зависимости, придумывал несуществующие функции и иногда менял файлы, которые не следовало трогать.
После этого Google разделила процесс между несколькими агентами. Один изучал зависимости и составлял план, другой разбивал его на небольшие этапы и контролировал выполнение, а третий менял код, запускал сборку и исправлял ошибки. Для каждой команды использовались отдельные инструкции и примеры успешных миграций, поэтому агент, работавший с моделями YouTube, получал знания именно об инфраструктуре YouTube.
Решающим изменением стала возможность автоматически проверить результат. Google не ограничилась тем, что новый код собирается и проходит обычные тесты. Система математически сравнивала старую и новую версии модели, находила максимальное расхождение между их результатами и только после этого передавала работу инженеру.
На реальных моделях YouTube такой процесс дал ускорение от 6,4 до 8 раз, а работа, которая раньше занимала несколько инженерных месяцев, стала укладываться в несколько недель.
В первой миграции ИИ в основном создавал изменения, поэтому высокая доля машинного кода сократила общий срок примерно вдвое. Во второй системе агенты получили карту зависимостей, внутренние правила, разделение ролей и строгую проверку, благодаря чему похожая технология ускорила проект почти в восемь раз.
Ускорение на одном этапе может замедлить весь процесс
Разработку часто представляют как последовательное написание программы: сотрудник получает задачу, открывает редактор и начинает создавать решение. При таком взгляде всё кажется очевидным, поскольку ИИ пишет быстрее человека и должен во столько же раз ускорить весь процесс.
На практике до первой строки кода нужно понять задачу, найти нужное место и выбрать подходящее решение, а после последней предстоит собрать проект, запустить тесты, проверить безопасность, провести ревью и выпустить изменение. Если ИИ ускоряет только середину этой цепочки, нагрузка просто переезжает на следующие этапы.
Разработчик может подготовить за день не два изменения, а шесть, но теперь их должны прочитать другие сотрудники. Если пул-реквесты стали больше, проверка занимает дольше, а если тесты не покрывают важные сценарии, сэкономленное на написании время возвращается в виде ручного контроля.
Такой эффект обнаружила DORA, исследовательская программа Google Cloud, которая много лет изучает работу технологических команд. По данным за 2024 год, увеличение использования ИИ на 25% было связано со снижением пропускной способности разработки на 1,5% и стабильности выпуска на 7,2%. Одной из причин стали более крупные изменения, которые ИИ позволял создавать быстрее, хотя проверять и безопасно выпускать такой объём команды ещё не научились.
В 2025 году связь с количеством выпущенных изменений стала положительной, однако одновременно сохранился рост нестабильности. В последнем отчёте DORA ИИ описывается как усилитель существующей организации: в компании с хорошей внутренней платформой, автоматическими тестами и понятными процессами он увеличивает скорость, а при плохой документации и хрупкой инфраструктуре быстрее воспроизводит уже накопленные проблемы.
Именно поэтому две команды могут купить одинаковые инструменты и получить совершенно разный результат. В одной агент получает задачу вместе с контекстом, доступом к системам и способом проверить свою работу, тогда как в другой сотрудники вручную объясняют каждое изменение, а затем повторно разбирают его во время ревью.
Процент написанного ИИ кода почти ничего не объясняет
Доля машинного кода удобна для презентаций, потому что быстро растёт, хорошо выглядит в заголовке и создаёт понятное ощущение масштаба. При этом она не показывает, стала ли компания быстрее выпускать продукты, сколько времени ушло на постановку задач и проверку, а также какую часть предложенных изменений пришлось исправить вручную.
Само понятие машинного кода постепенно теряет однозначность. Если агент подготовил первую версию, разработчик изменил архитектуру, а второй агент написал тесты, определить автора итогового решения уже невозможно. Тем более количество строк не позволяет сравнить одно важное архитектурное решение с сотнями механических замен в разных файлах.
Поэтому полезнее измерять, какую часть задачи ИИ довёл до состояния, в котором человеку осталось проверить спорные места и принять решение. В неудачном сценарии модель за несколько минут создаёт убедительный код, который разработчик затем несколько часов разбирает. В удачном агент самостоятельно изучает зависимости, вносит изменения, запускает тесты и возвращает результат вместе с небольшим списком вопросов.
Во втором случае кода может быть даже меньше, хотя реальная экономия времени окажется значительно выше.
Модели совершенствуются настолько быстро, что прошлогодние замеры действительно успевают устареть. Результат METR с замедлением на 19% уже нельзя считать оценкой современных агентов, но он вместе с более свежими проектами Microsoft и Google показывает общую закономерность: производительность растёт не тогда, когда ИИ начинает писать больше кода, а тогда, когда компания передаёт ему достаточно контекста, инструментов и способов проверки, чтобы человеку не приходилось выполнять ту же работу заново.
Google уже сообщает о 75% нового кода, созданного с помощью ИИ, а Microsoft получает сотни готовых пул-реквестов от Copilot. Через несколько лет эта доля вполне может приблизиться к 100%, однако главным показателем всё равно останется не количество написанного машиной кода, а объём человеческой работы, который после этого действительно исчез.
Ещё больше интересного в телеграм-канале @kindaworks.