Генерация кода с помощью ИИ вызывает узкие места в код-ревью, так как инженеры испытывают трудности

Автор: The Pragmatic Engineer

Перевод: Shenchao TechFlow

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

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

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

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

С февраля резко возросло использование инструментов AI-ревью кода для справляния с ростом нагрузки: эксперименты и внедрение специализированных инструментов, таких как 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, предназначенная для ускорения процесса проверки:

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

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

Рисунок: Функция профилей рисков (Risk Profiles) Code Inbox, оценивающая риски изменений кода и подсказывающая, на чем сосредоточиться. Источник: The Pragmatic Engineer

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

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

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

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