Почему AI не ускорил разработку в 10 раз

Почему AI не ускорил разработку в 10 раз

Понедельник, кикофф квартала. СТО по имени Дамир (контора собирательная, потерпите) кидает в общий чат пересланный пост с заголовком «AI ускоряет разработку в 10 раз» и говорит: «Так, коллеги. Со следующего спринта живём по-новому. В цели квартала закладываю: фичи выкатываем втрое быстрее. Инвестор не простит, если мы проспим AI-волну». Команда покивала. Всем закупили Cursor и Claude Code, в Jira завели эпик «AI-трансформация», в вакансиях появилась строчка «AI-first команда».

Проходит квартал. Дамир открывает дашборд на ретро. Строк кода втрое больше. Закрытых тасок больше. А время от «взяли в работу» до «уехало в прод» стоит ровно там же, где стояло до всей этой истории. В углу переговорки сидит Лёша из QA с лицом человека, который последние три недели спал по графику стартапера. За его спиной очередь ревью: двести пулл-реквестов, и один из них на сорок тысяч строк, который никто не решается открыть.

Контору я выдумал. Дамира и Лёшу тоже. Но если вы дёрнулись, узнав их, дальше будет полезно.

«Где мои иксы?»: что видно, когда наконец считаешь

Дамир мерил скорость так, как её меряют почти везде: строки кода, закрытые таски, сожжённые story points. По всем этим цифрам команда реально ускорилась. Кода стало больше, тикетов закрывается больше, отчёт наверх красивый. Не двинулась одна-единственная метрика, ради которой всё и затевалось: сколько проходит от идеи до работающей фичи у пользователя.

Что один разработчик чувствует ускорение, которого нет, я разбирал в отдельном лонге про замер AI-сессий. Если коротко: METR в начале 2025-го посадила опытных разработчиков на знакомые им проекты, и с AI-инструментами те выполняли задачи на 19% дольше, хотя сами были уверены, что ускорились процентов на двадцать. Разрыв между ощущением и секундомером там почти сорок процентных пунктов. Год спустя METR пересняла замер на свежих моделях и сама оговорилась: ранняя цифра устарела, сегодня разработчики, скорее всего, ускоряются заметнее. Только чистого ускорения секундомер всё равно не показал. Повторные замеры вышли смазанными: разброс накрыл и лёгкое замедление, и небольшое ускорение. Да и сам сигнал METR назвала ненадёжным: те, кому AI заходит лучше всех, перестают участвовать в исследовании. Самовыборка. Не сдвинулось одно: люди по-прежнему оценивают свою скорость оптимистичнее, чем показывает таймер.

Это про одного человека. Но Дамиру продали не ускорение одного человека, ему продали ускорение конвейера. А на уровне конвейера всё ещё интереснее.

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

Кодинг это один станок на конвейере

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

Ничего хорошего, если третий станок не был узким местом. Детали быстрее долетают до четвёртого станка и копятся перед ним горой. Завод как выпускал N изделий в день, так и выпускает. Вы ускорили только темп, с которым растёт очередь перед четвёртым станком.

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

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

Поставил быстрый станок не на то место, и завод этого даже не заметил.

Куда уехало узкое место (на тех, кто и так тонул)

Узкое место не исчезает от AI. Оно переезжает. И переезжает оно, как назло, на самые недоавтоматизированные этапы: ревью, тестирование, координацию.

Лёша из QA это узкое место в человеческом облике. Раньше команда генерила N строк в день, и он успевал. Теперь генерит втрое больше, багов в этом коде пропорционально больше, а Лёша по-прежнему один. Я в такой роли сидел, знаю изнутри: это не лень и не тупость, просто объём изменился, а часов в сутках столько же. Код стало писать дёшево, а проверять, понимать и принимать его дёшево не стало.

Это не моё ворчание, это видно в данных. Отчёт DORA за 2024 год показал неприятное: с ростом внедрения AI на 25% оценочная пропускная способность доставки падала на 1.5%, а стабильность релизов на 7.2%. AI поднимает индивидуальную продуктивность и удовольствие от работы, и одновременно роняет доставку. Там же есть цифра, которая всё объясняет: 39% разработчиков почти не доверяют коду, который сгенерил AI. То есть его всё равно надо перечитывать глазами, просто теперь его втрое больше.

GitClear копнул код напрямую, разобрал 211 миллионов изменённых строк за пять лет. Доля скопированного кода выросла с 8.3% до 12.3%, число продублированных блоков подскочило примерно в восемь раз, а рефакторинг (это когда код причёсывают и упрощают) просел с 25% до меньше чем 10%. И ещё: доля кода, который переписывают в первые две недели после коммита, выросла почти вдвое. AI выдаёт больше кода, который живёт меньше и хуже стыкуется с остальным. Кто-то потом разгребает этот пир. Обычно ревьюер и Лёша.

А дальше масштаб. Недавно в форк WebKit от Bun прилетел пулл-реквест на 280 тысяч строк, сгенерированный AI. Не сорок тысяч, как у Дамира, а почти триста. Кто это будет ревьюить? Как это мержить в живой проект, который ведут люди? Не случайно Cursor уже строит Origin, отдельную платформу под хранение кода: говорят прямо, что GitHub делали для людей, а теперь нужна инфраструктура под армии агентов, которые читают и пушат код на порядок чаще. Узкое место переехало так заметно, что под него начали строить новый завод.

