Привет! Меня зовут Женя, я деврел в Банки.ру. Короче, у нас есть подкаст “про код.ии.прод” и на Хабре в комментариях нам предложили расшифровать выпуски и оформить их в статьи. Мы любим эксперименты — поэтому решили попробовать. Главное, чтоб зашло вам, друзья.

Сам выпуск записан 4 августа 2026 года. И по двум исследованиям, на которые мы ссылались, с тех пор вышли обновления, и цифры там заметно изменились. Мы добавили их прямо по тексту в квадратных скобках, чтобы не переписывать сказанное задним числом.

У микрофонов:
Сережа — руководитель кластера в Банки.ру, 26 лет в IT.
Саша — тимлид в Банки.ру, 11 лет в IT.
Женя — деврел, около IT 2 года.

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

Где ускорение есть, а где оно упирается

Женя: В исследованиях повторяется один паттерн: инженеры субъективно чувствуют рост продуктивности, а end-to-end delivery не ускоряется. Код пишется быстрее, но дальше его надо отревьюить, протестировать, интегрировать, поддерживать. Если эти части процесса не готовы к новому темпу, узкое место просто переезжает из кодинга в ревью. Похоже, мы научились генерировать код быстрее, чем принимать его. Саш, где ИИ дает максимальное ускорение и где оно упирается в процессы?

Саша: Объективно — в рутине. Исследование логов, поиск бага, разбор нового проекта. Найти какую-то функцию, API-метод, понять, есть ли вообще в проекте Swagger. Раньше это занимало до нескольких десятков минут, может, час. Сейчас это один промпт в DeepSeek, и через пару секунд у тебя готовый и вполне хороший ответ.

Но ты правильно сказал: код-то пишется быстрее. А насколько быстрее он потом принимается командой и мержится?

Я перед подкастом почитал исследования, чтобы мы были не такими субъективными. Знаете, что такое name dropping? Сегодня я займусь research dropping. Есть исследование Faros AI 2025 года, они как раз искали узкие горлышки. Кода стали писать гораздо больше и быстрее, но время на ревью выросло чуть ли не в два раза. И техдолг растет пропорционально написанному коду. Есть опасение, что ИИ ускорило работу, но создаст столько техдолга, что в сухом остатке мы станем работать медленнее.

Еще оттуда же: средний размер пулл-реквеста вырос в два с половиной раза. Это если брать примерно одинаковые по описанию фичи.

[Апдейт на момент публикации. Faros AI выпустили новый отчет 2026 года, уже по телеметрии 22 000 разработчиков, и назвали найденное «эффектом отдачи». Время ревью там выросло не на 91%, а на 441%. Багов на разработчика стало больше на 54% против прежних 9%, инцидентов на пулл-реквест на 243%. И самое неприятное: на 31% больше пулл-реквестов мержится вообще без ревью, потому что у ревьюеров просто закончилась пропускная способность.]

И еще наблюдение, уже не помню откуда. Да, ИИшка пишет за нас код быстрее, но быстрее работать мы не стали. Сэкономленное время можно потратить, ну, просто пойти кофе себе заварить. Фича по-прежнему делается целый час, только работать стало легче.

Женя: Надо посмотреть график закупки кофе, кажется, кто-то на этом делает хорошие деньги. Сереж, а почему команды не начинают быстрее поставлять ценность пользователю?

Роботы, которые подняли производительность на 36%

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

В начале книги главный герой Алекс случайно встречает в аэропорту своего преподавателя физики Иону и хвастает, что едет на конференцию представлять свой завод, где внедряют роботов. На одном участке внедрили, и производительность там выросла на тридцать шесть процентов.

А Иона начинает задавать неудобные вопросы. «Вы стали выпускать больше продукции?» Нет. «Сократили персонал?» Нет. «У вас сократились производственные запасы?» Тоже нет, скорее наоборот. «А в чем тогда успех? О чем вы вообще говорите?» И тот задумывается.

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

Я покопал исследование DORA, это команда, которую в свое время выкупил Google, они выпускают State of DevOps Report. И там ровно то, о чем говорил Саша. Индивидуальная производительность выросла, но все сэкономленное время перетекает в техдолг, в ревью и в согласование требований. Плюс вырос процент скопированного кода и сократилась доля рефакторинга.

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

Саша: Тут еще работает парадокс ограничений. Есть U-образная кривая: креативность максимальна не когда ограничений мало и не когда их много, а ровно посередине. Вспомните, как раньше разрабатывали игры, когда у тебя тридцать два килобайта оперативной памяти и ты продумываешь игру так, чтобы она в них уместилась.

Сейчас ИИшка это начальное ограничение убирает, порог входа просто нивелируется. И вот я, бэкенд-инженер, такой: а пойду-ка я фронтендовский дашбордик сделаю. А пойду-ка еще вот это и вот то. Ты начинаешь распыляться.

