40% кода пишут AI-агенты? Или 12%? Или 99%?

На недавнем кейноуте OFFZONE прозвучала цифра от «Яндекса» - около 40% агентского кода. Текущий это показатель или цель, не уточнялось.

Если послушать выступления на российских конференциях, становится понятно, что под словом «доля» скрываются разные вещи:

- На конференции ЦИПР от Т-Банка прозвучала цифра: 35-40% кода сейчас пишется с помощью AI.
- В докладе банка Райффайзен показывали эксперименты, в которых агент писал 80-99% кода.
- А в Лаборатории Касперского уже сейчас 12% пул-реквестов (PR) сделаны с AI, 17% подсказок принимаются разработчиками. Цель - 30% кода через три года.

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

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

В Acclaim первое ревью почти везде проводит модель. Для этого из проверенных людьми PR за три-четыре месяца извлекли около трехсот правил, свели их к 66 категориям и распределили между 12 субагентами. Живой человек пока приходит в любом случае: не решено, как определить, «сложный pull request или нет».

Еще одна причина передавать часть приемки модели - масштаб проверки безопасности. Пример от CTO «Лаборатории Касперского»: «У нас 275 миллионов строчек кода. Я нигде не найду столько специалистов по SDL, которые будут проверять мой исходный код на уязвимости». По его словам, модель постоянно проверяет на уязвимости код на поверхности атаки, и каждую неделю в новом коде что-то находится.

Но у машинной приемки есть слабое место: если агент пишет и код, и тесты к нему, критерий перестает быть независимым. Тесты создают впечатление простой проверки: прогнал и убедился. Однако в Acclaim замечают: «модельки любят подстраивать тесты под код», поэтому «все будет зеленое вообще». Зеленые тесты здесь оказываются двусмысленным сигналом. Как и пустой лог в примере, о котором я уже писал: запрет мог не понадобиться, а мог просто не работать.

С похожей проблемой столкнулся еще в Samsung. В 2022 году мы применяли LLM в проекте AI Developer Assistant для генерации юнит-тестов к коду на C/C++. У такого теста можно механически проверить синтаксис, компиляцию и вызов нужной функции. Но всем трем условиям отвечает и тест, который по существу ничего не проверяет. Покрытие показывает, какой код тест затронул, а мутационное тестирование - способен ли он обнаружить ошибку. Четыре года спустя, в 2026-м, Авито описывает тот же класс сбоя: агент может сообщить, что все прошло успешно, хотя «проверку прошли только заглушки». В качестве защиты там используют мутационное тестирование

В Яндекс Банке приемку связывают со скоростью выпуска: «мы не можем себе позволить релизить по 20 релизов в день, пока мы не проверим, что с ними все хорошо».

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

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

Одних ощущений ускорения тоже недостаточно. В пилоте Авито сто инженеров с доступом к топовым моделям сообщали об ускорении, но статистически значимых изменений в объективных метриках разработки не увидели.

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