Главный вопрос: что именно мы ускоряем

Представьте завод. Штамп выбивает деталь за долю секунды. Но машина выезжает с конвейера только после сборки, проверки и доводки. Спорить о «скорости штампа» полезно для цеха заготовок и бесполезно для клиента, который ждёт готовый автомобиль. В разработке то же самое: скорость набора строк легко спутать со скоростью доставки изменения.

Разделим понятия, которые в разговорах про ИИ часто склеивают в одно:

• скорость написания кода — как быстро появляется черновик;
• скорость выполнения задачи — сколько времени от старта до «готово» по критериям команды;
• объём кода — сколько строк или символов произведено (плохая метрика сама по себе);
• функциональная корректность — проходит ли приёмка и тесты;
• качество и поддерживаемость — читаемость, согласованность с архитектурой, цена будущих правок;
• время на проверку и исправления — ревью, откаты, «кроличьи норы» отладки;
• итоговая стоимость — человеко-часы, инциденты, переделки.

Главная мысль статьи простая и жёсткая: скорость генерации кода и скорость разработки программного продукта — не одно и то же. Пока вы измеряете только первое, любые проценты «ускорения от ИИ» будут выглядеть убедительнее, чем они есть для релиза.

Почему нужны эксперименты, а не ощущения

Разработчик после недели с ассистентом часто чувствует: «я пишу в два раза быстрее». Это ощущение правдиво как переживание потока: меньше рутины, меньше пустого экрана, больше ощущения прогресса. Но объективная проверка обязана ответить на другие вопросы.

Сколько времени ушло на задачу целиком? Был ли результат корректным? Прошли ли тесты? Сколько правок потребовалось после ревью? Можно ли принять изменение в production? Как оно встраивается в существующую систему, а не только «компилируется у меня локально»?

Отсюда принцип, который стоит повесить рядом с дашбордом: продуктивность разработчика ≠ строки кода в час. Строки — побочный продукт. Продукт — работающее, проверенное, сопровождаемое изменение. Именно поэтому ниже мы разбираем контролируемые и полевые исследования, а не только отзывы в соцсетях.

Copilot на формализованной задаче: плюс пятьдесят пять процентов

Один из самых цитируемых экспериментов — исследование Microsoft Research и GitHub вокруг GitHub Copilot. В контролируемой постановке участвовали 95 профессиональных разработчиков. Их случайно разделили на две группы, дали одну и ту же задачу на JavaScript — реализовать HTTP-сервер — и замерили время и успешность.

Группа с Copilot в среднем закончила примерно за 1 час 11 минут. Группа без ассистента — примерно за 2 часа 41 минуту. Это около 55% ускорения по времени (в публикациях GitHub фигурирует формулировка 55% faster; в доверительном интервале исследование указывало широкий разброс, но направление эффекта устойчиво). Успешное завершение задачи: около 78% против 70%.

Источники: Microsoft Research, пост GitHub о продуктивности и «счастье» разработчика.

Ограничение критично для интерпретации. Задача была относительно небольшой, ограниченной и хорошо формализованной: общий язык, понятный критерий готовности, автоматическая проверка. Это ближе к «штампу детали», чем к «выпуску автомобиля». Нельзя автоматически переносить вывод в формулировку «любой разработчик теперь программирует на 55% быстрее» — особенно в монолите с пятнадцатилетней историей, где узкое место не в наборе HTTP-обработчика, а в понимании последствий.

Качество кода: что измерял GitHub

Отдельный вопрос — не только «быстрее», но и «лучше ли». В исследовании GitHub 2024 года с 202 разработчиками (опыт Python, случайное распределение доступа к Copilot, одинаковая задача с API-эндпоинтами, затем автотесты и слепое экспертное ревью) смотрели функциональность, читаемость, надёжность, поддерживаемость, компактность и вероятность одобрения кода.

По сообщениям GitHub:

• вероятность пройти все 10 модульных тестов была выше примерно на 53,2% у группы с Copilot;
• в слепом ревью было меньше проблем с читаемостью;
• вероятность одобрения кода была примерно на 5% выше;
• небольшие, но статистически значимые приросты по читаемости, надёжности, поддерживаемости и компактности (порядка единиц процентов).

Источник: Улучшает ли GitHub Copilot качество кода?.

