GPT-5.6 Sol: куда движется coding agent после GPT-5.5
Как сравнивать frontier-модели по execution trace, supervision cost и доле задач, которые заканчиваются mergeable PR.

Preview без преждевременного вердикта

26 июня GPT-5.6 Sol появился в ограниченном preview. По нескольким удачным сессиям легко объявить модель новым стандартом, особенно если показывать задачи, где заранее известны нужный файл и форма решения. Я бы не делал этого.

Официальный анонс limited preview описывает Sol как flagship-модель GPT-5.6 для complex professional work. Но такое позиционирование ещё не отвечает на практический вопрос: насколько надёжно она проходит длинную coding-задачу внутри реального agent harness.

После GPT-5.5 меня интересует уже не качество отдельного Symfony service. Полезная граница проходит дальше:

ISSUE
  ↓
RESEARCH
  ↓
PLAN
  ↓
IMPLEMENT
  ↓
TEST + DEBUG
  ↓
REVIEW
  ↓
MERGEABLE DIFF

Первый тест Sol должен измерять не эффектность результата, а объём инженерной работы, который модель проходит без тактических подсказок разработчика.

Убирать нужно подсказки, а не контекст

Фраза «дай модели только issue» звучит строго, но её легко применить неправильно. Агент всё равно должен получить AGENTS.md, команды запуска, архитектурные ограничения, approval boundaries и критерий готовности. Без этого проверяется способность угадывать правила команды.

Убрать стоит другое:

не говорить:
- открой PermissionService.php;
- причина, вероятно, в Redis;
- запусти SecurityTest;
- добавь listener после RoleChangedEvent.

Задача остаётся короткой: «После изменения роли пользователь несколько минут сохраняет старые права. Найди причину, исправь её без изменения API и добавь regression coverage».

Это совпадает с рекомендациями OpenAI для GPT-5.6: модель лучше выводит намерение из контекста, но ей по-прежнему нужно явно задавать hard constraints, границы действий и success criteria. Автономность не требует скрывать правила игры.

Одинаковый diff может скрывать разную работу

Допустим, GPT-5.5 и Sol в итоге добавили одинаковую cache invalidation. Если смотреть только финальный patch, получится ничья.

Но первая session могла пройти такой путь:

wrong hypothesis
↓
broad change
↓
test failure
↓
second workaround
↓
human correction
↓
final fix

А вторая — сначала проследить role update, проверить Redis state до и после события, воспроизвести устаревший access decision и только затем изменить listener. Результат одинаковый, доверие к нему — нет.

Поэтому я сохранял бы execution trace: просмотренные области, проверенные hypotheses, test iterations, откаты плана и вмешательства человека. Без trace сравнение быстро превращается в «Sol показалась внимательнее».

Главная метрика — supervision cost

Clock time плохо описывает agentic работу. GPT-5.5 может закончить задачу за 52 минуты и пять раз выдернуть разработчика. Sol — работать 67 минут, но запросить одно решение о backward compatibility. Для моего рабочего дня второй вариант быстрее.

Количество сообщений тоже недостаточно. «Используй существующий Voter» и «ты исследовал не тот flow, откати изменения и начни заново» формально считаются одним intervention, хотя стоимость отличается на порядок.

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

SUPERVISION EVENTS
сколько раз понадобился человек

SUPERVISION MINUTES
сколько внимания заняли решения,
проверка направления и восстановление после ошибок

Так становится видно, действительно ли модель взяла на себя среднюю часть workflow или лишь быстро печатала код под постоянным руководством.

Сильный агент сначала добывает evidence

Гипотеза «виноват Redis» ничего не стоит, пока агент не нашёл cache writes, invalidation path и воспроизводимый сценарий. Центральный навык coding agent — не рассуждение само по себе, а цикл:

REASON
  ↓
ACT
  ↓
OBSERVE
  ↓
UPDATE HYPOTHESIS

