AI ускорил разработку: как понять, что это правда

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

Ощущение ускорения ничего не доказывает

Самое нашумевшее исследование 2025 года – METR. Опытным разработчикам дали AI-инструменты в их же репозиториях, и до начала они ждали, что задачи станут занимать на четверть меньше времени. После работы оценили ускорение чуть скромнее. А по факту они замедлились примерно на пятую часть, и часть моих коллег потом носила это исследование в формате «смотрите, AI замедляет».

Вопросов к нему много, там всего 16 разработчиков и 240 с чем-то задачек. Но мораль в том, что ощущения требуют измерений. Нужна методология, которая проверит, что ощущения вас не обманывают. В 2026-м METR повторили исследование и намерили уже прирост

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

В октябре Anthropic рассказали, как у них поменялась работа, и цифры там волшебные. Коммитов на инженера за полгода стало в 5 раз больше, а времени агентов тратится в 19 раз больше, чем времени инженеров. Причем это не фоновые агенты, их запускают сами люди. Кратно ускорились не только инженеры, но и юристы, менеджеры, продавцы. Не везде одинаково, но то, что агенты во второй половине 2026 года меняют темп, это точно

Только каждый результат относится к своим условиям. METR – полевой эксперимент, где инженерам купили Cursor и сказали «идите», хотя пользоваться им они не умели. Microsoft мерили слитые PR. Anthropic смотрят на всю компанию, и это самое интересное, потому что там можно брать коммиты, PR или целевые задачи, которые тебя волнуют.

Сначала выбираем границу измерения

Если повезло и компания умеет объединять discovery и delivery, можно мерить всю компанию: процессы перестраиваются целиком, и в них участвуют продакты, дизайнеры и все остальные. Бывает, что говорят: «Нет, дорогой друг, discovery – это бизнес и продакты, артистичные персоны с суперидеями. Давай ты займешься кодом». Тогда меряешь delivery. Ну и третий случай локальный, когда ты отвечаешь за одну инициативу вроде AI-ревью, миграций или вайбкодинга для продактов

Discovery + delivery: от гипотезы до клиента

Лучший вариант – когда у тебя есть полномочия, а у бизнеса желание меняться. Тогда весь путь меряется end-to-end, от гипотезы до изменения у клиента. На всю компанию так обычно не выходит, но почти всегда есть домен с командами, готовыми меняться.

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

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

А когда масштабируется, получается история про продуктовых инженеров, которые забирают проблему и сами доводят ее до конца. Правда непонятно, куда деваются аналитики, QA и разработчики разных видов. Команда становится маленькой и фулстечной, и у нее уменьшается число передач между ролями и время ожидания на них. Это прямо можно померить. Скорее всего, у такой мотивированной команды все метрики будут красивыми. Проблема в том, что таких команд немного. Про продуктовых инженеров и tiny teams сейчас много рассказывают, по крайней мере в России, но когда это дойдет до внедрения, непонятно.

Delivery: использование, влияние, затраты

Второй уровень – когда тебе говорят: бизнес оставим бизнесу, а IT пусть отвечает за свои метрики. Тут удобно опереться на DX. Эту платформу запустили в 2020 году ребята, которые придумали DORA-метрики и написали книжку Accelerate. В 2025-м ее купил Atlassian за миллиард долларов со словами, что у них самих система оценки developer productivity не получилась.

Фреймворк DX смотрит на три вещи. Использование – охват лицензиями, коммиты и PR с агентами, и это чем-то похоже на старую метрику lines of code. Дальше влияние: экономия времени, поток, качество, developer experience. И затраты с окупаемостью. В Т мы примерно так и пытались мерить. Спойлер: первые две части еще как-то меряются, напрямую или косвенно, а с третьей у нас не очень получалось

У процента внедрения должен быть знаменатель