Здесь нужна оговорка о конфликте интересов: исследование проводит компания, чей продукт оценивается. Это не отменяет методологию и не делает цифры «фейком», но обязывает читать их рядом с независимыми работами — в том числе с METR, где картина менее радужная. Качество в лабораторной задаче с десятью тестами также не равно качеству в прод-инциденте через полгода.

METR 2025: плюс девятнадцать процентов времени на реальных задачах

Исследование METR особенно интересно тем, что уходит от учебной HTTP-задачи. Это рандомизированное контролируемое исследование на 16 опытных разработчиках открытого кода, 246 реальных задачах в крупных зрелых проектах (миллионы строк кода), с участниками, у которых в среднем около пяти лет опыта именно с этими репозиториями. В задачах — исправления, функции, рефакторинг. Источник: файл METR.

Результат: разрешение пользоваться ИИ увеличило время выполнения задач примерно на 19%. До эксперимента люди ожидали ускорения порядка 24%. После работы субъективно оценивали ускорение около 20%. Объективные часы показали замедление. В обновлении METR 2026 формулировка уточняется как about 20% slowdown на данных начала–середины 2025 — порядок величины тот же.

Это не «ИИ бесполезен». Это «в этом режиме, на этих людях и задачах, итоговый цикл стал длиннее». Разница между ожиданием и секундомером и есть сюжет следующей главы.

Иллюзия производительности

Когда субъективная оценка говорит «я стал быстрее на 20%», а измерение — «задача стала дольше на 19%», возникает отдельный феномен: иллюзия производительности. Человек чувствует прогресс, потому что экран редко пуст, варианты появляются быстро, рутина делегирована. Но итоговое время до принятого изменения растёт из‑за проверки, интеграции и отладки чужих (для ментальной модели) решений.

Иллюзия опасна управленчески. Команда может внедрить инструмент, рапортовать о «росте скорости» по опросам и одновременно удлинять цикл до слияния. Панель «строк в час» и опрос «насколько вы довольны» усилят ошибку. Нужны часы до готовности, дефекты после слияния и стоимость переделок.

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

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

Контекст. Модели нужно угадать архитектуру, соглашения, зависимости, ограничения наследия и неявные правила, которые живут в головах. Чем больше скрытого контекста, тем чаще черновик технически правдоподобен и архитектурно чужероден. Подробнее о границах понимания наследия — в разборе ИИ на 15-летнем проекте.

Проверка. Генерация дёшева. Чтение, понимание, тесты и исправления — нет. Если вы не написали код сами, ментальная модель системы не «проросла» вместе с ним: вы покупаете скорость печати ценой более дорогой верификации.

Интеграция. Собственный код часто рождается уже внутри вашей картины системы. Предложение модели может быть корректным локально и дорогим глобально: другой стиль ошибок, другой слой абстракции, обход существующего API.

«Кроличьи норы» отладки. Цепочка знакома многим: генерация → тонкая ошибка → правка → новая ошибка → ещё проверка → откат. Доверие к правдоподобному тексту усиливает ловушку. Смежный сюжет — ревью после патча агента: человек обязан проверять то, что выглядит готовым.

METR 2026: измерение стало хрупче, а выводы — осторожнее

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

Сырые оценки нового прогона у METR уже намекают на ускорение у части когорт, но организация прямо пишет: сигнал слабый, истинный эффект у «отобранных наружу» разработчиков и задач может быть выше. Вывод для читателя важнее цифры: результаты начала 2025 нельзя механически переносить на инструменты начала 2026. Модели, агенты и привычки команд изменились. Меняется и сама возможность честно измерить эффект старым протоколом.

Полевые эксперименты Microsoft: тысячи разработчиков

Крупный полевой срез — работа Microsoft Research The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Три эксперимента в Microsoft, Accenture и компании из Fortune 100, суммарно 4 867 разработчиков. В объединённых данных исследователи сообщают о приросте порядка +26% к числу выполненных задач у тех, кому дали ассистента для написания кода. Эффект неоднороден: менее опытные разработчики чаще интенсивнее использовали ИИ и получали больший прирост.

Источник: Microsoft Research.

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

Почему исследования спорят друг с другом

Центральный аналитический ответ: они измеряют разное и ставят людей в разные условия.

Добавьте конфликт интересов у вендоров, размер выборки, длительность наблюдения и то, разрешено ли выбирать задачи. Тогда «55% быстрее» и «19% медленнее» перестают быть загадкой и становятся двумя точками на карте режимов работы. Про агентный режим и платформенные ограничения см. также агентную инженерию 2026 и почему агентам нужна платформа, а не только скорость печати.

