На недавнем кейноуте 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 перепишет”.
Сами по себе эти доли в общем случае несопоставимы. Для каждой цифры полезно уточнить три вещи:
- Что вошло в расчет.
- Это достигнутый показатель или цель.
- Как устроена приемка.
Одних ощущений ускорения тоже недостаточно. В пилоте Авито сто инженеров с доступом к топовым моделям сообщали об ускорении, но статистически значимых изменений в объективных метриках разработки не увидели.
Поэтому цель стоит задавать парой: доля агентского кода и режим его приемки. Иначе процент может вырасти за счет миграций, конфигураций и тестов, где результат формально проще проверить, а там, где ошибка обходится дорого, способ работы может остаться прежним.