Пройдет ли AI код-ревью?

ИИ может за час сделать то, на что раньше уходили недели. Но готовы ли вы выкатить этот результат в прод без код-ревью от сеньора?

🚩 Скорее всего, нет. «Работающий код» больше не критерий качества. Критерий – поддерживаемый код.

По мере того как мы перекладываем задачи на ИИ-агентов, главный инженерный вопрос смещается с «Как мне это написать?» на «Насколько чисто это написано?»

Вот почему код, который «просто работает», может оказаться бомбой замедленного действия:

1. Риск получить спагетти-код. Агент вполне может решить сложную задачу одной функцией на 500 строк. Юнит-тесты пройдут, но в будущем это станет кошмаром для поддержки. Задача человека теперь – жестко следовать архитектуре и принципам SOLID там, где ИИ по умолчанию выбирает стратегию «лишь бы работало».

2. Безопасность и «галлюцинации». ИИ опирается на самые частые паттерны из своих обучающих данных – а они далеко не всегда безопасны. Мы регулярно видим всё: от захардкоженных кредов до устаревших, уязвимых библиотек, которые LLM подтягивает в кодовую базу просто потому, что они «выглядели уместно».

3. Ловушка эффективности. Да, фронтенд выглядит отлично. Но что там под капотом? Оптимальный алгоритм или вложенный цикл O(n²), который намертво ляжет на реальных объемах данных? Одного функционального тестирования уже мало – нам нужна глубокая архитектурная оценка (evaluation).

Мы вступаем в мир, где ИИ – это разработчик (мидл/джун), а человек, вооруженный мощными фреймворками валидации и ML-оценки, – это сеньор ревьюер.

Написание кода стремительно обесценивается. Умение ревьюить, аудировать и оркестровать код становится главным навыком.

Поэтому у нас на проекте принята практика двойного ревью того, что написал AI.

Сначала ты смотришь своим человеческим взглядом на то, что написал агент, и уже потом отправляешь PR в общий репозиторий.
На втором этапе твой коллега еще раз оценивает, что в результате получилось.

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