ИИ ускоряет разработку на 55%: проверяем цифру из презентаций

У цифры «55% быстрее» есть день рождения

Сентябрь 2022 года, эксперимент GitHub, позже оформленный в статью «The Impact of AI on Developer Productivity: Evidence from GitHub Copilot». Участников просили написать HTTP-сервер на JavaScript. Группа с Copilot уложилась в 1 час 11 минут, группа без него провозилась 2 часа 41 минуту. Отсюда 55,8% – и вся дальнейшая блестящая карьера этого числа.

Дальше идёт мелкий шрифт. До конца задачу довели 35 человек. Доверительный интервал ускорения – от 21% до 89%: реальный эффект мог оказаться вчетверо скромнее заголовка. Доля успешно выполненных задач подросла на 7 процентных пунктов, и это различие статистически незначимо. Качество кода авторы честно вынесли за скобки, о чём в презентациях обычно забывают.

Получается аккуратный замер одной учебной задачи на крошечной выборке. А живёт он в 2026 году как закон всемирного тяготения.

Моя позиция простая: цифра ускорения без описания выборки и задачи – это слоган, а не измерение. Слоганом можно продавать. Планировать по нему нельзя.

Как один и тот же METR получил и минус 19%, и плюс 18%

Июль 2025 года, рандомизированное исследование METR: 16 опытных разработчиков, 246 реальных задач в собственных зрелых репозиториях, где у людей за плечами в среднем пять лет работы с проектом. До эксперимента участники ждали ускорения на 24%. После – были уверены, что ускорились на 20%. Секундомер показал, что с ИИ задачи занимали на 19% больше времени.

Продолжение вышло 24 февраля 2026 года под заголовком «We are Changing our Developer Productivity Experiment Design». Новый заход шире: 57 разработчиков, 143 репозитория, больше 800 задач. У вернувшихся участников вышло ускорение около 18%, у новичков – около 4%. И сам METR просит эти числа всерьёз не принимать.

Вот объяснение, ради которого стоит открыть тот пост. Заметно больше приглашённых разработчиков просто отказались участвовать: работать без ИИ они уже не хотят. Оплата участия упала со 150 до 50 долларов в час – выборка перекосилась ещё раз. А главное, сломался хронометраж: человек запускает агента и уходит заниматься другим, и «время задачи» превращается в фикцию.

Линейка перестала мерить, потому что изменился тот, кого меряют. Для меня это самая полезная новость года про производительность.

Куда девается ускорение на уровне компании

Faros AI в отчёте The AI Engineering Report 2026 перелопатил два года телеметрии: 22 000 разработчиков, больше 4 000 команд, сравнение периодов низкого и высокого внедрения ИИ внутри одних и тех же организаций. Не опросник, а выгрузки из таск-трекеров, гита, CI/CD и систем инцидентов.

Скорость и правда выросла: задач на разработчика +33,7%, эпиков +66,2%, влитых пул-реквестов +16,2%. А рядом в той же таблице живут другие строки: багов на разработчика +54%, инцидентов на пул-реквест +242,7%, медианное время ревью +441,5%, доля мерджей вообще без ревью +31,3%. ИИ-ассистированные пул-реквесты примерно в 2,5 раза толще обычных и ждут первого ревьюера около 16 часов против 200 минут у человеческих.

Bain в Technology Report 2025 подводит арифметику: команды с базовыми ИИ-ассистентами выигрывают 10–15%, но генерация кода – это 25–35% времени от идеи до запуска. Разогнали одну стадию – узкое место переползло в ревью и тестирование. Ровно это и торчит из цифр Faros.

Скорость есть, а переделок больше

GitClear разобрал 211 млн изменённых строк за 2020–2024 годы. Доля кода, переписанного в течение двух недель после коммита, поднялась с 3,1% до 5,7%. Легаси тут ни при чём: код такого возраста переписывают, потому что он сразу вышел не тем. Копипаста в 2024 году впервые обогнала перенос строк, а число блоков с пятью и более дублированными строками за год выросло многократно.

Veracode прогнал 80 задач через сотню с лишним моделей: в 45% случаев модель выбирает небезопасный вариант там, где выбор между безопасным и небезопасным вообще есть. В обновлении весны 2026 года с GPT-5.1, Gemini 3 и Claude 4.5/4.6 доля не сдвинулась.

Что мы в CRT сначала померили не то

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

Сейчас держим три числа. Сколько задач доехало до прода за период. Какая доля из них вернулась – с тестирования, от заказчика или инцидентом после релиза. И сколько прошло от постановки до работающей функциональности. Ускорение видно только там, где первая цифра растёт, а вторая за ней не тянется. На AI Software Engineer мы поэтому и ведём задачу одним инженером на всём маршруте: если выигрыш съедается на стыке «написал – отревьюили – протестировали», стыков должно быть меньше.

Где я не прав: если команда лепит прототипы на выброс, проверяет гипотезы и через месяц всё сносит – точность измерений тут лишний груз. Пишите быстро, не считайте ничего.

Три вопроса к любой цифре в презентации

1. Какая задача и какая выборка? Учебный HTTP-сервер и рефакторинг в чужом зрелом репозитории – разные вселенные.
2. Что мерили: написание кода или путь до продакшена? Первое ускоряется почти всегда, второе – как повезёт.
3. Какие контрметрики показали? Есть только рост, а багов, ревью и переделок нет – перед вами буклет.

Эти три вопроса закрывают процентов девяносто разговоров про «мы стали быстрее в два раза».

Вместо морали

Хорошая новость: проверить цифру дешевле, чем раскатить по ней инструмент на всю команду. Плохая: свои метрики придётся собирать руками, потому что чужие собраны под чужую задачу. Если хочется понять, что у вашей команды с реальной пропускной способностью до внедрения ИИ и после, это ровно тот разговор, который мы ведём в консалтинге для IT-команд.