AI-агенты ускорили код — и завалили код-ревью. Что с этим делают в Uber, Cloudflare и HubSpot

Главная инсайдерская рассылка про инженерную индустрию — The Pragmatic Engineer Гергели Ороса — выпустила пост, который звучит как сигнал тревоги. Главный тренд последних шести месяцев в больших компаниях: код-ревью превращается в узкое место разработки. И индустрия пока не придумала, что с этим делать.

Рассказываю простыми словами, что происходит, какие решения пробуют в Uber, Cloudflare, Faire, HubSpot — и почему это касается даже тех, кто не работает в большой компании.

Что произошло

По словам Ороса, сдвиг стал заметен в январе 2026 года, когда вышли Opus 4.5 (модель Anthropic) и GPT 5.4 (модель OpenAI). Эти модели стали писать заметно больше и заметно лучше кода в среднем по индустрии. У инженеров появилось больше времени на ревью чужого кода — но скоро выяснилось, что это проблема, а не подарок.

В феврале–марте 2026 инженерные директора начали формулировать новый тезис: «боттлнек разработки сдвинулся с написания кода на его проверку». То есть раньше главным узким местом было «как написать фичу» — а сейчас «как проверить, что AI написал её правильно».

Это конкретная боль, не абстрактная. Орос пишет, что слышит от инженеров на уровне директоров всё больше жалоб на объём ревью. И отдельно — на качество: люди просто одобряют PR-ы (pull request — запрос на слияние кода в общую ветку), не вчитываясь, если AI-ревью не оставило комментариев. Это плохо заканчивается, но у индустрии пока нет готового рецепта.

Как пытаются решить

Все решения сейчас экспериментальные. Орос разделил их на три направления.

1. Выделенные AI-ревью-инструменты

Бум этих инструментов начался с февраля. Сейчас в индустрии есть уже целый сегмент:

• CodeRabbit — бот, который комментирует PR-ы как опытный ревьюер.
• Greptile — делает упор на понимание всей кодовой базы перед ревью.
• Qodo — специализируется на тестах и качестве.
• SonarQube / Gitar — классический статический анализ + новая фича AI-ревью.
• Sentry Seer — добавил ревью как побочный продукт своей observability-платформы.
• Linear code reviews — интегрирует ревью прямо в трекер задач.
• Claude Code review, Cursor review, GitHub Copilot review — родные ревью-фичи у самих AI-кодеров.

Общая идея: AI даёт первичный проход по коду до того, как живой человек его откроет. Если AI нашёл проблемы — ревьюер тратит время. Если не нашёл — у ревьюера хотя бы есть baseline (стартовая точка для проверки).

Проблема этого подхода та же, что и везде: AI-ревьюер пропускает не то, что пропускает живой. Это не панацея, это фильтр первого уровня.

2. In-house инструменты в больших компаниях

Одного только бот-ревью мало. Большие компании строят своё, потому что вендорские не учитывают специфику их кодовой базы. Самый интересный кейс — Uber Code Inbox. В нём есть две фичи, на которых держится модель.

Smart Assignments — распределение PR-ов не «по очереди», а с учётом того, кто что трогал в этой части кода. Если человек в последний раз работал с модулем платежей — ему и ревьюить изменения в модуле платежей. Это сильно снижает нагрузку на «дежурного ревьюера», который не понимает контекст.

Risk Profiles — оценка, насколько PR-рискованный. Маленький фикс-опечатка получает низкий риск, изменение auth-модуля — высокий. Высокий риск означает «ревью должно быть тщательным», низкий — «можно approve по-быстрому». Это даёт ревьюеру явный сигнал, куда смотреть внимательнее.

Uber — не единственный. Cloudflare AI Code Reviewer, Faire Fairey, HubSpot Sidekick — все большие игроки сделали свои инструменты, потому что «поставили вендора — не сработало, написали своё — заработало».

3. «Не ревьюить, а верифицировать»

Самая радикальная мысль в статье — а что, если мы вообще перестанем ревьюить построчно, и перейдём к более сильным формам проверки? Тесты, фаззинг (запуск кода на случайных/неожиданных данных для поиска уязвимостей и падений), формальные методы (математическое доказательство корректности кода), observability (мониторинг работы в проде).

Звучит логично, но есть подвох. Что считать «достаточной проверкой»? Юнит-тестов мало — они проверяют только то, что разработчик предвидел. Интеграционных тестов мало — они проверяют только happy path. End-to-end тестов мало — они медленные и хрупкие. Что дальше? Фаззинг? Формальные методы? Полная observability продакшена?

Орос задаёт риторический вопрос: как связать все эти слои проверки в один работающий пайплайн? Ответа у него нет, и ни у кого в индустрии пока нет.

Главный риск — burn-out ревьюеров

Самая тревожная часть статьи — не техническая, а про людей. Орос пишет, что есть два типа пострадавших.

«Ленивые» ревьюеры — те, кто раньше вчитывался, а сейчас видит, что AI-ревью пустое, и жмёт Approve. Это кажется эффективным, но на самом деле это «передача ответственности AI». Через пару месяцев баг проскакивает в прод, и непонятно кто виноват.

