Код, предложенный нейросетью, проверяй как код от неизвестного автора: сначала пойми, что изменится, затем запусти проверки в изолированной среде. Факт, что проект собрался или один happy path сработал, не доказывает корректность, безопасность или сохранение прежнего поведения.
GitHub описывает Copilot code review как помощника, который анализирует pull request и предлагает исправления; документация также выделяет применение предложенных правок человеком (GitHub Copilot code review). В отдельной карточке Copilot Agents GitHub описывает возможности, ограничения и меры ответственного использования агентных функций. Это пример конкретного продукта, не замена ревью и не подтверждение качества любого сгенерированного кода.
Проверка в шесть шагов
1. Сверь изменение с требованием
Запиши ожидаемое поведение словами и условиями: какие входы поддерживаются, что должно происходить и чего не должно происходить. Попроси модель кратко перечислить файлы и поведение, которые она изменила. Сравни с реальным diff.
2. Прочитай diff целиком
Ищи неожиданные удаления, изменение конфигурации сборки, новые зависимости, изменение auth, сетевых адресов, платежей и миграций. Не принимай массовый форматирующий diff вместе с логикой: раздели изменения, чтобы видеть смысл.
3. Проверь границы доступа
Посмотри, кто может вызывать новый endpoint, читать данные и выполнять действие. Проверь, что секрет не встроен в клиент, ошибки не возвращают токены, а пользователь не может обратиться к чужому объекту изменив ID.
4. Проверь зависимости
Сверь имя, версию, источник и лицензию новых пакетов. Убедись, что код не исполняет установочный скрипт или shell-команду только потому, что модель это предложила. Lockfile и список зависимостей должны соответствовать ожидаемому изменению.
5. Добавь проверки по поведению
Тестируй требование и граничные случаи, а не внутреннее устройство конкретной реализации. Если требование — «неавторизованный запрос не меняет запись», тест должен утверждать отсутствие изменения и отсутствие доступа; он не должен повторять ту же ошибочную функцию из реализации.
6. Проверь отказ и откат
Что происходит при пустом вводе, повторном запросе, сетевом сбое и ошибке провайдера? Можно ли безопасно откатить изменение? Для миграции данных нужен проверенный backup и план восстановления до запуска.
Практическая таблица
| Область | Вопрос перед запуском |
|---|---|
| Функция | Выполняет ли код исходное требование без лишних действий? |
| Ввод | Что будет с пустым, длинным или неверным значением? |
| Авторизация | Проверяется ли право на каждый объект на сервере? |
| Секреты | Нет ли ключей в frontend, логах, diff или примерах? |
| Данные | Может ли операция повториться без дубликата или потери? |
| Зависимости | Понятно ли, зачем добавлен каждый пакет? |
| Откат | Как вернуть прежнее состояние? |
Запускай новый код в тестовом окружении с фиктивными данными. Не используй продакшен-ключи и клиентские данные для первой проверки. Если в diff затронуты платежи, авторизация или удаление данных, отдай изменение второму человеку с предметным контекстом.
Что может сделать ИИ-ревьюер
Попроси указать только конкретные дефекты с файлом, условием воспроизведения и последствием. Затем сам проверь каждое замечание. Отсутствие комментариев агента не означает, что код безопасен: модель может пропустить дефект, не понять архитектуру или неверно оценить риск.
Регрессия часто появляется в соседнем сценарии. Если поменялся парсер даты, проверь пустое значение, timezone, дату на границе месяца и старые данные. Если поменялась авторизация, проверь и разрешённый запрос, и запрет на чужой объект. Если добавлен retry, проверь, что side effect не дублируется. Хороший тест исходит из контракта поведения, а не из того, какую функцию придумала модель.
Запускай форматтер, линтер, типы и тесты проекта, если они уже настроены, но воспринимай зелёный результат как покрытие этих проверок, а не сертификат безопасности. Посмотри на новые warnings и не подавляй их автоматически. Для зависимости проверь advisory и минимально нужную версию по официальному источнику пакета.
Перед merge попроси автора изменения объяснить риск и откат. Если сам не можешь объяснить весь diff, уменьши объём задачи и попроси модель разделить изменение на маленькие части.
Пример: меняется форма, но меняется ли правило?
Предположим, модель добавила поле isAdmin в API-ответ. Сначала сверь diff с требованием: зачем это поле нужно и кто его задаёт? Затем проследи источник роли на сервере и проверь, что endpoint запрещает обычному пользователю изменить чужую запись, даже если кнопка скрыта. После исправления запусти тесты трёх случаев: обычный пользователь, администратор и запрос с чужим ID. Сверь фактическое состояние данных, затем повторно просмотри diff, чтобы убедиться, что fix не добавил лишние права.
Если ИИ предложил новую библиотеку для одной строки логики, сравни её с уже имеющимися возможностями проекта и стоимостью обновления. Маленький diff не означает маленький риск: один middleware может менять все маршруты. Если код запускает миграцию, прочитай SQL отдельно и проверь сценарий rollback на копии базы.
Перед публикацией собери список действий, которые код теперь может выполнять, и сравни его с требованием. Для дополнительной проверки секретов смотри как держать API-ключи вне браузерного bundle.
Сохрани воспроизводимый review
Перед изменением зафиксируй branch/commit. После проверки сохрани вывод тестов и точные команды, но удали из логов переменные с секретами и приватные данные. Если модель выполнила команду, разберись, какие файлы она читала или меняла. Не запускай полученный из недоверенного источника скрипт от имени администратора.
Для маленькой правки достаточно короткого diff и теста по требованию; для миграции, авторизации или данных нужен владелец системы и план отката. Риск определяется тем, что код может сделать, а не тем, сколько строк он занимает.
Проектная разработка и AI-workflow — на странице MK Ultra.