Agentic coding сломал мой код-ревью процесс — как вы адаптировались?

[docker13]

Столкнулся с неожиданной проблемой. Раньше PR от джуна — 200 строк, я понимаю логику, вижу мышление автора, могу обучить. Теперь приходит PR от того же джуна — 800 строк сгенерированных Claude Code, джун сам не очень понимает все детали, но 'оно работает и тесты проходят'. Код ревью превратился в попытку разобраться в чужом агентном output'е. Как вы перестроили процесс код-ревью под реальность где половина кода пишет агент?

[juniorstack]

У нас ввели правило: в описании PR обязательно указывать что было сгенерировано агентом, и автор должен приложить краткое объяснение каждого нетривиального решения своими словами. Если не можешь объяснить — значит не понял, значит PR не принимается. Это сначала казалось бюрократией, но реально помогает джунам учиться а не просто копировать output агента.

[Vthors22]

Я как тимлид перестал ревьюить строки кода и начал ревьюить решения. Смотрю на: правильно ли декомпозирована задача, соответствует ли архитектурным принципам команды, нет ли security-проблем, покрыты ли edge cases тестами. Детали реализации — если тесты зелёные и нет очевидных проблем — принимаю. Это сдвиг который занял примерно месяц привыкания.

[Omoto]

@docker13, Мы добавили обязательный прогон claude -p 'review this PR for security issues and architectural violations' как часть CI. Агент ревьюит агентный код — звучит рекурсивно, но работает. Он хорошо находит SQL injection, небезопасные десериализации, нарушения наших архитектурных паттернов (которые описаны в CLAUDE.md). Человеческий ревьюер смотрит на бизнес-логику и принимает финальное решение.

[smith_kate]

Честно скажу — у нас это вызвало конфликт в команде. Старшие разработчики говорят что джуны 'не учатся программировать', только 'учатся промптить'. Джуны говорят что старшие не понимают что программирование изменилось. Мы в итоге ввели 'агентные' и 'ручные' задачи в равных пропорциях — чтобы и скорость была и понимание не терялось. Пока работает, но напряжение есть.

[alansmit]

Практическое решение которое нам помогло: каждый PR теперь требует 'агентный дневник' — краткий лог ключевых промптов и решений принятых в процессе работы с агентом. Это занимает 5 минут, но ревьюер сразу понимает ход мысли, а не разгадывает загадку откуда взялись 800 строк. Побочный эффект — разработчики стали думать о промптах как о коде, структурировать их, переиспользовать.

[burg0809]

@juniorstack, Мы решили проще: ограничение на размер PR — не более 400 строк изменений. Если агент нагенерировал больше — разбей на части. Это заставляет думать об атомарных изменениях и не даёт скидывать огромные агентные сессии одним куском. Ревьюить маленькие PR с агентным кодом — вполне нормально, проблема именно в гигантских.

[fpga87]

@Omoto, у нас похожий прогон в CI стоит и я бы притормозил с восторгами. За полгода он поймал пару реальных дыр, да, но ещё нагенерил гору ложных срабатываний, и люди начали жать resolve не читая. Классическая усталость от алертов, только теперь в ревью. В итоге оставили его только на диффы больше 200 строк и список проверок урезали до security, стало терпимо.

[qcdeed]

А по-моему тред про симптом, болезнь не там. Джун который пушит 800 строк не понимая их, это старая история, раньше точно так же тащили со stackoverflow и из чужих реп, разница только в объёме. Правилами оформления PR это не лечится. Лечится тем что тимлид раз в неделю садится с джуном и час разбирает его PR голосом. Дорого? Да. Но дешевле чем через год поддерживать базу которую не понимает никто, включая авторов.

[depechie]

@burg0809, лимит 400 строк звучит красиво ровно до первой миграции или сгенерённого клиента по openapi спеке. И я видел что делают люди с жёстким лимитом: режут связное изменение на три PR по 399 строк, которые по отдельности смысла не имеют и ревьюятся ещё хуже. Метрика стала целью, привет Гудхарт.