Использование нельзя оценивать в вакууме: кто пользуется, в каком контексте, как часто и в каком режиме. В процентах важен знаменатель. Людей с AI делим не на всех, а на тех, у кого был доступ, потому что нормальные лицензии выданы не всем. Задачи с AI считаем от задач, которые подходят под критерии

Режимы тоже разделяем. Человек может работать с агентом интерактивно, как с ассистентом, а может полностью делегировать задачу в пайплайн по расписанию или триггеру, где его вообще нет. И отдельно смотрим параллельность. Человек часто запускает кучу агентов, поэтому его время надо уметь отделять от времени, которое агенты работают в фоне. У Anthropic агентского времени стало в 19 раз больше, чем инженерного. Прочитать, что наделали агенты и сабагенты одного инженера, в принципе невозможно, и ревью таких изменений – большой вопросик.

Событие инструмента еще не результат

Мне импонирует подход Google: снимаете телеметрию с разных инструментов, логи превращаете в события, события собираете в сессии с привязанными артефактами и по ним считаете метрики. Допустим, вы хотите понять, насколько агент ускоряет. Когда человек начал задачу, вы не знаете, поэтому нужен пайплайн, который привяжет артефакт первой сессии к задаче. У нас полноценного пайплайна не было, и этап до попадания кода в систему контроля версий мы часто не могли померить. А это съедало часть сути метрики вроде «насколько быстрее ты мержишь PR с инструментами».

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

Задачи застревают на ревью и согласованиях

Код у нас действительно стали производить быстрее, а end-to-end метрики потока особо не росли. Как и у всех, задачи начали застревать на ревью, согласованиях и проверках. Если мерить на выпуске, то токены сожжены, все роли на всех этапах показывают рост метрик активности, а для бизнеса изменений особо нет. Когда изменения все-таки есть, заглядываешь внутрь и видишь команды, которые поменяли подход к работе и объединили discovery с delivery

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

Причем инструменты меняют и сам процесс, и измерение. METR хотели в 2026-м повторить исследование, и это оказалось сложно. Часть участников уже отказывалась работать без AI, часть задач не хотели включать в эксперимент, а параллельная работа агентов мешала подвести итоги. Эксперимент февраля 2026-го скорее про то, что скорость с новыми агентами все-таки растет, но интерпретировать это сложно. Ну и во многих экспериментах участников назначают не случайно, настоящей контрольной группы нет, так что чистого причинного вывода не получается.

Экономика конкретной инициативы

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

AI-ревью

Бот проверяет PR и оставляет замечания, автор разбирает сигнал и исправляет, ревьюер смотрит на риск и остаток работы, и все это мержится. Хочется понять, есть ли польза от находок и сходится ли экономика, когда к труду разработчиков добавляются агенты. И пропускаем ли мы меньше дефектов в прод

Мысленный эксперимент: есть 100 пулреквестов, ставка инженера $60 в час, и при текущих правилах он разбирает их за 8 часов, плюс расходы на AI. Вы меняете правила, человек работает меньше, AI тоже тратится меньше, и эту экономию можно записать себе. Впрямую так посчитать удается редко. Когда мы внедряли AI-ревью, ребята показывали много красивых метрик, но до экономики не дошли и остановились на том, сколько стоило бы то же ревью людьми. Ну и ревьюить ли конкретный PR – вопрос риска, так что настраивать ревью стоит по риску пулреквеста.

Миграции

С миграциями все проще, отсылка тут к статье Google «Migrating Code at Scale». Переезд на новую версию библиотеки или языка, а иногда и на другой язык, например со Scala на Java или Kotlin. Вы примерно знаете, сколько инженерных часов это стоит, и можете посчитать подготовку, правила, ревью и работу агента. Если типовых миграций много, на какой-то пятой, шестой, седьмой все отобьется. Сканируете все репозитории, находите, сколько мест надо мигрировать, и говорите: окей, безубыточность наступает тут, а у нас этого добра бесконечно

