Anthropic использует Claude Code для ежедневного автономного обслуживания собственного программного обеспечения. По данным компании, разработчики объединяют с основной кодовой базой 46% изменений, предложенных системой, — это редкий публичный показатель реальной полезности AI-агента.
Суть события
Claude Code регулярно получает задачи по поддержке внутренних программных проектов Anthropic: ищет небольшие неисправности, готовит изменения и отправляет их на проверку. Люди сохраняют контроль над принятием результата, но часть рутинного обслуживания уже выполняется без ручного запуска каждой отдельной операции.
Показатель в 46% означает не точность модели и не долю кода, написанного AI. Это доля подготовленных изменений, которые после проверки дошли до объединения с основной кодовой базой. Остальные предложения могли быть отклонены, потребовать доработки или потерять актуальность.
Детали
Ежедневный режим отличается от обычного помощника программиста. Агент должен самостоятельно найти подходящую задачу, понять репозиторий, внести ограниченное изменение, выполнить проверки и оформить результат так, чтобы разработчик мог быстро принять решение.
Такой процесс требует строгих разрешений, журналирования и автоматических тестов. В статье о безопасном авторежиме Claude Code мы разбирали, почему границы доступа важнее обещания полной автономности.
Контекст
Компании давно измеряют AI числом сгенерированных строк, но эта метрика почти ничего не говорит о пользе. Доля принятых изменений ближе к рабочему результату: код прошёл человеческую проверку и оказался достаточно полезным для продукта.
При этом 46% нельзя переносить на любую команду. Результат зависит от качества тестов, структуры репозитория, сложности задач и времени ревью. Сравнение AI-ассистентов для программирования помогает понять, почему одна и та же модель по-разному работает в разных процессах.
Что дальше
Если практика масштабируется, AI-агенты будут забирать всё больше профилактических задач: обновления зависимостей, исправление предупреждений, документацию и небольшие тесты. Разработчики смогут сосредоточиться на архитектуре и изменениях с высокой ценой ошибки. При этом ответственность за выпуск остаётся у команды: автономная подготовка изменения не должна автоматически означать автономное развёртывание в рабочей среде.
Главная метрика — не количество созданных запросов на изменение, а экономия времени после учёта проверок и исправлений. Командам стоит начинать с безопасных классов задач и отдельно отслеживать принятые изменения, возвраты и дефекты после выпуска.
