GPT-5.5 в Codex: почему benchmark по PHP уже почти ничего не говорит
Почему coding models пора сравнивать на реальных issues — по исследованию repository, качеству решения, tests, размеру diff и времени review.

Новый score, старая единица измерения

23 апреля 2026 года OpenAI представила GPT-5.5. В launch-анонсе компания показала 82,7% на Terminal-Bench 2.0 и 58,6% на SWE-Bench Pro. Там же появился Expert-SWE — внутренний eval для long-horizon coding tasks, медианная оценка человеческой работы над которыми составляет около 20 часов.

Сами числа можно обсуждать отдельно: harness, доступные tools и методика grader меняют результат. Для меня релиз интереснее другим. OpenAI описывает GPT-5.5 как модель для полного engineering workflow — codebase navigation, planning, implementation, debugging, testing и verification. На этом фоне вопрос «какая модель лучше пишет PHP» измеряет слишком маленький участок работы.

старый объект сравнения: prompt → PHP code

новый объект сравнения: issue → исследование → diff → доказательства

PHP никуда не исчез. Просто syntactic correctness перестала быть главным bottleneck для сильных frontier-моделей.

Генерация функции хорошо проверяла autocomplete

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

человек понял задачу
      ↓
человек нашёл место изменения
      ↓
человек выбрал решение
      ↓
AI сгенерировал код

Можно было сравнить типы, стиль framework, обработку ошибок и читаемость. Запрос «сгруппируй заказы по пользователю» действительно проверял значимую часть возможностей chat-based coding.

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

Coding agent получает issue, а не заготовку функции

Реальная задача для Codex может звучать так:

После перехода на новый механизм скидок часть заказов с несколькими промокодами получает неправильную итоговую стоимость. Найди причину, исправь её без изменения API и добавь regression tests.

В prompt нет имени класса, готовой гипотезы и списка команд. Агенту нужно самому пройти маршрут:

ISSUE
  ↓
RESEARCH → REPRODUCE → PLAN → IMPLEMENT
                              ↓
FINAL DIFF ← REVIEW ← DEBUG ← TEST

Генерация PHP занимает здесь несколько минут. Качество задачи чаще теряется раньше: агент не заметил второй calculator, не воспроизвёл комбинацию промокодов или принял устаревший test fixture за business rule.

Первый eval — понял ли агент существующую систему

Возьмём другой issue: пользователь иногда получает 403 после изменения роли. Плохой агент ищет строку 403, открывает первый controller и ослабляет условие. Diff компилируется, но причина остаётся.

Нормальное исследование выглядит иначе:

role update
  ↓
UserService → entity listeners → security voter
  ↓                             ↓
permission cache          existing regressions
  ↓
гипотеза: cache не инвалидируется после изменения role

Benchmark должен оценивать discovery coverage: нашёл ли агент authentication flow, место обновления роли, cache layer и уже принятый проектом способ invalidation. Красивый Symfony-код не компенсирует неверную карту системы.

Этот критерий плохо помещается в одиночный answer. Нужны action log, список прочитанных файлов и связь между найденными фактами и выбранной гипотезой.

Второй eval — решение и локальность diff

После исследования остаётся выбор. Полное отключение permission cache устранит 403, но создаст performance regression. Точечная invalidation после смены роли сохраняет архитектуру и решает исходную проблему.

Обе реализации могут пройти узкий test. Поэтому я смотрю ещё на отношение:

полезное изменение
──────────────────
фактический diff

Если bugfix внезапно затронул PermissionService, User entity, security config, cache abstraction, DTO и двадцать tests, reviewer платит за весь этот scope. Большой diff не обязательно плох, но агент должен доказать необходимость каждой расширенной границы.

В проектном eval полезно считать изменённые файлы, строки вне исходного subsystem и новые abstractions. Метрика грубая, зато быстро выявляет модели, которые используют каждую задачу как повод для архитектурного ремонта.

Tests перестают быть бинарной галочкой

Строка tests pass не объясняет, что именно проверено. Агент мог запустить один новый unit test, написанный после реализации и повторяющий её предпосылки. Для regression этого мало.

Сильнее выглядит последовательность:

воспроизвести bug
      ↓
добавить failing regression test
      ↓
сделать минимальный fix
      ↓
запустить новый test + существующий relevant suite
      ↓
проверить итоговый diff

Особенно показательно поведение после первого failure. Случайная серия правок говорит о слабом debugging loop. Чтение stack trace, обновление гипотезы и targeted fix — уже инженерная работа.

