Claude Opus 5: насколько далеко можно отпустить coding agent
Как измерять полезную автономность через human attention, качество эскалаций, scope discipline и готовность diff к review.

Тестировать нужно автономность, а не генерацию кода

24 июля Anthropic представила Claude Opus 5. В официальном анонсе компания делает акцент на software engineering, длительной многошаговой работе и более тщательной проверке результата. После Opus 4.8 проверять такую модель Symfony-контроллером уже бессмысленно.

Нужна задача, которую разработчик выполнял бы несколько часов:

ISSUE
  ↓
RESEARCH
  ↓
PLAN
  ↓
IMPLEMENT
  ↓
TEST + DEBUG
  ↓
SELF-REVIEW
  ↓
REVIEWABLE DIFF

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

Автономность — не способность долго молчать. Это способность долго двигаться в правильном направлении, проверяя себя и вовремя останавливаясь перед неизвестным.

Runtime ничего не говорит без Attention Required

Трёхчасовая session с семнадцатью подсказками остаётся ручным программированием через AI. Если за те же три часа агент запросил два решения о backward compatibility, а исследование, implementation и debugging провёл сам, это уже делегирование.

Я бы фиксировал рядом два числа:

AGENT RUNTIME
180 min

HUMAN ATTENTION
12 min

Но и количество вопросов легко обманывает. «Где лежит TokenService?» — avoidable escalation: repository доступен агенту. «Использует ли внешний партнёр возможность повторно увидеть token?» — necessary escalation: ответ может существовать только в головах команды или production telemetry.

Полезная метрика должна разделять эти два класса. Сильный agent исчерпывает доступные evidence, затем формулирует короткий вопрос с найденными фактами и последствиями вариантов.

Эксперимент: убрать plaintext из API tokens

Для PHP-проекта я бы дал Opus 5 конкретную migration-задачу: перевести API tokens с plaintext на hash, сохранить публичный API и обеспечить постепенный переход существующих записей.

Простая формулировка скрывает несколько flows:

CREATE TOKEN
API + Admin + CLI

AUTHENTICATE
Authorization header → Authenticator → database

LIFECYCLE
revoke + rotate + audit + logs

Агент должен найти все точки создания и проверки, понять, где token показывается повторно, проверить логи и спроектировать переход. Например, новые строки получают token_hash и token_prefix, старые продолжают проходить через индексированный legacy lookup, а после успешной проверки мигрируют лениво и теряют plaintext.

Здесь быстро всплывают последствия: unique index для hash, одноразовый показ исходного token, rollback strategy и запрет утечки секрета в logs. Если Claude обнаружил их до review, он выполнял engineering, а не механическую замену колонки.

Task contract удерживает scope

На длинной работе сильная модель опасна тем, что умеет сделать больше, чем просили. Hash migration легко разрастается в новый security layer, repository abstraction и изменение response contract.

Поэтому перед запуском я зафиксировал бы контракт:

MUST CHANGE
- token storage
- authentication lookup
- data migration
- regression coverage

MUST NOT CHANGE
- routes
- client token format
- permission semantics
- unrelated security code

Через два часа первоначальные ограничения окружены сотнями search results и test failures. Long-running capability проявляется в том, что они продолжают управлять diff.

В scorecard стоит добавить scope preserved и unnecessary change surface. Восемь связанных файлов убедительнее тридцати семи файлов с «попутным улучшением архитектуры». Большая автономная работа должна уменьшать review surface, а не перекладывать на человека чтение 2500 лишних строк.

Green tests недостаточно: важны стратегия и восстановление

Команда phpunit после implementation ещё не доказывает качество. Для migration нужны отдельные сценарии: новый token работает, legacy token проходит и мигрирует, revoked legacy token отклоняется, plaintext исчезает, а повторный запрос аутентифицируется уже по hash.

Ожидаемый verification loop выглядит так:

failing migration test
        ↓
minimal implementation
        ↓
token security suite
        ↓
PHPStan
        ↓
related integration suite
        ↓
diff review

