ИИ напишет за вас код, но никто больше не захочет внимательно его проверить.

Автор: The Pragmatic Engineer

Подготовка: TechFlow

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

Привет, это Герги. Это бесплатный дополнительный выпуск рассылки Pragmatic Engineer Newsletter. В каждом выпуске я освещаю жизнь крупных технологических компаний и стартапов с точки зрения опытных инженеров и руководителей инженерных направлений. Сегодня мы обсудим одну из четырех тем, ранее опубликованных в журнале The Pulse. Полноценным подписчикам эта статья вышла неделю назад. Если вы получили это письмо по пересылке, можете подписаться здесь.

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

Для меня всё началось в январе этого года, когда Opus 4.5 и GPT 5.4 начали генерировать больший объем и более качественный код в большинстве компаний. Примерно тогда же руководители высшего звена стали обсуждать, что узким местом в разработке ПО стал этап ревью, а не написание кода.

Бум инструментов для ИИ-ревью кода

С февраля наблюдается взрывной рост инструментов для ИИ-ревью кода в ответ на увеличение нагрузки. Эксперименты и внедрение специализированных решений, таких как CodeRabbit, Greptile, Qodo, SonarQube (теперь также Gitar), набирают обороты. К этому списку добавляются встроенные функции самих инструментов разработки: Claude Code review, Cursor review, GitHub Copilot review. Кроме того, в эту нишу активно приходят решения, которые ранее не занимались ревью, но обладают контекстом о кодовой базе, например, Seer AI reviews от Sentry и Linear code reviews.

Крупные компании создают внутренние инструменты: Code Inbox от Uber

Крупные корпорации разрабатывают собственные внутренние инструменты для улучшения процесса ревью кода. Яркий пример — Code Inbox от Uber:

Функция интеллектуального распределения внутри Code Inbox используется для оптимизации процесса ревью:

Рис.: Настройка Smart assignment в Code Inbox для ускорения процесса ревью. Источник: The Pragmatic Engineer

Также присутствует функция профилей риска, которая оценивает влияние изменений и призывает разработчиков уделять особое внимание высоким рискам:

Рис.: Функция Risk Profiles в Code Inbox для оценки рисков изменений кода и уведомления о необходимости повышенного внимания. Источник: The Pragmatic Engineer

Мы уже писали о том, как Uber использует ИИ в разработке ПО, но они далеко не единственные: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) и многие другие компании тоже создали собственные инструменты для отладки процессов ревью кода, так как внутренняя разработка показала лучшие результаты по сравнению с интеграцией сторонних решений.

От «ревью» к «верификации»

Альтернативный подход заключается в мышлении о верификации кода, а не только о его ревью. Теоретически сделать это проще, чем реализовать; полностью автоматизированное тестирование должно гарантировать, что код работает ожидаемым образом. Но сколько тестов считается «полным»? О каких именно типах тестов идет речь? Включают ли они интеграционные и end-to-end тесты? Что насчет фаззинга? Формальных методов? Как убедиться, что новые тесты действительно покрывают заявленные функции? Как интегрировать всё это с системами наблюдаемости?

Чрезмерное ревью выматывает инженеров

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

Проблема есть, но решения всё ещё экспериментальные

Проблема реальна, но текущие решения кажутся скорее попытками и экспериментами.