Одиннадцать процентов

Саша: Нашел исследование Microsoft 2025 года, называется Time Warp. Они опросили четыреста восемьдесят четыре разработчика и смотрели, сколько времени занимает каждый этап. На написание кода уходит одиннадцать процентов рабочего времени. Для сравнения: встречи это примерно двенадцать процентов, отладка девять, проектирование новых систем шесть, ревью пулл-реквестов пять.

И вот с помощью ИИшки мы ускоряем эти одиннадцать процентов.

Представьте конвейер по разливу газировки. Одна бутылка готовится пятьдесят секунд. Один из этапов, наклейка этикетки, занимает пять секунд. Мы его автоматизируем и ускоряем до одной секунды. И что получилось? Пятьдесят секунд превратились в сорок шесть. Какое там ускорение delivery одной бутылки?

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

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

Вот смотрите. Есть метрика WIP (Work In Progress) — время, когда задача непосредственно в работе: в разработке, в ревью, в тестировании. На средней команде она где-то в районе пяти-пятнадцати процентов. Остальные восемьдесят пять или девяносто пять процентов задача просто лежит в очереди.

И когда ты ускоряешь работу над задачей, ты ускоряешь только вот этот in progress. Как Саша сказал, одиннадцать процентов, а то и меньше. Ты получаешь там рост процентов на двадцать-тридцать. Но итоговый рост даже в самой зрелой команде выходит не больше 7-8 процентов. Больше вы не получите никак. Если вам обещают больше, это маркетинг.

Саша: Вас хотят обмануть.

Почему нам кажется, что мы едем быстрее

Саша: На эту тему есть очень показательное исследование от METR, тоже 2025 года. Они взяли 16 разработчиков, которые занимаются опенсорсом, и дали им 246 реальных задач в репозиториях, которые эти разработчики хорошо знают. Спрашивали, как по ощущениям ИИ повлиял на работу, а потом замеряли фактический результат.

Разница получилась интересная. До эксперимента разработчики ожидали, что ускорятся на 24%. После эксперимента говорили: по ощущениям я разрабатываю процентов на 20 быстрее. А фактический результат показал, что они разрабатывают на 19% медленнее.

[Апдейт на момент публикации. METR с тех пор пометили этот результат как исторический: он получен на инструментах начала 2025 года и не описывает то, что происходит сейчас. Более позднее наблюдение показало у них уже признаки ускорения.]

Это как раз про то, как мы субъективно все воспринимаем. Хорошая цитата мне попалась на эту тему: мы запоминаем джекпоты, а не то, сколько монеток забросили в автомат. Мы не запоминаем процесс, пока пишем промпты, правим их, меняем. Мы запоминаем только тот минутный выигрыш, когда она за пять минут сгенерировала крутой код. А что мы потом целый час заставляли ее написать хороший код, мы не вспоминаем.

Сережа: Встречалась оценка, что примерно 66% времени разработчик тратит на корректировку результата ИИ, который вроде и дал желаемое, но чуть-чуть не то. Вроде бы она быстро выдала первый результат, а потом ты его корректируешь еще примерно столько же времени.

Саша: Вот и думайте, ускоряет ИИшка работу или нет. Пока она как будто нас обманывает, заставляет думать, что ускоряет. По факту мы больше сидим и с ней разговариваем, чтобы она правильно все сделала.

Кстати, раньше топ-перформера можно было отличить по тому, как быстро он пишет код. Сейчас эта штука просто уходит: и тот, и другой пишет код быстро. Мне кажется, на первое место выйдет другая характеристика: понимать, какой код написала ИИшка, и апрувить его. Ты будешь не весь код в репозиторий пушить, а смотреть: написала хорошо, запушим. Написала фигню, переделываем.

Сережа: Это как раз то, о чем мы говорили в прошлом выпуске. Инженерные практики выйдут на первое место.

Когда эксперименты становятся workflow

Женя: Промпт это все-таки ручной режим. Но когда ИИ становится частью пайплайна, все обрастает слоями абстракций: скиллы, агенты, оркестраторы. И вопрос уже не в том, как написать хороший промпт, а как построить процесс, где ИИ получает задачу, контекст, ограничения и отдает проверяемый результат. Саш, где заканчиваются эксперименты и начинается настоящий workflow?

Саша: Когда ты все это объединяешь в один workflow. Пока ты каждый этап пытаешься оптимизировать по отдельности, это все считается экспериментом.

Кстати, про описание задач. Когда мы только начали внедрять ИИшку, я видел некоторые описания в Jira. Это были просто огромные портянки технического текста. Заходишь в такую задачу и понимаешь: а кто ее делать-то будет? Сейчас в этом плане уже гораздо лучше.

