Ещё несколько лет назад идея по-настоящему ревьюить 15 программных проектов одновременно показалась бы мне нереалистичной. Я не имею в виду просто открыть 15 репозиториев и быстро на них посмотреть. Я говорю о регулярной проверке реальных проектов на баги, слабые предположения, SEO-проблемы, ошибки переводов, несогласованность локализации, недостающие тесты, регрессии и участки старого кода, которые уже перестали соответствовать остальной системе.
Ограничением никогда не была скорость печати. Ограничением было внимание. У каждого проекта есть своя история, свои соглашения, edge cases и код, который выглядит неправильным, хотя на самом деле существует по вполне осознанной причине. Нормальное ревью требует читать, искать, сравнивать, запускать проверки, а уже потом решать, что действительно нужно менять.
Codex изменил для меня экономику этой повторяющейся работы. Он может сделать первый проход по репозиторию, проследить связи, посмотреть связанные файлы, подсветить подозрительные паттерны, предложить тесты и помочь исследовать места, которые иначе пришлось бы вручную открывать одно за другим. Это не делает финальное решение автоматическим. Это сильно ускоряет дорогую часть работы, которая происходит до решения.
Главное правило, которое я для себя вывел, очень простое: я использую Codex не для того, чтобы убрать себя из цикла ревью, а для того, чтобы сделать этот цикл шире.
Главное узкое место — повторение, а не написание кода
Когда поддерживаешь один проект, в голове можно удерживать удивительно много контекста. Когда проектов много, этот подход перестаёт масштабироваться. Одни и те же классы задач появляются снова и снова:
- поиск похожих багов в разных компонентах;
- проверка, не остался ли после рефакторинга старый call site;
- ревью тестов после изменения поведения;
- поиск несогласованности в metadata, языковых правилах, заголовках и внутренних ссылках;
- сравнение localization keys и переведённого контента;
- поиск отсутствующей обработки ошибок и edge cases;
- проверка того, не затронуло ли «маленькое» изменение неожиданно много файлов;
- чтение diff'ов, каждый из которых сам по себе простой, но вместе они съедают огромное количество времени.
В этих задачах нет ничего эффектного. Но все они важны. А когда один и тот же тип ревью нужно повторять в нескольких кодовых базах, стоимость этой работы становится огромной.
Именно здесь AI coding agent полезен мне больше всего. Он очень хорошо съедает повторяющуюся часть пространства поиска, чтобы я мог тратить больше собственного внимания на решения.
Я начинаю с исследования, а не с разрешения переписать всё
Один из самых простых способов получить плохой результат от агента — дать ему огромную задачу вроде «проверь весь проект и исправь всё». Такая формулировка кажется эффективной, но в одной команде смешивает поиск проблем, приоритизацию, архитектуру, реализацию и проверку.
У меня гораздо лучше работает разделение этих стадий.
inspect → explain findings → prioritize → change → validate → review diffСначала я хочу, чтобы агент понял нужную область и рассказал, что именно нашёл. Мне нужны конкретные пути к файлам, затронутый код, объяснение, почему что-то подозрительно, и возможные последствия. Только после этого я хочу изменения.
Это важно, потому что AI способен очень уверенно ошибаться. Код может выглядеть лишним, но существовать ради старого браузера, редкого платёжного сценария, миграции или бизнес-правила, которое невозможно понять из одного файла. Этап исследования позволяет поймать ошибочное предположение до того, как оно превратится в огромный diff.
Я воспринимаю находки как гипотезы, а не как приговор
Хорошее ревью от Codex не заканчивается фразой «я нашёл 17 проблем». Само число почти ничего не значит. Мне нужны доказательства.
Для действительно полезной находки я хочу понимать:
- где находится проблема;
- почему это проблема;
- какое поведение может сломаться;
- насколько уверенным вообще можно быть в выводе;
- какая проверка может подтвердить или опровергнуть его;
- как выглядит минимальное безопасное исправление.
Особенно это важно для security, SEO и бизнес-логики. Агент может указать на место, которое стоит исследовать, но объяснение в стиле security ещё не делает находку реальной уязвимостью. SEO-предупреждение не означает автоматически проблему с ранжированием. Странное условие не означает автоматически dead code.
AI снижает стоимость поиска кандидатов. Реальность проблемы по-прежнему определяет проверка.
Надёжным workflow делает именно validation loop
Генерация кода — самая заметная часть AI-разработки, но для production ценнее всего проверка.
После изменения я хочу, чтобы кодовая база сама ответила на него. В зависимости от проекта это могут быть:
- TypeScript или другой compiler/type checker;
- lint;
- unit- и integration-тесты;
- проверка сборки;
- точечный поиск старых названий или call sites;
- ручное чтение итогового diff;
- проверка пользовательского поведения.
Конкретные команды не так важны, как сам цикл. Агент делает предположение, репозиторий возвращает доказательства, и следующее решение принимается уже на основании этих доказательств.
Поэтому мне особенно нравятся проекты со строгой типизацией при работе с AI. Отдельно я писал о том, почему TypeScript так хорошо сочетается с Codex в реальной разработке: типы превращают многие неверные предположения в мгновенный машиночитаемый feedback.
Некоторые виды ревью особенно хорошо подходят для AI
При работе с несколькими проектами есть несколько категорий, где такой подход приносит мне особенно много пользы.
Баги и регрессии
Агент может проследить значение через несколько файлов, посмотреть callers, сравнить похожие реализации и найти ветки, которые ведут себя по-разному. Это помогает быстрее понять, откуда может идти симптом. Но перед тем как доверять выводу, я всё равно воспроизвожу или иначе проверяю поведение.
Тесты
AI хорошо помогает искать поведение, которое поменялось без соответствующего test coverage, предлагать edge cases и объяснять, что на самом деле защищает существующий тест. Ещё он способен подсветить тесты, которые проверяют детали реализации, а не реальное пользовательское поведение.
SEO
В техническом SEO очень много работы на консистентность: metadata, языковые alternate-ссылки, правила indexability, internal links, шаблоны страниц, sitemap generation, redirects и page-level conventions. Агент может сравнить эти правила по большой кодовой базе быстрее, чем я вручную открою каждый route. Но техническую корректность я всегда отделяю от намного более сложного вопроса: заслуживает ли сам контент вообще позиции в поиске.
Локализация и переводы
Для многоязычного продукта это одна из самых повторяющихся областей. AI может сравнить ключи, найти отсутствующие значения, обнаружить очевидно неправильный язык, проверить placeholders и подсветить места, где структура одного locale разошлась с другим. Это намного быстрее ручного просмотра больших объектов переводов, хотя важный пользовательский текст всё равно требует человеческого суждения.
Консистентность после рефакторинга
Большие рефакторинги часто ломаются самым скучным способом: где-то остаётся старый import, один route продолжает использовать прежнее имя поля, один test fixture хранит старую структуру. Поиск по всему репозиторию вместе с агентом, который понимает цель изменения, здесь особенно полезен.
Параллельная работа помогает только тогда, когда задачи независимы
Очень соблазнительно запустить много агентов и позволить им всем одновременно менять всё. Это может увеличить throughput, но так же легко умножает конфликты и несовместимые предположения.
Я воспринимаю параллельность как задачу координации. Независимые аудиты отлично подходят для параллельной работы: один проект можно проверять на локализацию, пока другой ревьюится на тесты, или несколько отдельных репозиториев можно исследовать одновременно. Два агента, переписывающие одну архитектуру без общего плана, — совсем другая ситуация.
Чем больше параллельности, тем важнее границы: конкретный проект, конкретная задача, понятный definition of done и результат, который можно проверить отдельно.
Цель не в том, чтобы запустить максимальное количество агентов. Цель — получить максимум полезного и проверяемого прогресса.
Что я не отдаю AI вслепую
Есть части разработки, где мне полезна помощь AI, но я не хочу отдавать ему автономное право на решение.
- Архитектурные решения: модель может предложить варианты, но долгосрочные trade-offs часто зависят от контекста, которого вообще нет в репозитории.
- Security-выводы: находки требуют проверки, понимания threat model и часто специализированных инструментов.
- Бизнес-правила: код может быть внутренне последовательным и при этом реализовывать неправильное продуктовое поведение.
- Большие разрушительные рефакторинги: огромный diff труднее осмыслить и гораздо легче бездумно принять.
- Production deployment: прошедшие тесты не отменяют необходимости понимать операционный риск.
- Финальное ревью: перед тем как поставить под изменением своё имя, я хочу понимать, что именно поменялось.
Не потому, что агент бесполезен в этих областях. Наоборот — именно здесь правдоподобная, но неверная рекомендация может стоить особенно дорого.
AI-review не заменяет статический анализ
Codex для меня также не является заменой компилятору, линтеру, тестам, scanner'ам или мониторингу. У этих инструментов есть преимущество, которого нет у AI: они узкие, детерминированные и повторяемые.
Сильнее всего работает их комбинация. Codex способен рассуждать по контексту и подсказать, куда смотреть. Статические инструменты способны жёстко применять точные правила. Тесты проверяют поведение. Логи и мониторинг показывают, что происходит в реальности. А человеческое ревью связывает все эти сигналы с реальной целью продукта.
Без таких feedback systems я доверял бы AI меньше, а не больше.
Главный прирост продуктивности — правильнее распределённое внимание
Проще всего сказать: «Codex экономит время». Но для меня это слишком слабое описание.
Самый дефицитный ресурс в разработке — не нажатия клавиш, а качественное внимание. До AI coding agents огромная часть этого внимания уходила на повторяющийся поиск: искать одни и те же паттерны, читать похожие файлы, прослеживать references, проверять, везде ли дошло изменение, а потом повторять тот же аудит уже в другом репозитории.
Теперь я могу намного больше такой работы первого прохода отдавать агенту, а своё внимание оставлять для того, что автоматизировать сложнее: действительно ли находка важна, вписывается ли fix в архитектуру, улучшится ли пользовательский опыт, приемлем ли риск и хочу ли я вообще это выпускать.
Именно поэтому поддержка и ревью множества проектов теперь ощущаются иначе. Я не ревьюю меньше. Во многих случаях я могу ревьюить больше именно потому, что механическая часть перестала съедать весь доступный ресурс.
Workflow, которому я доверяю
- Задать узкую цель ревью. Баги, тесты, SEO, локализация, рефакторинг или другая конкретная область.
- Сначала дать агенту исследовать, а не редактировать. Сначала мне нужны доказательства и затронутые места.
- Приоритизировать находки. Не каждая теоретическая проблема заслуживает изменения кода.
- Ограничивать размер изменений. Маленькие связные diff'ы проще проверять и понимать.
- Запускать машинные проверки. Typecheck, lint, tests, build, поиск или специфичные для проекта проверки.
- Ручное чтение diff. Я ищу ненужные переписывания, неверные предположения, пропущенные edge cases и изменения вне заданного scope.
- Проверять важное поведение. Особенно всё, что связано с пользователями, деньгами, security, SEO или production-инфраструктурой.
- Только после этого двигаться дальше. Параллельность полезна, но неразрешённая неопределённость не должна тихо переноситься дальше.
Пятнадцать проектов больше не ощущаются как пятнадцатикратный объём ревью
Codex не сделал 15 проектов простыми и не снял с меня ответственность. Он изменил отношение между масштабом и количеством повторяющейся работы.
Я могу позволить себе более глубокие первые проходы, более широкие проверки консистентности, больше идей для тестов и более системные аудиты, не тратя каждую минуту лично на поиск по каждому файлу. А освободившееся внимание могу оставить для решений, которым всё ещё нужен разработчик.
Именно такой AI-assisted development мне кажется полезным: не autopilot, не слепое доверие и не «генерируй код, пока что-нибудь не пройдёт». Это более плотный цикл между машинным масштабом исследования и человеческим масштабом суждения.
Для меня в этом и находится реальное усиление от Codex. Он не отменяет ревью. Он делает серьёзное ревью возможным на таком масштабе, который раньше было намного сложнее поддерживать.