«Перфекционисты» ревью — те, кто продолжают читать каждый PR как раньше. Их перегружают «AI slop PR-ы» — это PR-ы, где код написан AI и выглядит правильно, но содержит скрытые баги. На таких людей падает непропорционально много работы, они выгорают и уходят.

Оба сценария плохо заканчиваются. Первый — технически, второй — по людям.

Почему это касается даже маленьких команд

Если вы думаете «у нас команда 5 человек, нам это не грозит» — вы, скорее всего, правы. Но проблема уже просочилась к вам, просто в другом виде:

• Ваш AI-ассистент пишет код для вас и для команды быстрее, чем раньше. Кнопка «сделать PR» стала дешевле. Объём кода, который идёт в ревью, вырос даже без AI-кодеров.
• Стоимость ошибки выросла, потому что AI-код выглядит «правильным». Junior-разработчик пишет код с очевидными багами. AI-генератор пишет код, который выглядит чистым, но содержит ошибку на edge case. Ревьюеру труднее это поймать — всё выглядит чистым.
• Появились инструменты, которые вы не пробовали. CodeRabbit, Greptile, Qodo — каждый из них можно поставить за час. Это низко висящий плод для команд любого размера.

Что делать прямо сейчас

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

Для команд любого размера (3+ разработчика)

1. Поставьте AI-ревью на каждый PR. CodeRabbit для открытых репозиториев — бесплатно, для закрытых — trial. Это снимает самые очевидные проблемы (синтаксис, форматирование, повторяющиеся паттерны) автоматически.
2. Попросите AI-ревьюера коротко резюмировать изменения в одном абзаце. Если резюме выглядит адекватно — это сигнал, что PR сделан осмысленно. Если нет — уже повод задуматься.
3. Разделите «ревью по делу» и «ревью для галочки». PR-ы, которые ничего не ломают (опечатки в документации, переименование переменной), можно ревьюить 30 секунд. PR-ы в чувствительных местах — час, с полным погружением.

Для команд побольше (10+ разработчиков)

1. Внедрите «ownership» (закреплённую ответственность) — модель распределения кода по владельцам. Человек ревьюит PR только в тех модулях, за которые отвечает. Не нужно понимать весь код — нужно понимать свою территорию.
2. Добавьте «risk profile» — оценку риска PR. AI-агент анализирует diff и говорит, насколько изменение чувствительное. Высокий риск — обязательное тщательное ревью. Низкий — быстрое.
3. Ведите статистику по ревью. Сколько PR-ов в день на человека, какие часто возвращаются на доработку, какие получают только авто-approve. Это покажет где bottleneck у вас.

Для руководителей

1. Следите за выгоранием ревьюеров. Это не метафора, это конкретный HR-риск. Один человек, который читает 30 PR-ов в день, через два месяца уволится.
2. Вкладывайтесь в тесты и observability. Да, Орос пишет, что вопрос открытый. Но базовый уровень — интеграционные тесты + хороший мониторинг продакшена — снижает нагрузку на ревью объективно.
3. Не верьте, что «AI-ревью решит проблему». Оно снимает часть нагрузки. Но оставшаяся часть — это самое сложное, что остаётся живым людям.

Что я думаю по этому поводу

Эта статья Ороса — одна из тех, которые звучат «про чужую боль», но попадают в нерв. Потому что проблема описана не как «AI заберёт работу», а как «AI меняет форму работы так, что старые привычки ломаются».

Главное, что я вынесла: узкое место инженерии сместилось, а процессы — нет. Код-ревью 2019 года — это когда два человека час смотрят на 100 строк и обсуждают архитектуру. Код-ревью 2026 года — это когда один человек смотрит на 500 строк от AI за 5 минут и решает, пускать или нет. Это разные задачи, требующие разных инструментов и разной культуры.

В России эта тема тоже актуальна. Не из-за больших in-house инструментов (их у нас мало), а из-за того, что AI-кодеры широко используются, а AI-ревью-инструменты — почти нет. И когда в команде из 8 человек все используют Cursor, объём PR-ов растёт в два-три раза, а ревью остаётся человеческим. Это прямой путь к выгоранию.

Если ты техлид или инженерный менеджер — обрати внимание на нагрузку ревью в твоей команде прямо сейчас. Если у твоего ревьюера очередь из 12 PR-ов и он не успевает — это уже тревожный сигнал. Не «когда-нибудь», а прямо сейчас.

Полезные инструменты для старта: CodeRabbit для авто-комментариев, Greptile для контекста всей кодовой базы, Qodo для тестов. Каждый из них можно поставить за час и получить первые результаты к концу недели. Не панацея, но фильтр первого уровня.

Источник: The Pragmatic Engineer, выпуск от 23 июля 2026, раздел Pulse. Автор — Гергели Орос. Если работаете в IT-команде, рекомендую подписаться на оригинал — он пишет про то, что реально обсуждают инженерные директора, а не про то, что хайпово в новостях.