Генерація коду за допомогою ШІ викликає затори у перевірці коду, оскільки інженери мають труднощі

Автор: The Pragmatic Engineer

Переклад: Deep潮 TechFlow

Огляд Shenchao: Штучний інтелект все швидше пише код, але перевіряє його все ще людина. Цей протиріччя перетворюється на кризу: інженери затоплені PR, згенерованими ШІ, — або втомлюються від непильного огляду, або просто натискають «схвалити», бо ШІ не виявив помилок. Великі компанії створюють власні інструменти для вирішення цієї проблеми, але поки що ніхто не має стандартного рішення.

Привіт, я Гергелі, це безкоштовний додаток до Pragmatic Engineer Newsletter. У кожному випуску я розповідаю про великі технологічні компанії та стартапи з точки зору досвідчених інженерів та керівників інженерних команд. Сьогодні ми розглядаємо одну з чотирьох тем, опублікованих у минулому випуску The Pulse. Повні підписники отримали цю статтю тиждень тому. Якщо це лист було переслано вам, ви можете підписатися тут.

Я чую, що однією з найважливіших проблем для лідерів інженерних команд є управління постійним зростанням навантаження на код-рев’ю. Ця тема існує вже певний час, і зараз такі дискусії здаються все частішими.

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

З лютого спостерігається вибуховий ріст інструментів AI-ревізії коду для впорання зі зростанням навантаження: експерименти та впровадження спеціалізованих інструментів 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, призначена для прискорення процесу перевірки:

Рисунок: Налаштування розподілу Code Inbox (Smart assignment) для прискорення процесу перевірки. Джерело: The Pragmatic Engineer

Також є функція профілю ризиків для оцінки впливу змін і залучення розробників до особливої уваги до високоризикованих змін:

Рисунок: Функція профілів ризиків Code Inbox, яка оцінює ризики змін у коді та підказує, на чому зосередитися. Джерело: The Pragmatic Engineer

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

Інший підхід — це подумати про те, як перевірити код, а не ревізувати його. Сказати легко, зробити складно; теоретично, повна тестування повинно здати код, що працює так, як очікується. Але скільки тестів вважається «повним»? Про які типи тестів ми говоримо? Чи включаються інтеграційні та енд-ту-енд тести? А фаззинг? А формальні методи? Як перевірити, що нові тести правильно охоплюють функціональність? Як ми пов’язуємо все це зі спостережуваністю?

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

Проблема існує, але рішення здається більше експериментом.