Корявый код джуна раньше был полезен. Странный JOIN, переменные tmp2 и data_new, три вложенных if там, где хватило бы одного. По таким следам ревьюер сразу видел, где человек плавает, и шёл проверять именно туда.

С ассистентом этот сигнал пропал. PR приходит аккуратный: нормальные имена, докстринги, обработка ошибок, тесты на happy path. Выглядит так же, как работа человека, который понимает, что делает. Ошибка при этом может сидеть в одной строке, и по внешнему виду её уже не найти, так что смотреть приходится всё.

Задачи джун с ИИ закрывает быстрее, только у старшего работы от этого прибавляется.

Генерировать подешевело, проверять нет

Вот два описания к одному и тому же PR. Первое: «вот код». Второе: «взял такой алгоритм, потому что на входе не больше пары тысяч записей; прогнал на пустом списке и на дублях; сломается, если API начнёт отдавать ответ страницами». Код одинаковый. В первом случае ревьюеру проверять нечего, кроме самого кода, и он решает задачу заново: читает документацию вызываемого API, гоняет тесты, думает про параллельные запросы. Во втором у него есть от чего оттолкнуться: прогнать тот же пустой список, посмотреть, что будет на трёх тысячах записей, открыть доку API на пагинации. Такое описание модель, конечно, тоже напишет, и на слово ему верить не надо. Польза в том, что его можно быстро перепроверить.

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

Особенно больно в инфраструктуре

Допустим, у сервиса есть SSE-эндпоинт за nginx. События приходят в браузер пачками, с задержкой, а если бэкенд замолкает дольше минуты, поток рвётся: proxy_read_timeout по умолчанию 60 секунд. Джун спрашивает модель и приносит фикс:

location /api/stream/ {
    proxy_pass http://backend;
    proxy_buffering off;
    proxy_read_timeout 3600s;
}

Если пачки делает именно буферизация nginx, оба симптома этот конфиг лечит.

Только что он поменял заодно? С выключенной буферизацией nginx отдаёт ответ клиенту синхронно, по мере получения, и медленный клиент держит апстрим открытым, пока читает (а если бэкенд держит по воркеру на соединение, то и воркер). Для SSE это неважно, соединение там и так живёт долго. Но если proxy_buffering off поставили не в этот location, а в server {}, так же пойдут и все обычные ответы. А proxy_read_timeout ограничивает паузу между двумя чтениями от апстрима, так что по-настоящему зависший апстрим nginx теперь оборвёт только после часа тишины.

Может, бэкенду стоило слать keepalive-комментарии раз в полминуты, а таймаут оставить? Куда в итоге легли эти строки, в location или выше? Чем измерили эффект и как откатывать? Буферизацию, кстати, бэкенд может выключить и сам, заголовком X-Accel-Buffering: no на нужных ответах, не трогая конфиг (таймаут он при этом не меняет).

Если на всё это ответ «так посоветовала модель», ревьюер идёт в документацию nginx и разбирается сам. Делает задачу второй раз, а потом ещё объясняет, чем первый вариант был опасен.

Что я бы поменял

Запрещать ассистентов я бы не стал. Сильному инженеру ИИ заметно ускоряет работу как раз потому, что он умеет проверить ответ, и учить джуна надо именно этому.

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

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