Код от AI трудно ревьюить прежде всего потому, что он хорошо выглядит. Ровное форматирование, понятные имена, аккуратная структура. То, что в чужом коде обычно говорит о добросовестной работе, здесь достаётся даром.
Поэтому привычные быстрые эвристики не срабатывают, и порядок проверки нужен другой.
Сначала границы, потом логика
Основная логика у модели чаще всего верна. Дефекты сидят на краях:
- пустой массив, пустая строка, ноль
- отрицательные числа там, где рассчитывали на положительные
- очень большие значения и переполнение
- параллельный доступ и повторный вызов
- поведение, когда внешний вызов завершился ошибкой
Эти случаи модель и пропускает, потому что вы про них ничего не сказали.
Проверяйте удалённые строки
При рефакторинге у агентов есть опасная привычка: молча убрать то, что показалось лишним. Проверку, которая выглядела избыточной, но страховала от редкого случая. Обработку ошибки, которая в тестах ни разу не сработала.
Удалённые строки в дифе читайте так же внимательно, как добавленные.
Падающий тест до исправления
Когда агент чинит баг, порядок такой: сначала тест, который воспроизводит проблему и падает, затем исправление, затем тот же тест проходит.
Только такое доказательство нельзя подделать красивым объяснением. Свои действия модель описывает отлично, но описание проверкой не становится.
Уверенность и корректность это разные вещи
Верный и неверный ответ модель излагает с одинаковым спокойствием. Сигнала сомнения в коде нет.
Если объяснение звучит убедительно, а запускать вы ничего не стали, значит, вы ничего и не проверили.
Держите изменения небольшими
Диф на десять файлов проверяется хуже, чем пять дифов по два файла. Это верно и для кода людей, но для агентского правило строже: связи между файлами меняются разом, и удержать их в голове труднее.
Разбить задачу дешевле, чем потом распутывать большой диф.
Три правила процесса
- Автор изменения это человек, который его отправил. Отвечает за него тоже он.
- Агент сам не мержит, при любых настройках.
- Расход виден по каждому ключу, чтобы было понятно, где переделки съедают бюджет.
Последний пункт похож на разговор о деньгах, а на деле это метрика качества: много итераций значит, что задачу поставили плохо.
Коротко
Аккуратный вид ничего не доказывает. Проверяйте границы, читайте удалённые строки, требуйте падающий тест до исправления и не раздувайте изменения.