ИИ теперь пишет 42% кода в компаниях, но 96% разработчиков ему не доверяют

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

Опрос стартапа Sonar, разрабатывающего инструменты проверки ИИ-кода, охватил более 1100 разработчиков. По их оценке, ИИ обеспечивает 42% кода, добавляемого в общие кодовые базы. При этом, хотя ИИ полезен для объяснения и прототипирования кода, 96% опрошенных не доверяют полностью тому, что его код будет работать правильно. 38% сказали, что проверка ИИ-кода требует больше усилий, чем проверка кода коллег, а 61% отметили, что ИИ часто выдаёт код, который выглядит правильным, но оказывается «ненадёжным».

Инвесторы видят в этом разрыве возможность: в августе стартап CodeRabbit, специализирующийся на ИИ-ревью кода, привлёк 143 миллиона долларов при оценке в 1,5 миллиарда долларов, заявляя, что выполняет более 2 миллионов проверок в неделю для 17 000 клиентов, включая Nvidia, Indeed и BMW Group.

В Synthesia, платформе для генерации видео с помощью ИИ, ревью кода стало ключевым звеном инженерного процесса. По словам технического директора компании Питера Хилла, в ноябре 2025 года все 118 инженеров Synthesia перешли на ИИ-инструменты для программирования вроде Claude Code, и объём кода резко вырос. По состоянию на август число пул-реквестов (предложений изменений в кодовую базу) выросло на 120% в годовом исчислении, при этом 95% из них содержат код, написанный ИИ. Постоянная проблема, дублирование: ИИ-инструменты не всегда видят, что нужный код уже существует в проекте, из-за ограниченного контекста, и пишут его заново. Synthesia находила до 10 версий одной и той же функции: инженерам приходится находить и удалять лишние, а затем переобучать агента, чтобы ошибка не повторялась. Агенты сами определяют, какие изменения требуют более пристального человеческого внимания: правка текста ошибки менее рискованна, чем код, работающий с данными клиентов или бизнес-логикой. Даже так меньше 5% изменений в Synthesia обходятся без ревью человеком. «Я не знаю, наступит ли когда-нибудь момент, когда генерации кода ИИ-агентами можно будет полностью доверять», говорит Хилл.

В Amazon Stores пытаются предотвращать проблемы ревью ещё до того, как ИИ напишет первую строку. Старший главный инженер Маклейн Стэнли использует ИИ, чтобы модернизировать 17-летний код мобильного приложения Amazon для покупок; его команда из 70 человек поддерживает инфраструктуру для более чем 1000 разработчиков. Основная работа теперь, писать подробную спецификацию того, что и как должен построить агент, ещё до генерации. Стэнли вспоминает случай: из-за отсутствовавшей инструкции агент сгенерировал 25 000 строк на неверной версии языка Swift, а переключение версии дало 600 ошибок, которые агент не смог исправить разом. Стэнли отбросил код, обновил спецификацию и перезапустил агента, через пятнадцать минут код был сгенерирован уже правильно.

Когда код уже написан, первый круг проверок берут на себя специализированные агенты. По словам Дэвида Янасека, старшего главного инженера Amazon Web Services, компания использует агентов, чтобы тестировать работоспособность кода, сверять его с исходным планом и искать уязвимости ещё до того, как за дело возьмётся человек. Похожая логика, в Bonterra, поставщике ПО для некоммерческого сектора с примерно 290 инженерами: по словам технического директора Тануджи Корлепры, за три месяца после внедрения ИИ число предлагаемых изменений утроилось, объём кода, поступающего на ревью, вырос в десять раз, а время проверки утроилось, просматривать каждую строку стало нереально. Агенты Bonterra сверяют код с утверждённым дизайном, правилами безопасности, стандартами кодирования и требованиями доступности, затем сообщают степень уверенности в результате; низкая оценка или найденная проблема отправляют изменение человеку. Код, касающийся платежей, персональных данных и других чувствительных систем, всегда проходит ревью человеком. «Агенты читают, а люди судят», говорит Корлепра.

Когда машины выдают больше кода, чем инженеры способны внимательно прочитать, одобрение человека рискует превратиться в «показное одобрение» (theater approval), так это называет Джей Ди Раймонди, главный ИИ-архитектор консалтинговой компании Making Sense: инженер может убедиться, что функция работает, бегло просмотреть код и одобрить его, не разбираясь по-настоящему в заложенных решениях. В компании Temporal, разработчике открытой платформы для распределённых приложений, ответственность возвращают тому, кто подаёт код на ревью. По словам генерального директора Самара Аббаса, объём кода и время ревью выросли вместе с внедрением ИИ. По принятой в Temporal политике «Send Back» инженер обязан своими словами объяснить архитектурные решения агента и то, как код обрабатывает нештатные ситуации, иначе ревьюер отклоняет изменение. «Мы отказываемся превращать ревью кода в свалку непроверенного вывода моделей», говорит Аббас.

