Claude Opus 4.7: когда AI можно отдавать действительно сложные задачи
Как проверить модель на long-running refactoring, удержании инвариантов, самостоятельной верификации и реальной стоимости human supervision.

Новая единица делегирования

16 апреля 2026 года Anthropic выпустила Claude Opus 4.7. Компания заявляет самый заметный прирост относительно Opus 4.6 в advanced software engineering, особенно на трудных заданиях. В описании повторяются три свойства: устойчивость на long-running tasks, точное следование инструкциям и привычка искать способ проверить результат до завершения работы.

Это всё ещё заявления производителя и early-access клиентов. Новый score сам по себе не говорит, что модель можно оставить на ночь в любом repository. Но он подсказывает более полезный эксперимент, чем генерация очередного controller.

Я бы проверял Opus 4.7 на задаче, которую senior-разработчик делал бы несколько часов:

Переведи legacy-систему permissions на Symfony Voters. Не меняй routes, public API, HTTP statuses и фактическую permission semantics. Сначала исследуй проект, затем подготовь plan, реализуй migration и докажи, что поведение сохранилось.

Здесь единицей делегирования становится не функция и даже не feature. Агент получает цель, скрытый контекст, архитектурное ограничение и обязанность проверить собственную работу.

Сложность не измеряется количеством файлов

CRUD для пользователей может затронуть Entity, Repository, Service, Controller, DTO и tests. Diff большой, но маршрут предсказуем. Гораздо сложнее заменить внутренний механизм, сохранив наблюдаемое поведение системы.

PermissionService + ручные checks + legacy helpers
                         ↓
                    Symfony Voters
                         ↓
routes, responses, statuses и business rules не меняются

Такая работа требует сначала реконструировать правила, а уже потом писать PHP. Вызов canEditOrder() может скрывать администратора, менеджера своего отдела, автора заказа в статусе DRAFT, исключение для архива и отдельную support-role. Части этой логики часто разбросаны по service, controller, subscriber, Twig extension и старым regression tests.

Написать Voter по готовой таблице правил несложно. Настоящий тест — сможет ли агент сам собрать эту таблицу и заметить противоречия, не выдумывая новое поведение.

Сложная задача начинается с карты, а не с diff

Первый этап я бы отделил жёстко: исследуй, но код не меняй. Агент должен найти все вызовы PermissionService, прямые проверки ролей, условия в templates, security config, связанные entities и тесты.

Permissions
├── Orders
│   ├── VIEW     → PermissionService + Twig
│   ├── EDIT     → Service + Controller
│   ├── DELETE   → Controller
│   └── APPROVE  → Subscriber
├── Customers
│   ├── VIEW
│   └── EDIT
└── Reports
    └── EXPORT

Хороший research-result содержит не только список файлов. Для каждого action нужны текущие условия, источник правила, существующее test coverage и неоднозначности. Если документация говорит одно, а integration test фиксирует другое, агент обязан поднять конфликт, а не выбрать удобную версию.

Ошибка на этом этапе дорогая. Технически аккуратный Voter и зелёные новые unit tests не спасут migration, если исходная модель permissions восстановлена неверно.

Длинная работа проверяет способность удерживать инварианты

Для migration важнее всего список того, что запрещено менять:

INVARIANTS
- routes и request format
- response body и HTTP statuses
- имена ролей
- доступ для существующих пользователей
- порядок security checks
- публичные service contracts

Десятки tool calls отделяют исходный prompt от последнего patch. Агент ищет usages, читает tests, проектирует voters, меняет controllers, получает failure и возвращается к реализации. На каждом переходе есть шанс забыть ограничение или незаметно расширить scope.

Именно здесь long-running capability становится инженерным свойством. Ценность модели определяется не лучшим отдельным решением, а качеством всей цепочки:

goal → research → decision → tool → observation
  ↑                                      ↓
  └──── correction ← verification ← change

Неверно понятое business rule порождает правильный код для неправильной системы. Чем длиннее rollout, тем важнее, чтобы модель возвращалась к исходным инвариантам после каждого крупного изменения.

Supervision — скрытая стоимость агента

Допустим, senior выполнил бы migration за четыре часа, а Claude закончила за час. Это выглядит как четырёхкратное ускорение только до тех пор, пока человек не провёл весь этот час рядом, исправляя направление, добавляя контекст и подтверждая каждый безопасный шаг.

Поэтому для Opus 4.7 я бы измерял две величины отдельно:

wall-clock time агента
                ≠
active attention разработчика

Полезный сценарий выглядит иначе. В 09:00 разработчик формулирует задачу и acceptance criteria. В 11:30 он возвращается к карте исследования, diff, тестам и журналу найденных проблем. Между этими точками агент сам прошёл research, implementation и несколько test loops.

Anthropic пишет, что сложную работу, прежде требовавшую близкого контроля, early users передают Opus 4.7 увереннее. Я бы воспринимал это как гипотезу для локального eval: сколько минут человеческого внимания потребовалось на задачу и в какие моменты без вмешательства возник бы неверный результат.

