ИИ-ассистенты в разработке убрали из кода джуна привычные маркеры неопытности: кривые имена переменных, странные ветвления и очевидные промахи. Проблема в том, что вместе с ними исчезли и подсказки для ревьюера: аккуратный pull request может выглядеть как работа сеньора, но содержать ошибку в одной строке. Для русскоязычных команд это означает простую вещь: экономия времени на генерации кода легко превращается в перерасход времени на проверке.
На эту проблему обратил внимание автор материала, который за 19 часов собрал на Habr / Карьера 8,1 тыс. читателей. Тезис короткий и неприятный: джун с ИИ закрывает задачу быстрее, но если он не понимает, как пришел к решению, старший инженер вынужден восстанавливать весь путь самостоятельно. То есть не просто читает PR, а фактически решает задачу заново.
Раньше слабое место часто было видно по стилю. Неудачный JOIN, временные переменные с бессмысленными именами, три вложенных условия там, где достаточно одного, — все это работало как дым из-под капота. Ревьюер понимал, куда смотреть внимательнее, и быстрее находил зону риска. С генеративными инструментами этот дым рассеивается: код получает нормальные имена, комментарии, обработку ошибок и тесты на самый удобный сценарий. Внешне все прилично. Внутри может быть логическая дыра, неверное допущение или изменение поведения системы, которое автор даже не заметил.
Ключевой конфликт не в самом использовании модели, а в отсутствии проверяемого объяснения. Есть большая разница между PR с подписью «вот код» и PR, где автор пишет: выбран такой алгоритм, потому что вход ограничен несколькими тысячами записей; проверены пустой список и дубликаты; есть риск, если API начнет отдавать данные страницами. Код может быть одинаковым, но нагрузка на ревьюера — разная. В первом случае он сам читает документацию, придумывает граничные случаи и ищет скрытые зависимости. Во втором он проверяет конкретные утверждения автора.
Показательный пример — инфраструктурный фикс для SSE-эндпоинта за nginx. В браузере события приходят пачками и с задержкой, а поток рвется, если бэкенд молчит дольше минуты: стандартный proxy_read_timeout равен 60 секундам. Джун спрашивает ассистента и приносит конфигурацию: отключить proxy_buffering и поднять proxy_read_timeout до 3600 секунд. Если причина действительно в буферизации nginx, симптомы уйдут. Но ревью начинается не с «работает ли», а с «что еще мы этим изменили».
Отключение буферизации заставляет nginx отдавать ответ клиенту сразу, по мере получения данных от upstream. Для SSE это обычно ожидаемо: соединение и так живет долго. Но если настройка случайно легла не в конкретный location, а уровнем выше, она затронет обычные ответы тоже. Медленный клиент сможет дольше держать открытым соединение к upstream, а если бэкенд выделяет воркер на соединение, проблема уже не косметическая. Увеличенный timeout тоже не бесплатный: зависший upstream nginx оборвет не через минуту, а через час тишины.
Есть и альтернативный путь: бэкенд может отправлять keepalive-комментарии раз в полминуты, а timeout оставить прежним. Буферизацию для нужных ответов можно отключать заголовком X-Accel-Buffering: no, не меняя общий конфиг. Но чтобы обсудить эти варианты, автор PR должен понимать, куда легла настройка, чем измерен эффект, как откатывать изменение и почему выбран именно такой вариант. Если ответ сводится к «так сказала модель», ревьюер идет в документацию nginx, разбирает поведение сам и потом еще объясняет, почему первый фикс опасен.
Для команд это меняет не политику использования ИИ, а правила сдачи работы. Запретить ассистентов проще всего, но пользы мало: сильные инженеры уже используют их как ускоритель, потому что умеют проверять результат. Джунов логичнее учить не «правильно промптить», а подтверждать свои решения без открытого чата. К задаче стоит прикладывать допущения, способ проверки и наблюдаемый результат: тест, запрос на стейдже, EXPLAIN, метрику до и после, описание граничных случаев. Для инфраструктурных изменений нужен еще и план отката.
ИИ-ассистенты в разработке также возвращают старое правило маленьких PR. Тысячу сгенерированных строк нельзя качественно проверить «по диагонали», даже если они красиво отформатированы. Чем больше кода принесла модель, тем важнее разбивать изменение на части: отдельно конфигурация, отдельно тесты, отдельно изменение бизнес-логики. Иначе ревью превращается в археологию, где старший инженер ищет не баг, а намерение автора.
Самый практичный фильтр звучит почти грубо, но работает: закрыть чат и попросить автора объяснить решение голосом. Почему выбран такой timeout, что произойдет при пустом входе, как поведет себя сервис после рестарта, какой сценарий не покрыт тестом. Если человек не может ответить без подсказки модели, задача еще не готова к ревью. ИИ-ассистенты в разработке уже стали нормой, поэтому следующий рубеж — не скорость генерации, а инженерная подотчетность: кто именно понимает код, который попал в репозиторий.