Claude Opus 4.8: тестируем Claude на большом legacy PHP-проекте
Как проверить coding agent на reconstruction архитектуры, скрытых business rules, минимальном diff и честной работе с неизвестностью.

Opus 4.8 стоит проверять не на новом controller

28 мая 2026 года Anthropic представила Claude Opus 4.8. Компания показала рост в coding, agentic skills, reasoning и professional work, а отзывы ранних тестировщиков отдельно связала с более осторожным judgment на длинных задачах.

В собственных eval Anthropic модель примерно в четыре раза реже, чем Opus 4.7, оставляла незамеченными дефекты написанного ею кода. Одновременно Claude Code получил Dynamic Workflows: research preview для крупных задач, где система планирует работу, запускает сотни subagents и проверяет результат перед завершением.

Это заявления производителя, а не гарантия для конкретного проекта. Поэтому я бы не проверял релиз запросом «напиши Symfony Controller». Сильнее другой эксперимент:

Разберись в большом legacy PHP-проекте почти без документации, восстанови нужный business flow и только после этого предложи минимальное изменение.

Legacy проверяет способность восстановить систему

Удобный demo-repository уже сообщает модели половину ответа: src/Controller, src/Service, typed PHP, Composer, Docker и tests. Даже незнакомая codebase быстро складывается в знакомую схему.

Десятилетний проект на CodeIgniter 3 выглядит иначе:

application/
├── controllers/
├── models/
├── libraries/
├── helpers/
└── hooks/

cron/  scripts/  ajax/  api/  old/  third_party/

Оформление заказа проходит через controller, model, helper, billing library, внешний API и ночной cron. Admin при этом умеет менять тот же заказ в обход основного flow. README заканчивается на composer install.

Старый синтаксис здесь вторичен. Настоящая сложность — неявные зависимости, исключения без комментариев и несколько поколений business rules. Агенту нужно реконструировать модель системы, а не просто понять PHP 7.4.

Первый этап — research без права менять код

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

Восстанови lifecycle итоговой стоимости заказа. Найди все места, способные изменить цену после создания. Код пока не меняй.

Поиск по price, total, discount, amount и coupon даст кандидатов, но не архитектуру. После поиска придётся проследить вызовы, альтернативные entry points, scheduled jobs и записи в database.

Список из трёх файлов — слабый результат. Нужна карта поведения:

create order
  ↓ Order_model::create()
base total
  ↓ order_helper.php
discount
  ↓ Billing::calculateDelivery()
delivery
  ↓ cron/recalculate.php
nightly recalculation

Admin.php → manual total override

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

Хороший bug заставляет использовать symptom как улику

Следующая задача: «После ручного изменения заказа скидка иногда исчезает после полуночи». Плохой агент открывает Admin.php и правит первое подозрительное условие. Он реагирует на место ввода скидки, но игнорирует время сбоя.

Нормальное расследование начинается с вопроса: что запускается ночью?

Admin → manual discount → database
                         ↓
00:15 → cron → recalculate_order()
                         ↓
              manual discount lost

Причина распределена между admin flow, cron configuration и старой функцией пересчёта. Opus должна найти scheduled job, подтвердить, что он выбирает затронутые заказы, и показать, где именно теряется поле. Только после этого появляется основание для fix.

Этот сценарий оценивает reasoning лучше отдельной функции: модель должна связать temporal symptom с инфраструктурой и опровергнуть первое локальное объяснение.

Странный код может быть историческим контрактом

Legacy опасен тем, что плохой стиль и business rule выглядят одинаково. Например:

if ($user->type === 'manager' || $user->id === 417) {
    // Разрешить изменение заказа
}

Magic number просится в рефакторинг. Но пользователь 417 может оказаться integration account старого партнёра, поведение которого закреплено внешним договором. Документации нет, зато существуют import script и несколько записей в audit log.

Мой критерий простой: необычный код нельзя «улучшать», пока агент не нашёл usages, данные и исторические следы. В legacy действует порядок understand → constrain → change. Aggressive refactoring до исследования нужно считать ошибкой эксперимента, даже если итоговый код выглядит современнее.

Небольшая feature проверяет coverage и judgment

После onboarding можно дать изменение: пользователь не должен иметь больше пяти активных API-токенов, публичный API и формат ошибок менять нельзя.

В старом приложении token создаётся тремя путями:

POST /api/tokens     → Api.php
Admin action         → Users.php
CLI integration      → scripts/create_token.php

Проверка только в REST controller формально закроет endpoint, но не обеспечит invariant. Агент должен найти все entry points и выбрать место, через которое ограничение невозможно обойти.