Ловушка в том, что успех легко записать себе, когда сделано, например, 95% изменений. А миграция закончилась, только когда старое погашено и не осталось хвостов, из-за которых держат старые системы. Плюс проблемы часто всплывают уже на проде. Помните, как Anthropic переписывали Bun с Zig на Rust: все тесты зеленые, а регресс, не покрытый тестами, все равно нашли на продакшене. У вас, скорее всего, будет так же, причем тестов на поведение приложения у вас сильно меньше, чем у Bun. Часть хвоста придется закрывать руками инженеров, и это тоже надо считать. Иначе миграция выглядит как суперкейс, где AI рулит и экономит безумные деньги.

Прототипы

Последний кейс – вайбкодинг, когда продакты сами делают прототипы с AI, проверяют гипотезы без нас и хотят катнуть их на пользователей. Обычно считают стоимость проверки гипотезы: время, затраты и получилось ли катнуть. И забывают, что для выкатки реального прототипа нужна нехилая работа платформенной команды. Она должна сделать прототипы достаточно production-ready, чтобы их можно было катнуть хотя бы в webview внутри мобильного приложения и ничего не развалилось

Многие крупные компании делают себе внутренний аля Lovable для продактов, которые говорят: «Вот если бы мы могли быстрее катить изменения, точно заработали бы миллиарды». Обычно так не бывает. А если прототип выстрелил, его еще надо передать в delivery и превратить в рабочее решение

Сэкономленные часы еще не деньги

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

Не всем есть что делать больше

Часто говорят, что мы сможем делать в 10 раз больше задач. Может, и сможем. Но тогда мы упираемся в убывающую полезность, и в 10 раз больше результата, скорее всего, не будет. Если теми же силами работать над тем же бэклогом, кривая закругляется, и условно в 10 раз больше фичей дадут в 2 раза больше бизнес-эффекта. Это объективная реальность.

Если не сращивать discovery с delivery, а просто быстрее разгребать бэклог, вы начинаете пилить все менее важные задачи, которые там висели и тухли. Делаете их быстрее, но бизнес-эффекта они не дадут. Мне кажется, рассказы про «делегируем работу агентам и будем делать больше» забывают, что не у всех компаний есть что делать больше. Иногда продукт просто не требует бесконечных доработок

Если у вас сто инженеров

Количественные показатели со статзначимостью работают на масштабе Google или Т-Банка. Если у вас условно 100 инженеров, заморачиваться со статзначимостью, наверное, не стоит. Зато вы можете в принципе обозревать, что происходит. Разбейте задачи на кластеры: интеграции с партнерами, фронт, ваш внутренний движок. И внутри каждого класса смотрите, что происходит с задачами.

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

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

AI усиливает то, что у вас уже есть

Часто пророчат, что с агентами качество кода упадет. В одном из отчетов DORA была мысль, что AI работает как усилитель текущих процессов. Если ты был крутым инженером и выстроил процессы, ты смотришь на инструменты и говоришь: «Отлично, я никогда не мог писать столько тестов». Раньше тебе говорили, что тесты – это дорого, давай побыстрее. Ты хотел фитнес-функции на архитектуру, но они постоянно ломались, и разобраться в них мог только какой-то высоколобый чувак. С агентами ты приходишь, говоришь «хочу по красоте» на языке этого домена, и агент отвечает: давай сделаем это, то, пятое, десятое.

А теперь представь команду, которая никогда не занималась тестами и всех этих умных слов не знает. Она говорит: «Агент, катани мне фичу». И агент катит и вторую, и третью, и пятую, и получается месиво. Сделать инженерные практики красиво агент вполне может. Но ты должен знать, что они существуют, уметь сказать нужные слова и смотреть, идет ли агент в ту сторону. Иначе в какой-то момент зовешь специалиста: «Чувак, теперь я не фичи пилю, а только баги правлю». Как с Lovable, когда на трехсотой итерации просишь сложную фичу, вокруг все отваливается, и дальше «а теперь почини 10 багов».

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

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

Остальное на polomodov.tech и в канале Книжный куб