ИИ не ускоряет разработчиков. Он увеличивает разрыв между ними

Мне больно смотреть на некоторых знакомых разработчиков. Это сильные инженеры, которым я без колебаний доверил бы архитектуру сложной системы или авральную починку прода. Но, к моему удивлению, с современными coding-агентами уровня Claude Code или Codex многие из них до сих пор толком не работали.

В лучшем случае компания развернула не самую мощную open source-модель: медленную, с коротким контекстом и без доступа к интернету. Агент тормозит, теряет контекст, ломает работающий код и невозмутимо ссылается на несуществующую функцию. Разработчик несколько раз пробует, тратит больше времени, чем экономит, и выносит приговор:

Весь этот AI — переоценённая игрушка.

Некоторые пробовали год назад. Модели с тех пор сменились несколько раз, а приговор — нет. У разочарования вообще многолетний срок хранения.

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

Цифры, кстати, легко поддержат скептика. В 2025 году METR провёл контролируемый эксперимент: 16 опытных open source-разработчиков выполняли 246 реальных задач в хорошо знакомых им проектах. С AI они работали в среднем на 19% медленнее.

Почти одновременно исследование в Microsoft, Accenture и компании из Fortune 100 обнаружило среди 4867 разработчиков рост числа завершённых задач на 26%. А в соцсетях уже рассказывали про 2×, 5× и 10×.

Так где же правда? Спорить бесполезно. Похоже, все измеряют разные вещи, но называют всё это продуктивностью.

Два разработчика, одна галочка

Один человек несколько раз в день нажимает Tab, просит чат объяснить регулярное выражение и потом исправляет за моделью поломанную типизацию. Другой поручает агентам задачи целиком, запускает несколько сессий параллельно, принимает результат по тестам, отдаёт diff другой модели на критическое ревью и проверяет изменение в реальной среде.

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

В опросе обоим поставят одну галочку: «пользуется AI». Потом их результаты усреднят и получат те самые скромные проценты.

Исследование здесь не врёт. Врёт классификация, которая смешивает практически разные способы работы.

ИИ пока не сделал всех разработчиков быстрее. Он увеличил расстояние между ними.

Мы платим не только за токены

Компании привыкли покупать софт по количеству лицензий. Выдали сто лицензий с лимитами, подождали квартал, посмотрели на среднюю продуктивность. Революции нет — значит, маркетологи снова всех обманули.

Но лицензия не равна доступу. Важны модель, размер контекста, доступ к репозиторию и инструментам, лимиты и скорость. Она определяет, сколько попыток человек успевает сделать за день.

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

Быстрый агент участвует в разговоре. Медленный напоминает подрядчика: отдаёшь ему задачу и надеешься получить что-нибудь полезное к завтрашнему вечеру.

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

В такой конфигурации компания потом пишет в отчёте, что AI внедрён, но заметного роста производительности нет. Хотя оплатила она, по сути, ограниченный пилот.

Дешёвая модель иногда оказывается самой дорогой. Плохой diff можно выбросить. Гораздо хуже, когда после нескольких таких попыток хороший инженер больше не хочет экспериментировать.

Где живут 5× и 10×

Кратный рост редко возникает из одной только модели. Вокруг неё должен сложиться рабочий процесс.

Мне нравится публичный кейс Davis Vaughan, разработчика dplyr и других ключевых пакетов экосистемы R. С помощью Claude Code он подготовил около двухсот наборов изменений для open source-проектов. Каждый прошёл человеческое ревью и превратился в pull request.

По его собственной оценке, вручную эта работа заняла бы около 33 часов. С агентами Vaughan потратил восемь — примерно в четыре раза меньше.

Всё получилось не сразу. Агенты отступали от плана, упирались в лимиты GitHub, а иногда редактировали файлы не там, где нужно. Ускорение появилось после того, как Vaughan ужал и изолировал задачи, а финальное «можно вливать» оставил за собой.

Есть и более громкие цифры. Nubank заявляет о 8–12-кратном сокращении человеческих часов на части миграции многомиллионной ETL-системы с помощью Devin. Это success story реальной компании, а не независимый эксперимент, но способ расчёта описан: обычные часы ручной миграции сравнивались со временем на постановку задач агенту и проверку результата.

Большие множители легче показать на повторяемой работе. Однако ими дело не ограничивается.

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

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

Почему такие цифры не видны повсюду, хорошо показывает наблюдение за более чем 100 тысячами GitHub-разработчиков. С автономными агентами число коммитов выросло на 180%, проектов — примерно на 50%, а реальных релизов — примерно на 30%.

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

Код уже ждёт разработчиков

Intercom попыталась перестроить вокруг AI всю R&D-организацию. Через девять месяцев компания сообщила о двукратном росте числа merged PR на сотрудника R&D. В том же отчёте число продуктовых изменений в марте более чем вдвое превысило январское, а медианное время от идеи до выпуска сократилось на 39%.

Honeycomb тоже показала рост объёма изменений, но рассказала и о цене. Пиковое число слияний в монорепозиторий выросло примерно с 30 до 74 в день, а число инцидентов — с базовых 18,5 за квартал до 53. Авторы отмечают, что инциденты росли примерно вместе с объёмом изменений, и одновременно менялись команда, платформа и характер задач. Поэтому приписывать AI весь эффект нельзя. Тем не менее этот разбор хорошо показывает новое узкое место.

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

Среднее значение по компании этого не покажет. Одни сотрудники уже получают кратный выигрыш, другим AI пока не даёт ничего. Поэтому полезнее разбирать конкретные способы работы. Если у кого-то получилось ускориться, стоит разобраться, на каких задачах, с какими моделями и как он работал, — а затем помочь коллегам повторить этот опыт.

Но одной технологией это не решить.

Разработчики не дураки

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

Он получит премию, повышение или больше свободы? Или ещё четыре дневные нормы?

Если приз за скорость — новая норма, молчание становится рациональной стратегией. Кто-то потратит выигранные часы на семью или отдых, кто-то — на pet project, кто-то попробует параллельно работать на другую компанию. Для корпоративной статистики итог одинаков: время освободилось, но работодателю не досталось.

Экономия возникает у человека, а не в бухгалтерской системе. Чтобы она превратилась в продуктивность компании, её придётся выкупить доверием, деньгами, свободой или карьерным ростом.

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

Возможно, некоторые разработчики уже работают в несколько раз быстрее. Просто не обязательно для вас.

Динозавры ещё ходят на стендапы

Есть удобный способ не замечать происходящее: объявить нейрослопом всё, к чему прикасался AI.

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

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

Есть и другая неприятная ассоциация. Люди, которые в ближайшие годы принципиально откажутся сливаться в экстазе с AI, напоминают динозавров, уже вымерших, но пока об этом не знающих.

Динозавр не был глупым животным. Он прекрасно подходил для мира, которого больше нет. Профессиональное вымирание тоже редко выглядит как мгновенное увольнение: человек продолжает получать зарплату, обслуживать legacy и ходить на стендапы, хотя его способ производства уже проиграл экономически.

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

В отличие от динозавров, разработчик может поменять способ работы.

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

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

А если недельная работа вдруг поместится в один день, главный вопрос придётся задать работодателю: что вы сделаете — вознаградите разработчика и изучите его лайфхаки или просто выдадите ещё четыре недели работы к пятнице?

Пожалуй, прежде чем измерять прирост продуктивности от AI, стоит проверить готовность компании не наказать человека за него.

Автор: Павел Косяков, основатель DevGhost.ru — сервиса оценки эффективности разработчиков.