Проверяйте код, созданный ИИ

Прочитайте требование до описания

Начните с нужного поведения и критериев приёмки. Затем изучите фактический diff. Описание агента помогает ориентироваться, но может пропускать изменения или неточно описывать проверки.

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

Сначала проверяйте поведение с наиболее серьёзными последствиями. Форматирование и имена важны, но не должны отвлекать от отсутствующей границы данных.

Проследите связь пользователя с ресурсом

Рассмотрим неполный вымышленный endpoint. Пример показывает задачу review; это не production-код.

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

Функция получает аутентифицированного пользователя. Она не показывает решение о праве доступа к счёту. Проверяющий должен выяснить, обеспечивает ли это другая часть системы. Неиспользуемое значение user — причина для исследования, но само по себе не доказательство эксплуатируемого дефекта.

Проследите запрос через фактическую систему. Определите доверенные данные о пользователе и организации. Проверьте, как запрос к базе ограничивает доступ к нужной записи. Изучите обработку ошибок и тесты запрещённых запросов.

Не предполагайте, что скрытая кнопка защищает API. Вызывающая сторона может отправить запрос без интерфейса. Не предполагайте, что корректный ID записи даёт право доступа.

Спросите, какие проверки способны отклонить изменение

Успешный тест может использовать тестовую учётную запись администратора или mock авторизации. Убедитесь, что он проверяет существенную границу. Где уместно, добавьте случай с другой организацией и реальным путём авторизации.

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

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

Сохраняйте независимость review

Вторая модель может выявить значимые проблемы. Она также может повторить предположения реализации. Передайте проверяющему требование и diff. Не подсказывайте, что изменение уже правильное.

Требуйте, чтобы замечания указывали конкретный сценарий сбоя и соответствующий код. Неподтверждённые предупреждения рассматривайте как вопросы для исследования. Уверенное одобрение остаётся ещё одним мнением, пока важные утверждения не подкреплены подтверждениями.

Review человеком остаётся решением об ответственности. Проверяющий должен понимать изменение достаточно хорошо, чтобы объяснить поведение, риски и проверки. Если diff слишком велик, сократите объём или разделите его на обозримые изменения.

Завершайте review на итоговой ревизии

После исправления повторите затронутые проверки. Изучите, не создаёт ли исправление новую проблему. Убедитесь, что обязательное review относится к итоговой ревизии согласно правилам репозитория.

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

Перед проверкой реального изменения потренируйтесь находить недостающее решение в упражнении по review кода.