Так вот, когда мы объединим разрозненные этапы в один flow, там все равно будут гейты, апрувы пользователя. Можно сделать полностью закрытый цикл, но это приведет ровно к тому, что мы уже обсудили: будем генерить огромное количество техдолга. Да, фичи будут закрываться, баги будут правиться. Но кто потом этот техдолг будет убирать?

Если брать методологию discovery и delivery — то сейчас мы по сути в discovery. У нас появился новый инструмент, мы учимся с ним работать. Научились писать крутые промпты, научились анализировать фичу, научили ИИшку правильно, вот ключевое слово, правильно разрабатывать фичу именно в твоем проекте. Это часть пути. А вот когда ты замыкаешь цикл, и она уже сама делает это поэтапно, сама передает другому агенту, тот третьему, вот это уже workflow по агентской разработке.

Женя: Ты сказал про портянки в задачах. Они плохо работают для людей, но ведь для ИИ, кажется, наоборот хорошо? Если одна модель составит портянку, а другая ее прочитает, то ТЗ, кажется, получается полнее.

Саша: По наблюдениям, которыми ребята делятся на форумах, даже ИИшки не любят огромные текстовые файлы. Они читают начало и конец, а середину теряют и из-за этого начинают глючить. Поэтому все советуют писать agents.md через ссылки, через референсы. Нужна авторизация, иди вот этот md-файл почитай, и там буквально до сотни строк. То есть ИИшка читает не всю портянку в полторы тысячи строк, а идет по ссылкам. Так что подробное “портяночное” описание задачи это не всегда хорошо даже для ИИ.

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

Война не моделей, а подходов

Женя: А когда все эти workflow станут частью внутренних платформ разработки?

Сережа: Сейчас очень интересный период, и я опять зайду через книгу. Есть одна из моих любимых по бизнесу, «Воля и видение» Джерарда Теллиса и Питера Голдера. Они показали, что лидерами рынка очень часто становятся не пионеры этого рынка. До этого считалось наоборот: кто первый, тот и захватывает. Вообще нет. И если полвека назад разрыв от пионера до лидера был лет десять, то сейчас он стремительно сокращается.

Мой любимый пример оттуда это война видеоформатов: VHS от JVC против Betamax от Sony. У Betamax качество картинки было гораздо лучше. А JVC двадцать лет разрабатывали свой формат. И в итоге победили, хотя качество было хуже. Почему? Потому что видели рынок и понимали, что пользователю важнее, чтобы на кассету помещался фильм целиком.

На рынке ИИ происходит то же самое. GitHub Copilot был пионером, гремел везде, встраивался в IDE. Потом Cursor отъел много рынка. Claude появился совсем недавно и тоже отъел значимую долю. И каждый сделал ставку на свой подход: Copilot на встраивание в IDE, Cursor стал экосистемой вокруг VS Code, Claude делает ставку на консоль и фоновое выполнение задач.

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

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

Время терять нельзя, надо пробовать. Но всегда есть опасность свернуть не туда, потратить кучу денег и остаться ни с чем. Из российских примеров: Rambler появился гораздо раньше Яндекса. Ну и где Rambler, и где Яндекс сейчас?

Метрики тщеславия

Женя: Кажется, нельзя мерить успех количеством сгенерированного кода или числом пулл-реквестов. Мне понравилось выражение «метрики тщеславия». Кстати, один наш коллега сегодня написал в чатике, что end-to-end скорость особо не выросла, а количество задач за спринт увеличилось.

Саша: Да, velocity спринта выросло, а delivery не поменялся. Это опять же про то, что мы ускорили те самые 11%.

Женя: Сереж, а на какие метрики ты бы смотрел?

Сережа: Я бы разделил их на две части, и индустрия это тоже предлагает.

Первое это диагностические метрики: сколько денег тратим, сколько решенных задач с помощью ИИ, сколько кода генерируем. Они показывают, что мы его используем в каком-то объеме.

Второе это метрики результата. Тут уже все придумано до нас, той же DORA. Четыре ключевые метрики: частота релизов, время от коммита до фичи на проде, доля неудачных релизов и время восстановления.

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

А вот метрику «время от коммита до релиза» я бы переопределил. Коммит сейчас как раз ускоряется, его ИИ и делает быстрым. Я бы смотрел от поступления требований до релиза. Я делал такое исследование на своем кластере: очень много задач простаивает. То, что у Голдратта называется незавершенным производством. Оно замусоривает трубу, и вот с этим надо что-то делать.

Частоту релизов тоже можно мерить, но обязательно в паре с долей неудачных. И туда же добавить количество исправлений после релиза на какой-то дистанции, скажем, двухнедельной. Мне важно увидеть размен: если я ускоряюсь в количестве релизов, то где я теряю?