По мере того как ИИ смещает работу инженеров от написания кода к его оценке, компании пересматривают, как набираются опыта junior-специалисты. В Making Sense именно junior-инженеры получили наибольший прирост продуктивности от ИИ, что заставляет задуматься, чему они перестают учиться на практике; компания сознательно оставляет за junior-специалистами решения о том, зачем клиенту нужна функция и как она должна работать, а не сводит их роль к проверке вывода ИИ. В IBM, напротив, новых инженеров сразу нагружают более сложными задачами: по словам генерального менеджера по автоматизации и ИИ Нила Сундаресана, недавние выпускники теперь работают над функциями и проектами, которые раньше доверяли только старшим инженерам, ИИ помогает реализовать и протестировать код, а если что-то ломается, junior-специалисты разбираются и чинят проблему до финального одобрения старшим разработчиком. По оценке Сундаресана, ИИ позволяет junior-инженерам выполнять 70, 80% некоторых задач, которые раньше требовали senior-уровня. Synthesia в основном нанимает специалистов среднего и старшего уровня; менее опытные сотрудники работают в паре со старшим коллегой и ИИ-агентом, отвечая за часть проекта и одновременно учась определять, каким должен быть правильный код. В Bonterra агенты теперь выполняют многие из чётко определённых задач, на которых раньше учились новые инженеры; вместо этого junior-специалисты вместе с опытными коллегами отвечают за результат целиком, учатся направлять агентов, подвергать сомнению их вывод и нести ответственность за итог. «Если индустрия перестанет нанимать junior-специалистов, она перестанет производить senior-специалистов», говорит Корлепра.

Ключевые факты

Опрос стартапа Sonar среди более чем 1100 разработчиков: по их оценке, ИИ обеспечивает 42% кода в общих кодовых базах, но 96% не доверяют полностью его результату; 38% говорят, что ревью ИИ-кода требует больше усилий, 61%, что такой код часто выглядит верным, но ненадёжен.
Стартап CodeRabbit в августе привлёк $143 млн при оценке $1,5 млрд, заявляя о более чем 2 млн проверок кода в неделю для 17 000 клиентов, включая Nvidia, Indeed и BMW Group.
В Synthesia (118 инженеров, все на ИИ-инструментах вроде Claude Code с ноября 2025) число пул-реквестов выросло на 120% за год, 95% из них содержат ИИ-код; найдено до 10 дублирующих версий одной функции; менее 5% изменений обходятся без ревью человеком.
В Amazon Stores инженер Маклейн Стэнли из-за пропущенной инструкции в спецификации получил 25 000 строк кода на неверной версии Swift и 600 неисправимых ошибок; после исправления спецификации агент выдал корректный код за 15 минут.
В Bonterra (~290 инженеров) за три месяца внедрения ИИ число предлагаемых изменений утроилось, объём кода на ревью вырос в 10 раз, время проверки утроилось; в IBM junior-инженерам с помощью ИИ теперь доверяют 70, 80% задач, ранее требовавших уровня senior.

Почему это важно

ИИ-инструменты пишут код быстрее, чем инженеры успевают его проверять, и это смещает узкое место разработки с написания кода на его ревью. Скрытые в ИИ-коде дефекты, ошибочные допущения, уязвимости, дублирование логики, способны свести на нет весь выигрыш в скорости, если их приходится дорого исправлять постфактум. Поэтому крупные компании, Synthesia, Amazon, Bonterra, Temporal, IBM, не просто добавляют ИИ в разработку, а перестраивают сам процесс ревью вокруг того факта, что большая часть кода теперь пишется не человеком.

Кому это важно

В первую очередь техническим руководителям и инженерным командам, которые уже увеличивают долю ИИ-кода и упираются в пропускную способность ревью, как Bonterra с десятикратным ростом объёма проверок или Synthesia со 120-процентным ростом числа пул-реквестов. Материал важен и для стартапов вроде CodeRabbit и Sonar, строящих бизнес на автоматизации проверки ИИ-кода, а также для junior-инженеров и тех, кто отвечает за их обучение: там, где ИИ берёт на себя рутинное написание кода, меняется сам путь входа в профессию.

Как это применить

В статье описаны несколько работающих схем: писать подробную спецификацию для агента до генерации кода, чтобы предотвращать типовые ошибки заранее (подход Amazon Stores); ставить специализированных агентов на первый круг проверки, тесты, сверку с планом, поиск уязвимостей (AWS), с оценкой уверенности и автоматической эскалацией к человеку при низком балле или чувствительных данных (Bonterra); маршрутизировать ревью по риску, оставляя человеку только рискованные изменения (Synthesia, где обходятся без ревью менее 5% правок); и требовать от разработчика лично объяснять решения агента перед ревьюером, чтобы ответственность не размывалась (политика «Send Back» в Temporal).

Можно ли доверять

Материал IEEE Spectrum строится на именных интервью с техническими руководителями и старшими инженерами конкретных компаний (Synthesia, Amazon Stores, AWS, Bonterra, Temporal, Making Sense, IBM), что придаёт ему вес. При этом часть цифр, самооценка заинтересованных сторон: данные о 42% ИИ-кода и уровне недоверия к нему получены из опроса Sonar, стартапа, который сам зарабатывает на проверке ИИ-кода, а цифры о 2 млн проверок в неделю и 17 000 клиентах CodeRabbit, это заявления самой компании на фоне привлечения инвестиций, без независимой проверки.

Риски и подводные камни

Главный риск описан прямо в тексте: при огромном объёме ИИ-кода одобрение ревьюера рискует стать «показным», человек убеждается, что функция работает, бегло смотрит код и подписывает его, не понимая заложенных решений, а ответственность за результат при этом всё равно остаётся на человеке. Отдельная проблема, обучение: если junior-инженеры перестают сами писать код, непонятно, как они научатся его оценивать; компании решают это по-разному, от сохранения за junior-специалистами содержательных решений (Making Sense) до немедленной нагрузки более сложными задачами под присмотром (IBM, Bonterra). Технический директор Synthesia прямо признаёт, что не уверен, наступит ли момент полного доверия к генерации кода агентами.

«Я не знаю, наступит ли когда-нибудь момент, когда генерации кода ИИ-агентами можно будет полностью доверять.»

— Питер Хилл, технический директор Synthesia