Как проверять код, который написал ИИ — и почему начинать надо с дифа

Вот в чём фокус с кодом от ИИ: он почти никогда не бывает сломан очевидно.

Синтаксис правильный. Имена переменных осмысленные. Комментарии на месте. Выглядит так, будто писал уверенный человек. И на том примере, который ты показал, всё работает.

Проблема ровно в этом. Модель пишет не «неправильно» — она пишет правдоподобно неправильно. А правдоподобное невозможно поймать чтением по диагонали: глаз скользит и не спотыкается.

Поэтому проверка кода от ИИ — это не «вчитаться внимательнее». Это другой порядок действий. Вот он, шесть шагов.

1. Смотри диф, а не файл

Первый и главный разворот. Не читай итоговый файл — читай изменения.

git diff

Если правок много, начни с обзора:

git diff --stat

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

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

2. Найди то, о чём ты не просил

Теперь веди пальцем по дифу и на каждом куске спрашивай: я это заказывал?

Ты просил поменять текст кнопки — почему тронута функция загрузки? Ты просил добавить поле — почему пропала проверка на пустой список?

Модель почти всегда правит шире задачи. Не из вредности: она видит код, который кажется ей неряшливым, и «улучшает» его заодно. Беда в том, что она не знает, зачем там костыль. А костыли обычно стоят не просто так — за каждым чья-то пролитая кровь.

Правило простое: всё, что вне задачи, — откатывай. Не «ну ладно, вроде лучше стало». Отдельная правка — отдельный заход, с отдельной проверкой.

Отдельно ищи удалённые строки (в дифе они с минусом). Добавленное ты прочитаешь и так. Удалённое — единственное, что ревью пропускает систематически.

3. Проверь границы

Код от модели работает на том примере, который был в разговоре. Границы она угадывает.

Пройдись по четырём вопросам:

• Пусто. Пустой список, пустая строка, ноль элементов. Что нарисуется?
• Нет значения. Поле не пришло с сервера, значение null. Упадёт?
• Много. Тысяча записей вместо трёх. Десять тысяч символов в поле.
• Ошибка. Сервер ответил 500, интернет отвалился на середине. Пользователь это увидит или оно молча проглотится?

Последний пункт — чемпион по пропускам. Модели очень любят try/catch, внутри которого пусто. Ошибка поймана, никому не сказано, приложение делает вид, что всё хорошо. Это хуже, чем падение: падение хотя бы заметно.

4. Посмотри, откуда данные и куда они уходят

Быстрый, но обязательный проход по безопасности. Три вещи:

1. Ключи и пароли в коде. Модель могла вписать ключ прямо в файл — особенно если ты сам показывал его в чате. Ключам место в переменных окружения, не в репозитории.
2. Новые сетевые запросы. Появился запрос на адрес, которого ты не заказывал? Разберись, куда и зачем.
3. Новые зависимости. Поставился пакет? Посмотри, что это за пакет и живой ли он.

Тридцать секунд, но именно эти тридцать секунд отделяют «я выложил проект» от «я выложил свой ключ».

5. Запусти — но не по тому пути, который показывал

Очевидный шаг с неочевидной поправкой.

Если ты проверяешь ровно тот сценарий, на котором модель настраивалась, ты проверяешь её домашнее задание. Оно сдано.

Запусти соседний путь. Другую кнопку рядом. Тот же экран, но с пустыми данными. Возврат назад и повторный заход. Ломается обычно там — почему так происходит, разбирали отдельно.

Если что-то упало — не пересказывай ошибку своими словами. Копируй текст целиком, включая стек. Как его читать — отдельная маленькая наука, и она окупается.

6. Спроси модель, что тут сломается

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

Новая — потому что в старой модель уже защищает своё решение: она помнит, как обосновывала каждую строчку. Чистый контекст даёт куда более честный разбор.

А вопрос должен просить не одобрения, а дыр:

Разница не в вежливости. Первый вопрос предлагает модели согласиться — и она соглашается. Второй даёт ей роль критика, конкретные рамки и явное разрешение сказать «проблем нет». Ответы получаются разные до неузнаваемости.

Что получится

Полный проход по шести шагам на средней правке занимает минут десять. За эти десять минут ты обычно находишь:

• одну-две правки не по задаче (шаг 2) — откатываешь;
• один непроверенный пустой случай (шаг 3) — дописываешь;
• иногда проглоченную ошибку (шаг 3) — превращаешь в видимое сообщение.

И, что важнее находок, меняется сама роль. Ты перестаёшь быть тем, кто принимает чужую работу на веру, и становишься тем, кто отвечает за результат. Код в твоём репозитории — твой, кто бы его ни набрал.

Нужно ли читать каждую строчку от ИИ?

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

Что делать, если я не понимаю сгенерированный код?

Не принимать. Попроси объяснить построчно или переписать проще — модели отлично умеют «сделай то же самое, но чтобы понял новичок». Код, который ты не понимаешь, ты не сможешь починить в три часа ночи, когда он сломается.

Достаточно ли того, что код запускается?

Нет. «Запускается» проверяет один путь из десятка. Минимум — ещё пустые данные и ошибка сети: два случая, на которых падает большинство сгенерированных экранов.