Официальная model guidance GPT-5.5 прямо советует задавать acceptance criteria, evidence rules и stopping conditions, а модели давать tools для проверки результата. Это уже спецификация agent loop, а не подсказка по синтаксису.

Terminal-Bench, SWE-Bench и Expert-SWE измеряют разные горизонты

Terminal-Bench 2.0 проверяет многошаговую работу через command line: планирование, tool coordination и восстановление после ошибок. SWE-Bench Pro начинает с repository issue и требует привести проект к рабочему состоянию. Expert-SWE, по описанию OpenAI, двигает горизонт к задачам, на которые человек потратил бы десятки часов.

function benchmark  → качество фрагмента
terminal benchmark  → качество execution loop
repository issue    → task completion
long-horizon eval   → устойчивость инженерной работы

82,7% и 58,6% полезны в рамках зафиксированной методики. Они не обещают тот же pass rate на Laravel-монолите вашей команды. Особенно если отличаются environment, network, dependencies, project instructions или скорость test suite.

Главное изменение — формат задания. Единицей оценки постепенно становится не ответ модели, а состояние repository после завершения агента.

PHP eval должен быть проектным

Я бы не просил четыре модели написать одинаковый Symfony Voter. Большинство сильных моделей выдадут приемлемый class. Вместо этого нужен один реальный snapshot проекта и несколько issues разных типов:

BUG          reset token остаётся валидным после смены email
REFACTORING  permission checks → Symfony Voters без смены поведения
FEATURE      деактивация API token через существующий REST API
MIGRATION    deprecated Symfony API → актуальный контракт
PERFORMANCE  N+1 в списке заказов

Каждая модель получает repository, issue, одинаковый tool surface и acceptance criteria. Не получает список файлов, готовый plan и скрытые regression tests. Человеческие вмешательства записываются дословно.

Такой набор проверяет PHP и framework knowledge в контексте, где они действительно нужны. Ошибка в API Symfony проявится при container build. Ошибка в архитектуре — в размере diff или review. Пропущенное business rule поймают скрытые tests.

Модель всё равно нельзя отделить от harness

GPT-5.5 внутри Codex работает не в вакууме. Результат создаёт связка:

GPT-5.5
  + context management
  + tools
  + project instructions
  + execution loop
  + environment
  = coding agent

Та же модель в другом agent harness может выбрать иной контекст, получить менее удобный terminal output или раньше остановиться. Я уже разбирал эту границу в сравнении Claude Opus 4.6 и GPT-5.3-Codex. Пользовательский eval Codex + GPT-5.5 измеряет продуктовую систему; выдавать его за чистое сравнение weights некорректно.

Это связывает релиз и с Composer 2: Cursor обучает модель под собственную agentic environment, OpenAI настраивает GPT-5.5 под tool-heavy и long-running workflows. Индустрия оптимизирует весь маршрут, а не один code completion.

Считать нужно время и стоимость принятого issue

Model A работает 12 минут, меняет 42 файла и оставляет 90 минут review. Model B работает 25 минут, меняет восемь файлов и проверяется за четверть часа. По response time победила первая. По developer experience — вторая.

TOTAL ENGINEERING TIME
= agent runtime
+ human interventions
+ review
+ исправление regressions

Стоимость тоже стоит считать на успешно принятый issue. Официальная документация отмечает, что GPT-5.5 достигает сильных результатов с меньшим количеством reasoning tokens относительно предыдущих моделей при том же effort. В длинном loop экономия на одном turn складывается, но дешёвый незавершённый запуск всё равно дороже более затратного результата, который дошёл до merge.

В scorecard я бы оставил семь строк: task completion, human interventions, test quality, diff locality, regressions, review time и total cost. Benchmark score модели будет только вводной.

Новый вопрос к coding model

Вопрос «какая модель лучше пишет PHP» не стал полностью бессмысленным. Он всё ещё ловит слабое знание языка, framework hallucinations и плохой стиль. Просто для frontier coding agents это нижний порог, а не итоговая оценка.

Практический bottleneck переместился: понял ли агент repository, выбрал ли локальное решение, воспроизвёл ли bug, пережил ли failure, сохранил ли constraints и оставил ли понятные доказательства.

Поэтому главный сигнал GPT-5.5 я вижу не в отдельном результате Terminal-Bench. Релиз закрепляет новую единицу сравнения:

реальное issue
      ↓
agentic stack
      ↓
небольшой, понятный и проверенный diff
      ↓
минимальное active attention разработчика

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