Для duplicate webhook я ожидал бы проверки event dispatch, retry policy, transaction boundary и idempotency key. Если Sol меняет первый подозрительный handler без reproduction, её код может быть красивым, но эксперимент провален.

Хороший финальный отчёт должен связывать каждый важный вывод с наблюдением: failure до fix, изменившееся состояние после fix, зелёный regression test и перечень сценариев, которые агент не смог проверить.

Три задачи вместо двадцати игрушечных benchmark

Для первого сравнения я взял бы один production-like Symfony-проект: PostgreSQL, Redis, Messenger, PHPUnit и PHPStan. Затем — три задачи из настоящего backlog.

Bug: duplicate webhook

Root cause спрятан между retry policy и transaction boundary. Оцениваем reproduction, evidence, regression test и минимальность исправления.

Feature: временная блокировка API token

Агент сам находит creation и validation paths, сохраняет API contract и не строит новый policy engine ради одного nullable timestamp.

Refactoring: PermissionService → Voters

Здесь важны полнота поиска, сохранение permission semantics и способность пересмотреть migration strategy, если старые integration tests показывают системную ошибку.

Такой набор проверяет investigation, restraint и long-horizon consistency. Генерация PHP присутствует во всех трёх задачах, но нигде не является главным bottleneck.

Сравнение должно быть воспроизводимым

Обе модели получают одинаковые repository state, project instructions, tools, sandbox permissions и task prompt. Каждая стартует в fresh branch и новой agent session. Решение первой модели второй не показывается.

Reasoning effort тоже нельзя менять по настроению. OpenAI советует при переходе с GPT-5.5 сохранить текущий effort как baseline, а затем отдельно проверить уровень ниже. Для первого прогона я бы оставил одинаковый effort, иначе сравниваются сразу две переменные.

После завершения таблица должна содержать:

task completed?
major rework required?
human supervision minutes
wrong turns and recoveries
test iterations
files changed
unnecessary change surface
total cost
human review time

Особенно показателен последний пункт. Двадцатиминутный run с полуторачасовым review проигрывает сорокаминутному run, который оставил небольшой и объяснимый diff.

Единицей оценки становится pull request

Функция проверяет знание языка. Issue добавляет поиск причины. Production-ready PR включает ещё архитектурное решение, tests, совместимость, документацию и удобство review.

Поэтому итоговый вопрос для Sol я сформулировал бы жёстко:

Какой процент задач заканчивается pull request, который senior-разработчик готов принять без major rework после разумного review?

Green PHPUnit и PHPStan необходимы, но не достаточны. Агент может выполнить требования буквально и одновременно создать неправильную границу ответственности, лишний abstraction или незаметное изменение business semantics.

После self-review я бы отдавал diff независимому reviewer agent, а затем человеку. Одна модель в двух ролях всё ещё способна повторить исходный blind spot.

Preview стоит оценивать по floor, а не по ceiling

У любой frontier-модели найдётся впечатляющая overnight-задача. Для production важнее типичный результат: удержала ли она constraints, остановилась ли перед неоднозначным решением, восстановилась ли после failure и не объявила ли работу завершённой слишком рано.

В материале о GPT-5.5 и PHP benchmark я предлагал перейти от оценки code completion к полному engineering workflow. Sol двигает эксперимент ещё на шаг: можно ли отдать одной session всю цепочку и сократить участие разработчика до постановки задачи, важных решений и финального review.

Первый preview не даст процентного ответа. Он может показать более полезные наблюдения: модель дольше исследует до правок, реже требует указать файл, лучше меняет hypothesis после failed test — или, наоборот, делает слишком широкий diff.

Именно failures определят реальную границу автономности. Если Sol стабильно приносит небольшой, проверенный и понятный PR с меньшим supervision cost, прогресс находится уже не в генерации кода. Он находится в объёме инженерного процесса, который разработчик может безопасно превратить в делегированную работу.