Тут The Register пересказал инженерный блог Anthropic, что мае этого года компания мержила в основную ветку около 2500 изменений в день, к сентябрю уже больше 30 000. Рост более чем в 12 раз потянул за собой инфраструктуру. CI делает около 25 миллионов чекаутов в сутки, и под такую нагрузку компания строит собственную систему контроля версий. В блоге о новом хранилище кода инженеры пишут, что очень часто их роль сводилась к тому, чтобы сказать Claude «нет», потому что агенты иногда нарушают ключевые ограничения системы ради шаблона, который в этом месте не нужен.

Еще, косвенный признак дает колонка Джона Стояна на InfoWorld. Он пишет, что коммитов стало больше, а пул-реквесты двигаются быстрее, зато многие организации сообщают о замедлении деплоев. Механизм он называет следующий: циклы ревью, терпимые на человеческой скорости письма, становятся ограничением, когда разработчики с ИИ выдают в два-три раза больше кода.

Что у меня ускорилось, а что нет?

Ради оптимизации расходов, работа у меня построена так: Код пишет Codex, а задачи ему ставит сессия проекта на Claude (она читает дифф, гоняет тесты и сборку). Над сессиями сидит общий координатор на Claude Opus 5.5, а я уже смотрю итог и решаю, что делать, и на прод все выкатывается только после моей проверки.

Быстрее всего стало с заготовками. Скелет нового сервиса с сессиями, защитой от CSRF и воркером очереди Codex пишет целиком, мне на такое было бы нужно несколько дней. Ускорились и однообразные вещи: обвязка тестов, миграции, правки по списку замечаний.

Проверка на проде осталась медленной. Каждую выкатку я смотрю руками, и параллельно ее не пустишь так, как пишут код. Решение, нужна ли фича вообще, тоже остается за мной.

Что ревью ловит, а что проходит мимо?

Claude при чтении диффа очень хорошо видит расхождения внутри кода. Однажды он проревьюил несколько моих продуктов с платежами, код которых в разное время писали Codex и сами сессии, и нашел в них общую дыру, когда сумма в уведомлении платежной системы не сверялась с суммой заказа. Все ревью делал один Opus 5.5, поэтому повтор может объясняться и общим автором кода, и чек-листом самого Opus. Если дело в авторе, ревью ловит ошибки, которые модель повторяет из раза в раз.

Я вижу только то, что ревьюер нашел, а пропущенного не вижу. Вот что ревью не нашло и что поймали проверки в пайплайне и прод:

• аудит зависимостей остановил деплой на тестовый контур из-за двух критических уязвимостей во фреймворке, и ни ревью, ни зеленые тесты этого не заметили;

• сборка под нестандартным umask выдала файлам права, при которых процессы под другим пользователем их не читали, и сервисы упали через несколько минут после выкатки;

• деплой архивом (tar) оставил на проде файлы, давно удаленные из git, и сломал сборку фронтенда;

• правки по ревью тоже ломают: один пакет оставил в разметке непарный закрывающий тег, и поймало это только следующее ревью.

Где хватает агента, а где нужен человек?

Агентам я отдаю вопросы вида «соответствует ли код контракту»: расхождение типов, непокрытая ветка, гонка в счетчике, забытая проверка прав. На каждую находку я прошу тест, который воспроизводит баг. Без такого теста ревью от Opus 5.5 остается просто мнением.

Отчеты самих агентов я тоже проверяю. Однажды сессия отчиталась, что периодическая проверка ключа нигде не вызывается. Координатор на Opus 5.5 перепроверил и нашел задачу по расписанию, которая вызывала ее каждые десять минут. Сессия просто не открыла файл с расписанием. Заявление агента без ссылки на проверку по первоисточнику я теперь за факт не считаю.

Что измерять вместо количества PR?

Число пул-реквестов растет само и не говорит, дошла ли работа до пользователя. Из них я пока считаю только долю исправлений.

• Время от готового кода до прода. В нем прячутся очередь на ревью, пайплайн и ожидание моей команды.

• Доля дефектов, дошедших до прода. Пойманные до выкатки сюда не входят.

• Доля коммитов с исправлениями. Если она растет вместе с объемом кода, за скорость я плачу переделками.

• Стоимость задачи. Исследование, на которое ссылается VentureBeat, опубликовано на arXiv под названием «What Does a Harness Buy? Tokens, Mostly». При одной модели и одних задачах цена за задачу у разных оболочек агента (harness) отличалась до трех раз, а самая тяжелая и самая легкая оболочки на 447 задачах, по аннотации, оказались равны по точности в пределах пяти пунктов. Разницу видно только по счету за токены, и для этого нужен учет по задачам.

Первые три показателя берутся из git, журнала деплоев и трекера инцидентов, а для четвертого нужен учет токенов по задачам.

Какие правила я ввел

Большинство правил появилось после инцидентов.

1. Задача закрыта, когда проверено на проде, то есть сделан запрос к рабочему API, открыта страница и в логе нет ошибок. Зеленых тестов для этого мало.

2. Перед выкаткой сессия гоняет полную сборку, потому что проверка типов пропускает то, что роняет билд на проде.

3. Каждая находка ревью получает тест, который воспроизводит баг. Без теста я правку не принимаю.

4. Деплой не должен стирать чужие правки: сессии коммитят сразу и не пушат в ветку с автодеплоем, пока соседняя сессия не зафиксировала свои изменения.

5. На прод сессия выкатывает только по моей прямой команде, даже если CI зеленый.

У этих правил есть цена, ведь проверка на проде отнимает время и плохо параллелится, а каждый тест добавляет кода, который тоже надо читать, и где эта цена перевешивает пользу, я пока не знаю.