Полный цикл: от замысла до слияния

Предложим простую модель полного времени:

T_total = T_design + T_generation + T_review + T_debug + T_test + T_integration

ИИ особенно уверенно бьёт по T_generation. Иногда помогает и T_design (быстрые наброски вариантов). Но он же способен увеличить T_review, T_debug и T_integration — особенно когда черновик чужой по стилю и знаниям системы. Итог может быть положительным, нулевым или отрицательным. Оптимизировать только генерацию — всё равно что ускорять штамп, игнорируя ОТК и сборку.

Отсюда практическое правило: любой пилот ассистента измеряйте по time-to-merge, дефектам после слияния и числу итераций ревью, а не по скорости автодополнения в IDE. Экономика токенов без экономики переделок обманывает так же, как дешёвая модель без учёта полного цикла — см. совокупную стоимость дешёвой LLM для агента.

Усилитель, а не замена: junior, middle, senior

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

Junior. Порог входа падает: объяснения ошибок, boilerplate, варианты реализации. Риск зеркальный: принять код, который не понимаешь. Без наставничества и тестов «ускорение» превращается в долг.

Middle. Здесь ассистент часто даёт максимум бытовой пользы: генерация, рефакторинг, тесты, документация, разведка. Именно эта группа часто видна в полевых приростах числа задач.

Senior. ИИ — множитель: альтернативные архитектуры, быстрый прототип, автоматизация рутины, разбор компромиссов. Senior быстрее замечает плохое предложение — и быстрее попадает в ловушку METR, если экономит на проверке «правдоподобного» патча в знакомой системе.

Полевые заметки о том, как сильные команды внедряют инструменты без театра хайпа: за хайпом. Про замер агента в тестировании — 11 недель с ИИ-тестировщиком.

Как поставить свой A/B-тест в команде

Возьмите 20–50 реальных задач из бэклога (не учебный HTTP-сервер). Случайно или по очереди распределите условия: без ИИ и с ИИ (зафиксируйте, какими инструментами и версиями). Измеряйте время до готовности, число итераций, ошибки, правки после ревью, покрытие тестами, дефекты после слияния. Не сравнивайте только строки кода.

Минимальный набор метрик:

• скорость: time-to-first-working-code, time-to-completion, time-to-merge;
• качество: доля прошедших тестов, частота дефектов, инциденты, отказы на ревью;
• сопровождаемость: сложность, дублирование, согласованность с архитектурой;
• экономика: стоимость закрытой задачи, часы на фичу;
• человек: когнитивная нагрузка, уверенность, эффект обучения (понимает ли автор свой же патч через неделю).

Без такого контура любой внешний процент — чужой анекдот в красивой обёртке.

Что уже можно утверждать осторожно

1. ИИ способен сильно ускорять некоторые задачи программирования — особенно короткие и формализованные.
2. Эффект зависит от типа задачи, тестов, знакомства с кодовой базой и режима инструмента.
3. Ускорение генерации не гарантирует ускорения всей разработки.
4. Качество может улучшаться в контролируемых условиях, но это не автоматически переносится в прод.
5. Опытные авторы в зрелых репозиториях иногда получают меньше пользы, чем ожидают — вплоть до замедления.
6. Новые поколения моделей и агентов делают снимки 2022–2025 историческими, не вечными.
7. Субъективное ускорение часто расходится с часами.
8. Корректное сравнение — человек без ИИ против человека с ИИ, а не человек против модели.

Частые вопросы

Что почитать дальше

Рядом на сайте: ИИ и 15-летний проект, ревью кода в эпоху ИИ, агентная инженерия 2026, агентам нужна платформа, как команды внедряют ИИ без хайпа, 11 недель с ИИ-тестировщиком, химия кода как рамка решений.

Заключение

Вопрос «кто быстрее пишет код — человек или ИИ?» плохо поставлен. Модель пишет черновик быстро. Человек с моделью может закрывать задачу быстрее или медленнее — в зависимости от того, что вы считаете «закрытой задачей». Исследования Microsoft, GitHub и METR не спорят друг с другом, если читать их как карту режимов: учебный стенд, качество в лаборатории, зрелый открытый код, корпоративное поле, смена поколений инструментов.

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