Как ИИ-агенты обманывают наши инстинкты на код-ревю и что с этим делать

[evgen83954621]

Мы привыкли, что плохой код выглядит грязно: кривые отступы, странные имена переменных, спагетти-логика. Наши инженерные инстинкты годами затачивались на поиск этого мусора.

Но ИИ-код устроен иначе. Он не выглядит неряшливо. Он выглядит так, будто его написал senior-разработчик на пике своей формы: идеальный камелькейс, аккуратные функции, зеленые галочки на CI-пайплайне. И в этом кроется главная ловушка: глянцевый код усыпляет бдительность. Мы бегло смотрим на этот красивый диф, ставим "Approve" и катим в прод бомбу замедленного действия.


1. Иллюзия тестового покрытия (Тесты-декорации)

Агенты обожают писать тесты, потому что знают, что мы требуем покрытия. Но если вчитаться в ассерты, выясняется, что половина из них проверяет воздух. Модель пишет тяжелую асинхронную функцию создания пользователя и в конце проверяет: expect(user).toBeDefined();.
Прошел ли тест? Да. Проверяет ли он логику? Нет, это просто декорация.

• Что делать: Мой личный лайфхак при ревью, мысленно (или руками) переверните одно утверждение в тесте или закомментируйте кусок логики. Если тест всё равно горит зеленым, ИИ просто нарисовал вам красивую картинку. И не смотрите на общее покрытие проекта (overall coverage), ИИ размывает его. Требуйте от пайплайнов метрику patch coverage, какой процент именно измененных строк покрыт реальными тестами.

2. Архитектурный блоатинг (Раздувание системы)

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

3. Глухота к пограничным сценариям (Unhappy Paths)

По идеальной прямой дорожке (happy path) ИИ бежит великолепно. Но стоит сети моргнуть или прийти пустому значению — и система падает. ИИ обожает оставлять пустые блоки catch {}, безбожно замалчивая системные ошибки, или забывает логировать контекст при таймаутах.

Инженерный манифест

Мы должны рaзделить обязанности. Человек на ревью не должен тратить когнитивное топливо на проверку того, существуют ли вообще вызванные ИИ методы в текущей версии lockfile. Эту механическую рутину (поиск дубликатов, скaнирование секретов, проверку устаревших зависимостей) нужно полностью отдать автоматическим ботам и экшенам в CI/CD (например, вешать на гитхаб утилиты вроде DebtDraft или аналогичные линтеры).

Человек на ревью обязан держать в голове только одну вещь: соответствует ли этот красивый диф исходному бизнес-намерению задачи?
Если вы бездумно мержите ИИ-код, просто потому что он выглядит аккуратно, вы не ускоряете разработку. Вы берете кредит у технического долга под грабительские проценты.