Переглядайте код, згенерований ШІ

Прочитайте вимогу перед підсумком

Почніть із запитуваної поведінки та критеріїв приймання. Потім перевірте фактичний diff. Підсумок агента може допомогти зорієнтуватися, але може пропускати зміни або неточно описувати перевірки.

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

Спочатку перегляньте поведінку з найсерйознішими наслідками. Форматування й назви важливі, але не повинні відволікати від відсутньої межі даних.

Простежте ідентичність до ресурсу

Розгляньмо цей неповний вигаданий endpoint. Приклад ілюструє проблему перегляду; це не код для продуктивного середовища.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

Функція отримує автентифікованого користувача. Вона не показує рішення про авторизацію доступу до рахунку. Рецензент має перевірити, чи інший рівень забезпечує це рішення. Невикористане значення user — причина для дослідження, а не самостійний доказ дефекту, який можна використати для атаки.

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

Не припускайте, що прихована кнопка захищає API. Ініціатор може надіслати запит без інтерфейсу. Не припускайте, що дійсний ідентифікатор запису надає доступ.

Запитайте, які докази можуть відхилити зміну

Успішний тест може використовувати тестового адміністратора або підмінену авторизацію. Перевірте, чи він справді випробовує важливу межу. Де доречно, додайте випадок з іншою організацією та справжнім шляхом авторизації.

Для зміни інтерфейсу перевірте відображений результат. Перевірте роботу клавіатури, порожні стани, завантаження та помилки. Перевірка типів не може довести, що діалогом зручно користуватися з клавіатури.

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

Зберігайте незалежність перегляду

Друга модель може виявити корисні проблеми. Вона також може повторити припущення реалізації. Надайте рецензенту вимогу та diff. Не повідомляйте йому наперед, що зміна вже правильна.

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

Перегляд людиною залишається рішенням про відповідальність. Рецензент має достатньо розуміти зміну, щоб пояснити її поведінку, ризики та перевірку. Якщо diff надто великий, звузьте обсяг або поділіть його на зміни, придатні для перегляду.

Завершуйте перегляд на остаточній ревізії

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

Запишіть рішення про приймання через поведінку й докази. Для кожного залишкового обмеження вкажіть відповідального та наступну дію. Не перетворюйте невирішене питання на твердження, що всі перевірки пройшли успішно.

Використайте вправу з перегляду коду, щоб потренуватися знаходити відсутнє рішення перед дослідженням реальної зміни.