И еще про агентские пайплайны. Тут надо быть осторожным, потому что можно создать пайплайн, который с большой скоростью генерирует техдолг. Как поступать? Ты нашел измерениями узкое горлышко. Ага, на ревью постоянно лежит двадцать пять задач, и ты понимаешь: какая бы задача в эту очередь ни встала, она поедет на прод только через пять дней. Раньше никак. Вот оно, твое горлышко.

Дальше применять новшества на уровне всего кластера расточительно. Можно выделить часть команды и поставить эксперимент. Например, внедрить агента, который делает предревью. Или решить, что ИИ должна делать более атомарные коммиты, чтобы ревьюить было легче. Удачный эксперимент потом распространяем на остальных.

Не станет ли узким горлышком сам инженер

Женя: А вот когнитивная нагрузка на инженеров не может ли стать узким горлышком?

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

И когнитивная нагрузка растет как раз у топ-перформеров, потому что они понимают: у меня время освободилось, я могу потратить его еще на одну задачу, и еще на одну. Постоянное переключение контекста. Вот это и бьет по менталке.

А для тех, кто посередине, наоборот, создались более комфортные условия. То, над чем я раньше сидел час, теперь делает ИИшка.

Но сейчас произошел перекос: бизнес ожидает ускорения, те самые иксы, а по факту люди вряд ли будут делать по три задачи за освободившийся час. Ожидать, что с ИИшкой люди станут работать втрое быстрее, кажется, это розовые очки. Им просто станет комфортнее, ИИшка заберет рутину: логи, дебаг, boilerplate.

Тут еще про деньги хочется сказать. Компании потратили на ИИ огромные суммы. А потом появляются исследования, которые меряют не скорость разработки, а прирост ценности для бизнеса. И это разные метрики. Ты работаешь быстрее, а насколько ты ценен? Ты сделал десять дашбордов, а для бизнеса это один процент ценности.

И там начинается самое интересное: у большинства компаний ценность или не выросла, или выросла минимально. Был даже мем: чтобы продать фичу, просто добавь, что она использует ИИ, и бизнес активно одобрял бюджеты — а цифры говорят другое. И еще мем оттуда же: финансовый директор смотрит на отчеты и идет к CTO обсуждать, что вы потратили столько денег, а где ценность-то?

Ведь это банально. Есть разработчик, у которого есть оклад. Прибавь к окладу, сколько ты тратишь на его подписки. Разработчик стал дороже стоить. А стал ли он больше ценности приносить? Непонятно.

Сережа: Мы сейчас как-то пессимистично звучим. Скажу так: делать надо, быстро, но осторожно. Сейчас можно упустить момент, все в это так или иначе идут.

На заре развития интернета одна торговая компания решила полностью уйти в онлайн: все, теперь миром торговли будет править интернет. Они в это поверили, но рынку тогда это было не нужно, даже устройств с интернетом не было в таком количестве. А сейчас что мы видим? Торговля ушла в интернет. Просто та компания поторопилась лет на пятьдесят.

Технология прорывная, она так или иначе даст плоды. Сейчас идет интересное время поиска, где эти плоды будут наиболее ощутимыми.

Саша: Поддержу, идти в это надо. Хоть сегодняшний разговор и звучит как предостережение, что не все так прекрасно. Но мы свои шишки набили, получили опыт и экспертизу. С внедрением агентского flow мы уже подготовили базу. И как бы дальше ИИшка ни развивалась, у нас есть эта база.

Что в сухом остатке

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

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

Исследования, которые упоминались

• Faros AI, AI Engineering Report 2025. Телеметрия 10 000 разработчиков из 1255 команд: на 21% больше выполненных задач и на 98% больше смерженных пулл-реквестов, при этом время ревью выросло на 91%, размер пулл-реквеста на 154%, а метрики DORA на уровне организации не сдвинулись.

• Faros AI, отчет 2026 года. Телеметрия уже 22 000 разработчиков из более чем 4000 команд: время ревью +441%, багов на разработчика +54%, инцидентов на пулл-реквест +243%, на 31% больше пулл-реквестов мержится без ревью.

• DORA, State of AI-assisted Software Development 2025 (Google). Опрос почти 5000 специалистов. Главный вывод: ИИ это усилитель, он усиливает и сильные, и слабые стороны команды. Связь ИИ с пропускной способностью впервые стала положительной, а связь с нестабильностью поставки осталась.

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 16 разработчиков, 246 реальных задач: ожидали ускорения на 24%, по ощущениям получили 20%, фактически замедлились на 19%. Сами авторы сейчас помечают результат как исторический.

• Microsoft Research, Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era. Опрос 484 разработчиков: на написание кода уходит около 11% рабочего времени.

• Элияху Голдратт — «Цель. Процесс непрерывного совершенствования».

• Джерард Теллис, Питер Голдер — «Воля и видение. Как те, кто приходит позже остальных, в итоге заправляют рынками».