Падение первого варианта — не минус. Гораздо показательнее реакция. Агент может добавлять workaround за workaround или вернуться к assumption, признать неверный compatibility design и заменить подход.

Иногда лучший признак judgment — удалённый собственный код. Если выбранная схема создаёт race condition, час уже потраченной работы не должен превращаться в аргумент за третий patch.

Self-review полезен, но имеет потолок

После зелёных проверок я попросил бы Opus 5 сначала перечислить причины не принимать собственный diff: нарушение требований, security risk, производительность, rollback, missing tests и лишние изменения. Только затем — исправлять найденное.

Anthropic пишет, что Opus 5 стала сильнее в verification и итеративном исправлении результата. Это стоит проверять по конкретным находкам: заметила ли модель отсутствующий index, оставшийся CLI path или plaintext в audit log.

Но автор и reviewer всё ещё разделяют исходные assumptions. Если Claude решила, что старый integration не используется, она может пронести ошибку и через self-review. Материал Anthropic о harness design для long-running development прямо отмечает склонность agents слишком благосклонно оценивать собственную работу и пользу отдельного evaluator.

Надёжная цепочка для критичной migration остаётся такой:

IMPLEMENTER
  ↓
SELF-REVIEW
  ↓
INDEPENDENT REVIEWER
  ↓
HUMAN

Сначала один агент и честный scorecard

Subagents могут разделить research, tests и review, но первый эксперимент с Opus 5 я бы не усложнял. Иначе улучшение модели невозможно отделить от orchestration. Baseline должен быть простым: одна session, один repository, одна большая задача.

Журнал выполнения нужен не для чтения каждого grep, а для оценки траектории:

task completed
human attention minutes
necessary / avoidable escalations
wrong turns and recoveries
scope preserved
verification performed
architectural consequences found
major review issues
ready to merge?

Сравнивая Opus 5 с Opus 4.8, я смотрел бы не только на runtime. Три часа без надзора могут быть продуктивнее двух часов, из которых разработчик девяносто минут возвращал агента в scope.

Исследование Anthropic примерно 400 тысяч Claude Code sessions уже показывает разделение: человек чаще принимает planning-решения, Claude — execution-решения; опытные пользователи получают больше работы на одну инструкцию. Но авторы не знают, был ли полученный код затем принят или отброшен. Наш scorecard должен заканчиваться human review, а не ответом агента DONE.

Горизонт задаёт весь stack, а не одна модель

Несколько часов — только первый уровень. Дальше появляются context drift, failed CI, изменившиеся dependencies, merge conflicts и передача состояния между sessions. Ранний long-running harness Anthropic использовал task list, progress artifacts и проверку состояния среды именно потому, что одного compaction недостаточно.

USEFUL AUTONOMY
= model judgment
+ task contract
+ environment
+ persistent state
+ verification
+ checkpoints

Opus 5 усиливает первый компонент. Собственная VM, Skills, approvals и хорошие handoff artifacts отвечают за остальные. Поэтому рост модели не отменяет agent engineering — он позволяет убрать часть старого scaffolding и увеличить расстояние между контрольными точками.

Сюда естественно подключаются мобильный supervision и изолированные cloud workers: разработчик не сидит рядом, но остаётся доступен для редкого business decision.

Главная метрика — полезная работа до вмешательства

Успешный эксперимент — не «Claude работала четыре часа». За это время Opus 5 должна сохранить scope, сама исправить implementation failures, провести осмысленную verification, заметить последствия и принести небольшой diff без фундаментальной ошибки на human review.

Хорошая автономность включает умение остановиться. Если по repository нельзя понять, использует ли партнёр старый endpoint, продолжение работы будет не инициативностью, а выдумыванием business context.

Измерять стоит useful autonomous work before human intervention: сколько проверенной инженерной работы агент выполнил до первого действительно необходимого решения человека.

Если Opus 5 стабильно увеличивает этот участок, меняется единица делегирования. Разработчик задаёт цель и границы, уходит заниматься другой работой и возвращается не для того, чтобы направлять следующий tool call, а чтобы принять инженерный результат.