Мой собственный замер: где AI съел время, а где вернул

Теперь про себя, без всякого Дамира. Как я мерю свои сессии, расписывал в другом месте, повторяться не буду. Тут интереснее, что мои кустарные цифры сошлись с промышленными. Я завёл лог сессий, и поначалу у меня был высокий процент реворка. Сел разбираться, с чем связано. Оказалось, я грешил быстрыми сессиями планирования, и дип-ресёрч у меня, прямо скажем, был так себе. Я мог переделать фичу два раза, а потом просто откатить всё назад, потому что «ну не то получилось». Главная боль была даже не в коде: мне не хватало насмотренности, чтобы превратить идею в голове во что-то пригодное.

Конкретный жанр факапа выглядел так. Я давал агенту ТЗ, описывал как мог, как сам видел реализацию, а на выходе получал то, что мне не подходило. Особенно весело было с интерфейсом: элементы наезжали друг на друга при другой вёрстке, агент забывал добавить адаптивность, и я ловил это уже глазами, постфактум. Двадцать минут генерации экономили мне час. Разбор того, что нагенерилось, отъедал два.

Это ровно то, что нашли в Стэнфорде. Йегор Денисов-Бланч с командой разобрал данные почти ста тысяч разработчиков и развёл результаты по типам задач. На новых, простых проектах AI даёт честные плюс 30-35%. А на сложных задачах в больших старых кодовых базах прирост падает до 5-10%, и у заметной доли команд продуктивность вообще уходит в минус. Вывод, который бьёт под дых: примерно половину валового прироста съедает реворк. Фикс багов, которые насочинял агент, вычистка логики, которую он галлюцинировал, причёсывание кода под конвенции проекта.

Я про это уже писал с другой стороны: обвязка не спасёт кривой проект. Harness это усилитель, и усиливает он в обе стороны. Та же беда и с метриками: можно перестроить красивый процесс и получить ноль эффекта, если оптимизировал не то место. AI тут просто новый, очень убедительный способ оптимизировать не то место.

Где AI всё-таки даёт иксы (и не там, где ждал Дамир)

Если бы я тут остановился, получилась бы пропаганда «AI не работает». Это вранье. Работает, и местами реально кратно. Просто иксы лежат не там, где их искал Дамир.

В моих же логах есть и обратная сторона. В трёх-четырёх случаях из пяти мне удавалось получить что-то среднее (в хорошем смысле: рабочий черновик, не мусор), что дальше можно шлифовать, и без AI на это ушли бы дни, не преувеличиваю. А там, где AI для меня даёт настоящие иксы, это простые скрипты для выгрузки данных и кластерные анализы, либо начальные MVP-проекты. То, что раньше я бы писал полдня, гугля синтаксис pandas, теперь рождается за пять минут и сразу работает.

Видно это и у других практиков. Торстен Болл точно подметил недооценённую вещь: все обсуждают, как агенты пишут код, а самое сильное у них это дебаг прода. Дай агенту доступ к gcloud и скриншот графика с аномалией, и он пойдёт копать логи так, как у тебя руки никогда не доходят.

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

Что делать: лечить конвейер, а не разгонять станок

В таких замерах обычно ловишь не то, что ожидал. Команды перестают смотреть на AI как на ассистента для кодера и начинают автоматизировать целые куски процесса. Условно: разбор конфликтов и ошибок при обновлении движка раньше делали руками, а теперь под это собирают отдельные AI-пайплайны. Не «помоги человеку быстрее печатать», а «забери у человека целый кусок рутины». Вот тут уже пахнет разами.

У меня лично, кстати, произошло ровно то же смещение. Когда код стал дешёвым, моим узким местом стало совсем другое: поддерживать всё в актуальном состоянии для агента, планировать следующие этапы и расширять это на других ребят, кто с AI пока знаком очень плохо. Я больше не упираюсь в скорость набора кода. Я упираюсь в контекст, планирование и онбординг. Это и есть мой переехавший станок.

Если вы Дамир (или работаете на Дамира), вот с чего я бы начал, прежде чем закладывать иксы в OKR:

  • Найдите своё настоящее узкое место. Не угадывайте его, померьте: где деталь дольше всего лежит в очереди. С большой вероятностью писать код давно не проблема, проблема в ревью, тестах и согласованиях. Ускорять имеет смысл только это, всё остальное Голдратт вам не простит.
  • Перестаньте мерить строками и тасками, начните мерить временем от идеи до прода и долей реворка.
  • Не пускайте поток AI-кода в систему без бюджета на его проверку. У меня это правило выстрадано: удвоили генерацию, удвойте мощность ревью и тестов, иначе вы просто строите Лёше очередь.
  • Вложитесь в скучное: общий контекст для агентов, документацию, онбординг тех, кто пока буксует. Это и станет вашим новым узким местом, лучше прийти туда осознанно.

А Дамиру на том кикоффе я бы сказал одну вещь: давайте сначала поймём, на каком станке копится очередь. Пост про иксы он переслал правильный. Только иксы там были про чужой завод.

1