Як Aviator перевіряє у 4 рази більше AI-коду, не читаючи кожен рядок

Aviator каже, що ті самі дев'ять інженерів об'єднали в 4 рази більше запитів на злиття після того, як змінили код-рев'ю з читання сирих дифів на перевірку наміру, критеріїв приймання, інваріантів, рішень і конкретних доказів. Медіанний час до злиття впав з 2,1 дня до 3,4 години, відкати зменшилися на 40%, і людина досі підписує кожен запит на злиття.

Проблема: код-рев'ю не масштабується з AI

Код команди змінився з написаного людьми за допомогою AI на згенерований AI за допомогою людини. Щотижневі об'єднані запити на злиття зросли з приблизно 100 до понад 400, а медіанний згенерований AI запит на злиття досяг 640 рядків, що більше за 400 рядків, які широко вважають межею, після якої виявлення помилок знижується.

Виявлення помилок ніколи не було головною метою код-рев'ю. У дослідженні Microsoft 2013 року авторів Bacchelli і Bird лише 14% коментарів до рев'ю стосувалися дефектів. Рев'ю є тим, як інженери діляться знаннями та підтримують актуальну ментальну модель системи, і саме це варто захищати. Коли агенти пишуть більшість коду, саме ця частина найбільше під загрозою. На запитання, чи просто припинили рев'ю, команда відповідає: ні, вони припинили рев'ю дифа. Їхній висновок: рішення потребують людини, а диф є найгіршим місцем для їх ухвалення.

Що змінилося: перевіряйте намір, а не рядки

Код-рев'ю раніше виконувало кілька завдань одночасно: виявляло помилки, забезпечувало дотримання командних угод, ухвалювало проєктні рішення та підтримувало розуміння системи в усіх. Команда розділила ці завдання та дала кожному краще місце.

Намір і критерії приймання фіксуються з сесії кодування з агентом, а не пишуться як заздалегідь готова специфікація. Щоразу, коли інженер виправляє агента або відповідає на його запитання, створюється критерій. Команда каже, що раніше викидала їх, коли сесія завершувалася. Намір відповідає на запитання, чому зміну роблять; критерії приймання відповідають на запитання, як вона має поводитися. Намір без критеріїв неможливо перевірити, а критерії без наміру неможливо оцінити.

Саме другу половину рев'юер, який читає диф, ніколи б не перевірив. Не кожен критерій потребує браузера: контракт API доводиться записаним запитом і відповіддю, а правило коду збігом ast-grep або посиланням на файл і рядок. Радять обирати найдешевший доказ, який вирішує питання. Зелена перевірка CI лише каже, що пройшли тести, про які ви подумали.

Рішення надходять із трьох джерел: сесії кодування, аргументу агентів і невдалих запусків перевірки. У запиті на злиття перелічено кожне, його походження та хто його вирішив. У запиті на злиття, який додав повторні спроби для невдалих доставок вебхуків, чотири з п'яти рішень були вирішені; агенти не погодилися, чи прибирати дублікати повторно доставлених вебхуків, тож це вирішила людина.

Інженери припиняють читати кожен рядок. Вони володіють правилами, які перевіряють кожен рядок, і підтримують розуміння системи через читання наміру, доказів і рішень.

Результати

Робота з рев'ю не зникла. Вона перемістилася до уточнення інваріантів, обговорення рішень і покращення перевірки. Перехід може бути болісним: у перший місяць подвійна робота, до другого місяця інваріанти наздоганяють настільки, що рев'ю зменшуються, а до третього місяця люди читають намір і докази, а не код.

Джерела: The New Stack