Я больше не могу это ревьювить
Утро. Я как обычно завариваю флэт уайт и сажусь делать код ревью. Чаще всего передо мной с десяток пулл реквестов, куда нужно “посмотреть”. Добрая часть из них – простенькие фиксы, на них уходит полкружки кофе. Дальше идут реквесты посерьезнее, где нужно вникнуть, подумать, запустить локально. Обычно кофе заканчивается быстрее, чем я пойму, куда смотреть в первую очередь. Где-то через час рутина заканчивается и можно перейти к “своим” делам.
Так был устроен мой разработческий быт последние пять лет. Но недавно я начал подмечать изменения.
Первое. Я стал тратить больше времени на рутинное код ревью. Я перестал успевать сделать это до созвонов. Ревью откладываются на потом, а я начал уставать от этого. Мне стало сложнее делать “свою” работу просто потому, что код ревью теперь забирает слишком много энергии.
Второе. Я начал злиться. Каждый сгенерированный пулл реквест вызывает у меня эмоцию злости и отвращения.
Я задумался, а почему так? И вот что обнаружил – кода на ревью стали присылать гораздо больше. Обусловлено это растущей популярностью LLM моделей. Качество кода при этом разнится от связки модель + автор. Если это Opus 4.5 + Senior с мозгами, то качество стало выше. Если это Sonnet + Middle, то тут бывает по-разному. Ну а джунов я давно уже не видел.
Получается интересная картина: привычный код ревью стал напрягать, причем через собственные “телесные” напряжения мне видится индикация напряжения индустрии. Это кризис процессов в разработке.
На ум приходит теория ограничений Голдратта и термин бутылочное горлышко. Привычный код ревью стал тем самым бутылочным горлышком. При наращивании мощности нижележащих процессов мы уперлись в ограничения далее. Чтобы пайплайн разработки был действительно эффективным, следует подумать над способами разрешения бутылочного горлышка. Коим и является процесс код ревью.
Давайте разберемся, а зачем нам был нужен код ревью ранее?
Практический опыт: изучение проекта конкретным разработчиком.
Социальный: шеринг знаний с коллегами, взаимообучение.
Фактический: улучшение качества кода на выходе.
Сейчас мы находимся в точке, где интеграция ИИ в повседневную жизнь разработчика только набирает обороты, но уже можно с уверенностью сказать, что предыдущие “проблемы” перестают существовать. Три пункта выше не исключение. Смотрите.
- Практический опыт: изучение проекта конкретным разработчиком.
Я пользуюсь Claude Code (CC) около года. С выходом Opus 4.5 CC стал инструментом номер 1 в решении любой задачи. Изучение проекта и построение ментальной модели кодовой базы – это задача. И она превосходно решается с помощью CC. Мне больше не нужно ревьювить код коллег, чтобы быть в курсе.
How the repository logic works?
List me all database access patterns used in this project.
I also want to see database integration tests.
- Социальный: шеринг знаний с коллегами, взаимообучение.
При условии, что коллеги так же быстро могут вникнуть в кодовую базу, как и я, то шерить код с ними становится бесполезным. Шерить нужно что-то другое.
- Фактический: улучшение качества кода на выходе.
Поиск багов глазами стал слишком дорогим. Человек будет ревьювить код около 15 минут, в то время как модель сделает это за 15 секунд. При этом стоимость работы модели в несколько раз ниже, чем зарплата человеку. А качество на выходе, по моему опыту, сравнимое.
На смену код ревью должно прийти что-то другое. Очевидно, что модели должны ревьювить друг друга, но без участия человека. Также на поверхности лежит идея о том, что линтеров, чекстайлов и тестов должно становиться больше. Зеленый CI – можно пушить в мейн “не глядя”.
Вопрос в том, а что делать человеку?
На первый взгляд мысль парадоксальная, но я действительно так думаю. Человеческий ресурс становится более востребованным. Только сфера востребованности перемещается туда, где она всегда должна была быть. Что мы делаем? Зачем? Кому это нужно? Как мы гарантируем качество продукта? Какие ключевые инженерные решения, влияющие на продукт, мы принимаем? Какие ограничения они за собой несут?
–
14 января 2026. Автор Саша Пахомов.