Self-verification должно пытаться опровергнуть diff

Плохой агент заканчивает после того, как код выглядит убедительно. Хороший ищет контрпример. Для permission migration одной проверки мало, поэтому я бы зафиксировал четыре слоя.

Static correctness

PHP syntax, PHPStan или Psalm, сборка Symfony container и coding standards ловят сломанные зависимости, сигнатуры и configuration errors. Это дешёвый первый барьер, но он ничего не доказывает о business semantics.

Новые unit tests

OrderVoterTest и CustomerVoterTest должны покрывать восстановленную матрицу ролей, статусов и ownership. Они полезны ещё и как явная документация решения.

Старые regression и integration tests

Именно старый suite подтверждает обещание «внешнее поведение не изменилось». Новые тесты модель пишет из собственной картины мира; старые с большей вероятностью поймают ошибочную предпосылку.

Review итогового diff

После зелёных tests агент должен заново найти оставшиеся ручные checks, duplicated rules, лишние изменения и случайно затронутые contracts. Команда git diff здесь не отчётность, а отдельный этап проверки.

Reasoning и review получают отдельный бюджет

Вместе с моделью Anthropic добавила уровень effort xhigh между high и max. Для coding и agentic workloads компания советует начинать с high или xhigh, а Claude Code использует xhigh для Opus 4.7 по умолчанию.

В API появились task budgets в public beta: разработчик может направлять token spend на длинную работу. Это уже похоже на engineering budget. Переименование DTO не оправдывает дорогой rollout; migration permissions — оправдывает, если дополнительное reasoning снижает supervision и вероятность повторной работы.

Новая команда Claude Code /ultrareview создаёт отдельную review-сессию, которая читает изменения и ищет bugs и design issues. Сам факт отдельной команды хорошо показывает сдвиг:

раньше: WRITE

теперь: RESEARCH → IMPLEMENT → VERIFY → REVIEW

Генерация стала одним этапом pipeline. Но review той же моделью остаётся связанным: она может унаследовать собственную ошибочную интерпретацию. Для рискованного refactoring я бы использовал /ultrareview как дополнительный слой, а не как замену независимой проверке.

Большой scope требует разделения ролей

Чем больше работа одного агента, тем выше цена общей ошибочной предпосылки. Поэтому сильная модель делает multi-agent workflow не менее, а более уместным.

IMPLEMENTER
исследует систему, делает migration, запускает tests
              ↓
             DIFF
          ↙        ↘
   REVIEWER        VERIFIER
ищет ошибки      строит контрпримеры
          ↘        ↙
          HUMAN REVIEW

Reviewer получает исходную задачу и запрет доверять выводам implementer. Он проверяет coverage всех permission checks, сохранение API и размер scope. Verifier сравнивает старую и новую систему на edge cases: архивный заказ, support-role, смена отдела, отсутствие owner и переход статуса во время запроса.

Разделение ролей не гарантирует независимость, особенно если все агенты используют одну модель и один контекст. Но разные prompts, чистая сессия, скрытые acceptance tests и при необходимости другая модель уменьшают риск согласованной ошибки.

Сложная задача не означает право выбрать любую архитектуру

Есть разница между senior-задачей и правом принимать senior-решение. Формулировка «мы переходим с PermissionService на Symfony Voters; исследуй детали, реализуй и проверь» оставляет архитектурное направление человеку. Формулировка «permissions работают плохо; переделай как считаешь нужным» передаёт модели гораздо больше ответственности.

LEVEL 1  написать функцию
LEVEL 2  реализовать feature
LEVEL 3  исследовать и реализовать feature
LEVEL 4  провести сложный refactoring и доказать совместимость
LEVEL 5  самостоятельно выбрать архитектурное направление

Практический интерес Opus 4.7 — в движении к третьему и четвёртому уровням. Пятый требует другой модели governance: явной фиксации решения, threat analysis, review нескольких вариантов и человеческого владельца архитектуры.

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

Главная метрика — время до доверия

Для эксперимента с Voters я бы записывал не только pass rate и размер diff. Нужны точность карты существующей системы, число пропущенных checks, сохранение semantics, лишний refactoring, найденные агентом собственные ошибки и количество человеческих вмешательств.

Есть ещё одна метрика, которая ближе всего к ежедневной разработке:

task → agent result → review → confidence

time to trust = время человека до решения «можно принимать»

Агент может закончить за 30 минут и оставить три часа запутанного review. Другой работает два часа, но приносит карту решений, маленький diff, доказательства тестов и список оставшихся сомнений — senior проверяет его за двадцать минут. Второй результат ценнее.

Именно поэтому Opus 4.7 интересна не скоростью генерации PHP. Проверять нужно границу делегирования: какую инженерную задачу модель способна пройти целиком, сохранив ограничения и подготовив результат, который разумно ревьюить как работу другого разработчика.

Если эта граница действительно сдвигается, меняется сама единица AI-разработки. Раньше модели отдавали фрагмент кода. Теперь агенту можно поручать исследование, migration и доказательство совместимости — но право окончательно доверять результату всё ещё остаётся у инженера.