Если service layer отсутствует, решение уже не механическое. Новый TokenService очистит архитектуру, но расширит scope. Три локальные правки проще, зато оставят duplication. Хороший результат объясняет компромисс и не превращает feature в незапрошенную архитектурную миграцию.

Отсутствие test suite не отменяет доказательства

В проекте на 120 000 строк может лежать один ExampleTest.php. Цикл «изменил → запустил PHPUnit → green» недоступен, но объявлять задачу завершённой всё равно нельзя.

Для bug со скидкой я бы ожидал pragmatic verification:

fixture database
  ↓
создать заказ с manual discount
  ↓
запустить тот же recalculation command
  ↓
сравнить order state и audit log
  ↓
проверить обычную скидку и заказ без скидки

Narrow integration test вокруг исправленного поведения полезнее попытки сначала перепроектировать весь CodeIgniter controller ради идеального unit testing. Если автоматизация слишком дорога, агент должен оставить воспроизводимую команду, fixture и фактический результат smoke check.

Проверяется не знание PHPUnit. Проверяется способность добыть достаточное evidence в неудобной среде.

Документация должна отделять факт от гипотезы

Исследование legacy даёт полезный побочный продукт — architecture map для следующего разработчика. Но категоричная фраза «Order_model — единственная точка создания заказов» опасна, если агент просто не заметил old_import.php.

Поэтому summary лучше хранить с уровнем evidence:

CONFIRMED
Найдены 3 entry points, указаны callers и SQL writes.

LIKELY
CLI script выглядит заброшенным: последнее найденное использование датировано 2019 годом.

UNKNOWN
Не удалось подтвердить, запускается ли old_import.php в production.

Opus 4.8 здесь интересно проверить именно на честности. Anthropic утверждает, что модель чаще отмечает неопределённость и реже заявляет о прогрессе без достаточных оснований. В legacy такой навык важнее уверенного тона: неизвестный cron должен остаться риском, а не исчезнуть из отчёта.

Subagents стоит запускать после общей карты

Dynamic Workflows позволяют планировать большие изменения и параллелить работу между множеством subagents. Anthropic приводит codebase-scale migrations на сотнях тысяч строк как основной класс задач. Для PHP это может быть переход с annotations на attributes, обновление Symfony или постепенное выделение CodeIgniter-модулей.

Но legacy нельзя безопасно разделить по папкам до reconstruction:

RESEARCH
   ↓
SHARED ARCHITECTURE MAP
   ↓
MIGRATION RULES + INVARIANTS
   ↓
PARALLEL WORK
   ↓
INTEGRATION VERIFICATION

Иначе Controller Agent и Cron Agent по-разному поймут порядок пересчёта цены и создадут согласованный лишь синтаксически результат. Несколько subagents одной модели могут одинаково ошибиться, поэтому критичные выводы полезно отдавать отдельному reviewer с задачей найти контрпример.

Эксперимент должен состоять из пяти этапов

Я бы проверял Opus 4.8 на одном snapshot проекта и не подсказывал файлы:

1. Onboarding: модули, entry points, integrations, jobs и рискованные области.
2. Reconstruction: полный order lifecycle с evidence и неизвестными.
3. Investigation: исчезающая после cron ручная скидка.
4. Implementation: минимальный fix без изменения остальных сценариев.
5. Verification: regression evidence, self-review diff и список непроверенного.

Эта последовательность отделяет красивое объяснение от реального понимания. Если архитектурная карта ошибочна, defect проявится на расследовании или реализации.

Сравнивать стоит discovery coverage, точность root cause, change surface, compatibility, качество evidence, число human interventions и review time. В статье о проектном benchmark для GPT-5.5 я уже использовал похожий scorecard; legacy добавляет к нему цену onboarding и честность в неизвестном контексте.

Успех — быстрое понимание, которому можно обоснованно доверять

Удачный результат выглядит не как «Claude написал рабочий PHP». Модель восстановила неочевидный flow, нашла root cause в нескольких частях системы, предложила локальный fix, проверила его доступными средствами и явно оставила список неизвестного. После этого человек быстро сверил evidence и принял решение.

Это продолжает тему Opus 4.7 и длинного инженерного делегирования, но поднимает планку. Теперь интересен не только размер задачи, а стоимость входа в систему, которую никто из текущей команды уже не держит в голове целиком.

Если Opus 4.8 сокращает такой onboarding с двух дней до нескольких часов и подтверждает выводы фактами, польза для PHP-команды возникает ещё до первой строки нового кода. Именно legacy может оказаться лучшим benchmark сильного coding agent: чистый проект проверяет генерацию, старый — инженерное понимание.