Почему исследования показывают скромный эффект, а отдельные разработчики и команды ускоряются в разы за счёт AI
Мне больно смотреть на некоторых знакомых разработчиков. Это сильные инженеры, которым я без колебаний доверил бы архитектуру сложной системы или авральную починку прода. Но, к моему удивлению, с современными 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, стоит проверить готовность компании не наказать человека за него.
Комментарии (26)
ic10
18.10.2026 11:01двух разработчиков: одного, стучащего усердно по клавиатуре, и другого, думающего, научившегося распоряжаться машинным временем.
Ох какая гнилая манипуляция. Слопер, нажимающий кнопку OK -- это думающий, а человек, который разрабатывает своим мозгом -- это обезьяна, стучащая по клавишам.
Woodroof
18.10.2026 11:01Даже с AI человек разрабатывает своим мозгом, потому что именно он ставит задачу и принимает результат. Просто всё монотонное машина берёт на себя. И в итоге легко ускориться в разы, просто распараллелив задачи и не тратя время на рутину.
Качество от этого не падает, даже наоборот, при грамотно построенном процессе - растёт. Другое дело, что сейчас весь день разработчика - это сплошной сложный мысленный труд, и рутины, которая даёт голове отдыхать, почти не остаётся.
В итоге да, производительность выросла, но вот оплата труда та же, усталости больше, а работаем, т.к. ничего другого не умеем, в отрасли кризис, кушать надо, а разработки без AI скоро уже и не останется.
Я не знаю, как сейчас в РФ, т.к. на мой личный вкус только Opus 5.5 дошёл до уровня, когда результат стал нормальным (до этого приходилось очень сильно сужать задачи и выстраивать более сложные процессы, чтобы получать приличный результат), а Claude в России, как я понимаю, не доступен. Но пара лет, и будет уже везде.
Vindicar
18.10.2026 11:01Даже с AI человек разрабатывает своим мозгом, потому что именно он ставит задачу и принимает результат.
Не доказано. Даже во времена stack overflow были те, кто разрабатывал, пользуясь буфером обмена, а не мозгом. И вопрос в том, как отделить тех, кто "пользовался, не вникал в результат" от тех, кто "пользовался, вникал в результат". С учётом того, что первых будет кратно (на порядки?) больше.
Woodroof
18.10.2026 11:01Постановку задачи со stackoverflow не скопируешь, плюс есть (пока что) review.
Те разработчики, которые до AI были так себе, даже с AI не стали сильно лучше, разрыв в производительности только вырос.
becefi
18.10.2026 11:01Claude в России, как я понимаю, не доступен
Не совсем правильно понимаете )
Все в основном только на нем и работают.
Pavel1981 Автор
18.10.2026 11:01Те кто реально думают и ценят свое время, они уже давно переехали на ИИ. главное, чтобы была возможность использовать флагманские модели, а не мучать корпоративный qwen 80b. Разрабатывать своим мозгом можно не только стуча по клавишам.
Flux
18.10.2026 11:01Мне больно смотреть на некоторых знакомых разработчиков. Это сильные инженеры, которым я без колебаний доверил бы архитектуру сложной системы или авральную починку прода. Но, к моему удивлению, менеджмент заставил их большинство кода генерировать современными coding‑агентами уровня Claude Code или Codex и многие из них превратились в прокладку между llm и репозиторием и тупеют буквально на глазах, а сама кодовая база превращается в неподдерживаемый слоп потому что пишет агент, ревьюит агент и баги в этой лапше потом тоже ищет агент.
Зато менеджмент очень доволен, они думают что производительность команд сильно выросла.
Serge1001
18.10.2026 11:01Это ещё что, а представьте что будет если дать нейросеть новичку (джуну какому-нибудь) который сам и не писал никогда
Вам потом на ревью попадёт просто лютый нейрослоп от этого джуна
кодовая база превращается в неподдерживаемый слоп потому что пишет агент,
Так в вашем случае это ещё ничего - опытный инженер хотя бы проверяет работу нейросети (но конечно сам деградирует при этом)
KongEnGe
18.10.2026 11:01Менеджмент еще очень доволен, что наконец-то стали генерироваться одноразовые артефакты вроде развернутых описаний на пулл-реквесты. Читать их никто не будет никогда, но за стеклом смотрятся основательно на какой презентации.
Last_Mile
18.10.2026 11:01Самая правильная, на мой взгляд, Ваша фраза:
Экономия возникает у человека, а не в бухгалтерской системе. Чтобы она превратилась в продуктивность компании, её придётся выкупить доверием, деньгами, свободой или карьерным ростом.
WaRLoC
18.10.2026 11:01Если о статье кратко, то это про - до сих пор нет метрик, которые адекватно оценивают эффект использования иишниц...
itmind
18.10.2026 11:01Примерно год использую в разработке последние модели OpenAI и Claude. Да, внешне работающее решение они делают относительно быстро, но логика кода — это мрак. Ненужные абстракции, дублирование функционала, извращённая логика. Тыкаешь ИИ в это, он соглашается, переделывает. На это тратится очень много времени. Агент может написать тысячи строк кода за несколько часов, но потом мы с ним сидим и переделываем 2 дня. Никакие правила не помогают — их становится много, контекст забивается и фокус модели теряется. Выглядит так, как будто моделям скормили тонны говнокода и приправили всевозможными паттернами и стилями написания кода. Получилась адская смесь, которая может просто подряд сделать 3 полных обхода одного массива (типа это функциональный стиль), использовать кучу выделений памяти и т. д. Притом чем больше растёт кодовая база, тем больше проблем в коде агентов и поломок.
Одной моделью пользоваться нельзя, нужно обязательно двумя: одно семейство моделей делает задачу (opus 5.5 high), другое семейство ревью (gpt 6 sol extra high). Всегда модели находят проблемы в реализации при ревью. При этом можно сделать 5 ревью подряд, и в каждом будет найдена новая проблема.
Когда код писали люди, не было такой проблемы. Я знал уровень каждого своего сотрудника: за кем нужно перепроверять каждую строку (джуны), за кем общую реализацию (мидлы) или просто протыкать результат с точки зрения пользователя (сеньоры). А с моделями всегда как с джунами, только если джун выдавал сотни строк на проверку, то за моделью нужно проверять тысячи строк. Уже сменилось много поколений моделей, но качество кода особо не улучшилось. Выросла только автономность и способность наговнокодить конечный результат всё больших задач.
Посмотрите качество тех же Codex и Claude code, которые пишутся агентами: куча проблем, и с каждой версией всё хуже.
Есть и плюсы: ускорение анализа, быстрое получение работающих прототипов, быстрые эксперименты, огромное ускорение на механических правках и рефакторинге.
Woodroof
18.10.2026 11:01Может, не пытаться сразу просить написать тысячи строк, а разбивать на более мелкие задачи?
Я обычно сначала описываю, как бьём задачу, после каждого этапа — отдельный коммит, ревью, и частенько сброс контекста.
Но даже с таким до 5.5 работало так себе, а вот последняя версия Opus'а в таком режиме неплохо справляется.
Pavel1981 Автор
18.10.2026 11:01А действительно ли нам везде нужен идеально вычитанный код?
У прототипа задача — быстро проверить гипотезу. У стартапа — запуститься и понять, нужен ли продукт вообще. Месяц на красивую архитектуру иногда обходится дороже, чем потом её переделать после апробации в бою, понимая, что реально нужно и важно.
Для средних компаний с десятками или сотней пользователей тоже далеко не всегда нужна супернадёжная и ремонтопригодная архитектура. Достаточно, чтобы закрывало задачу и можно было быстро поправить. Особо крутое качество реально нужно для mission critical систем в крупных компаниях. Но кто там работал, знает, что процент говнокода и без ИИ зашкаливает — и ничего, работает годами.
Важно не то, насколько код близок к идеалу, а сколько времени и сил ушло на решение задачи и что в итоге получилось.
mahmud90
18.10.2026 11:01Всегда модели находят проблемы в реализации при ревью. При этом можно сделать 5 ревью подряд, и в каждом будет найдена новая проблема.
Присоединяюсь. В большом проекте, при реализации сколь-нибудь сложной логики, тоже всегда наблюдаю такую картину.
Вайбкодерам не-программистам при реализации своих пет-проектов с помощью ИИ кажется, что он не ошибается, и проверять за ним необязательно. Еще им кажется, что качество кода - дело десятое (и так сойдет!) - ведь работает же! И эту логику они экстраполируют на профессиональное программирование.
Serge1001
18.10.2026 11:01Ускоряет тех кто умеет работать и без ИИ, кто давно в IT
А если у человека нет опыта разработки, то для него нейрослоп нейросети - это магия (работает и ладно)
Поэтому я бы вообще не доверял пушить в репозиторий тем кто не умеет кодить без ИИ
usiqwerty
18.10.2026 11:01Всё получилось не сразу. Агенты отступали от плана, упирались в лимиты GitHub, а иногда редактировали файлы не там, где нужно.
Звучит как сырой продукт
Dhwtj
Это не даёт ответ на вопрос что делать в конкретном проекте.
vvovas
Я для себя решил попробовать настроить правила и ограничения для ИИ так, чтобы при генерации кода он был максимально похож на стандарты, по которым мы сами пишем.
Без этого ты можешь быстро делать задачи и они будут сделаны в целом хорошо. Потому что скорость анализа, реализации и фиксов вырастет в разы и оставшееся время просто будет потрачено на очень хорошее тестирование. Но при этом, если что-то в итоге и пропустят и какой-то баг нужно будет исправлять, я не думаю, что кто-то захочет разбираться в этом коде. За плечами пара задач, которые были решены именно так с оговоркой, что это будет проревьюено и исправлено в ближайшее время. Но сжатые сроки для этих задач перевесили в пользу подхода: пишем все агентами.
В итоге в проекте будет расти кодовая база, в которую никто не захочет лезть руками, исправлять будут через ИИ и получится снежный ком. Так что пока моя теория в том, чтобы планомерно на старте делать все медленнее и каждый странный кусок кода, который ИИ тебе выдал исправлять правилами, стандартизацией подходов и так далее. Чтобы со временем, ты безопасно мог поручать задачи ИИ, на выходе видел знакомый код, который тебе легко читать и в который ты не боишься залезть позже сам.
Пока это только теория, так как это задача на ближайшее будущее.
Woodroof
Даже если ревьюить всё, что выдаёт AI, знание кода всё равно будет хуже, чем когда написал руками. Другое дело, что я не знаю, что с этим делать, и не уверен, что вообще нужно. Кажется, нынче нужно знать архитектуру, а не детали реализации отдельных кусочков.
Pavel1981 Автор
Тут нет других вариантов, кроме как не опускаться ниже архитектурного уровня. ИИ ускоряет разработчика на порядок, x10. это видно по росту продуктивности отдельных контрибьюторов даже в опенсорсе, не только в приватных репах. можно и дальше игнорировать объективную реальность, не верить новостям, где ведущие западные компании отчитываются о кратном росте объема качественного кода на человека, продолжать вычитывать код самому, вместо контроля арх. развилок. но через год есть риск остаться без работы. именно эту мысль я пытался донести
vvovas
Тут важно понимать, что компании разные и отчитывают о круто работающем и эффективном ИИ чаще крупные комании с сильной командой разработки. Командой, которая смогла выработать стратегию для использования ИИ эффективно.
А потом менеджеры в простых компаниях радостно машут статьями перед своими разработчиками и хотят таких же свершений, однако ни процессов, ни сильной тех. базы в этой компании нет. И возникает конфликт.
mckeenly15
И снова эта догматическая безапелляционность, типичная для продавцов ИИ. Можете привести конкретные примеры и доказательства ускорения "x10"? Метрики, результаты исследований, ссылки на какие-то новости, посты?
Тот же самоуверенно-пренебрежительный стиль: разработчик который до сих пор пишет и даже читает код - это уже "динозавр". "Вы еще не внедрили ИИ? Тогда мы идем к вам!"
vvovas
Не скажу, что ревьюить за ИИ легко и приятно, как по мне так наоборот, по причине того что код написанный командой и ИИ слишком различается. Нестандартные именования, непривычная логика деления кода на части, странные места расположения отдельных классов и утилит.
Собственно это я и хочу научиться исправлять.
Про детали реализации: вы все равно будете знать, то над чем вы работали, если сами продумывали и обсуждали решение с ИИ, а затем он по этому обсуждению делал. Иначе у вас будет магия, которая выглядит рабочей, но по косвенным признакам вы подозреваете, что внутри все не так хорошо как в UI. У меня есть и такие примеры - мой нынешний pet project, который сейчас пишется только через Claude и я абсолютно не представляю как он внутри написан. Этот проект сейчас в глубокой альфе и мне важнее пощупать интерфейс и отработать UX, чем писать все по правилам. Но, как я и сказал, иногда при работе прям видно признаки очень неоптимизированного и проблемного кода.
WaRLoC
Ищи свои метрики и собирай. И то, на единичном потоке все равно выгоднее наощупь.