Что вышло 5 февраля
5 февраля 2026 года OpenAI представила GPT-5.3-Codex — модель для сложных задач реальной разработки. В официальном changelog Codex компания заявила более сильное reasoning, профессиональные знания и прирост скорости на 25% для пользователей Codex. Модель также чаще сообщает о прогрессе и реагирует на steering во время работы.
Техническое описание закрепляет позиционирование: GPT-5.3-Codex оптимизирована для agentic coding, поддерживает несколько уровней reasoning effort и работу с инструментами. Но для меня важнее не число в benchmark и даже не скорость. Меняется масштаб работы, который имеет смысл отдавать модели.
Было: «Напиши AuditService»
Теперь: «Добавь аудит изменений пользователей в существующий проект»В первой формулировке решение уже принято человеком. Во второй агент получает цель и должен восстановить архитектуру, выбрать точку интеграции, изменить несколько слоёв и доказать результат тестами.
Фрагмент кода и инженерная задача
Когда разработчик просит написать класс, он обычно уже знает namespace, зависимости, интерфейс и место вызова. AI остаётся только воплотить готовое техническое решение на PHP. Это полезно, но основная инженерная работа произошла до промпта.
Задача «добавить аудит изменений пользователя» устроена иначе. Сначала нужно найти все точки изменения User, понять текущую event-архитектуру, решить, где хранить старые и новые значения, определить инициатора и не нарушить транзакционность. Только после этого имеет смысл создавать migration, listener или сервис.
Правильный результат может вообще не содержать AuditService. Если проект последовательно использует domain events, ручной вызов сервиса из каждого контроллера станет чужеродным решением. В другом коде Doctrine listener окажется слишком неявным, и явный application service будет честнее. Качество PHP здесь вторично по отношению к попаданию в существующую систему.
Research входит в реализацию
Перед правкой незнакомого модуля я сначала восстанавливаю flow. Агенту нужен тот же этап: маршруты, контроллеры, application services, события, persistence и тесты. Поиск файлов — часть программирования, а не подготовительная церемония.
Для пользовательского аудита исследование должно ответить хотя бы на четыре вопроса:
- где пользователь меняется фактически, а не где начинается HTTP-запрос;
- как проект передаёт инициатора из authentication layer в бизнес-логику;
- есть ли принятый механизм событий и выполняется ли он внутри транзакции;
- какие поля нельзя писать в историю — пароль, токены и другие секреты.
Без последнего пункта агент вполне может реализовать формально полный, но опасный аудит. Автономность не компенсирует отсутствующие ограничения.
Модель работает вместе с инструментами
Для отдельного класса модели достаточно контекста в сообщении. Для задачи уровня проекта нужны repository search, Git, Composer, база данных, PHPUnit, PHPStan или Psalm и команды фреймворка. Практическая система выглядит как связка из модели, инструментов, репозитория и исполняемого окружения.
read → decide → edit → run → observe → correctТерминал замыкает этот цикл. Допустим, feature-тест ожидал 201, а API вернул 422. Для генератора это финальная ошибка. Для coding agent — новое наблюдение: нужно открыть response, сверить validation rules, найти расхождение и повторить тест.
Сам факт запуска PHPUnit ничего не доказывает. Агент должен выбрать релевантную команду, не проигнорировать упавший соседний тест и правильно интерпретировать причину. Инструменты увеличивают возможности модели, но одновременно добавляют новые места для неверного решения.
Long-running — это много коротких циклов
Длительная задача не означает один огромный ответ. Она складывается из десятков переходов: найти entity, проследить update flow, проверить события, создать migration, изменить код, запустить тесты, разобрать ошибку, проверить static analysis и перечитать diff.
Главная сложность — не потерять исходную цель после пятого промежуточного решения. Агент может увлечься удобным рефакторингом, начать менять публичный DTO или заменить event-механику ради локальной красоты. Поэтому длинной работе нужны явно записанные границы, а не надежда на память разговора.
Steering корректирует курс, а не заменяет постановку
GPT-5.3-Codex лучше реагирует на сообщения во время выполнения. Это полезно, когда разработчик видит раннее направление и добавляет ограничение: не менять таблицу users, не использовать lifecycle callbacks, не трогать frontend.
task → execution ↔ developer steering → resultSteering снижает цену ранней коррекции, но не лечит расплывчатую цель. Если агенту не сказали, что публичный API должен остаться прежним, позднее сообщение может остановить рефакторинг, однако уже потраченный контекст и diff никуда не исчезнут.
Я использую вмешательство для новых фактов и уточнения курса. Архитектурные инварианты, безопасность и Definition of Done лучше дать до начала реализации.
Хорошее задание всё больше похоже на issue
Task-level delegation требует другой формы запроса. Вместо описания будущих классов полезнее зафиксировать цель, ограничения, критерии готовности и то, что сознательно не входит в работу.
GOAL
Хранить историю изменений пользователей.
REQUIREMENTS
- changed fields, old values, new values
- actor и timestamp
CONSTRAINTS
- публичный API не менять
- новые зависимости не добавлять
- использовать текущую event-архитектуру
DONE WHEN
- migration проходит
- functional tests добавлены
- весь существующий test suite зелёный
OUT OF SCOPE
- UI истории
- экспорт
- аудит других entitiesТакое задание меньше похоже на prompt engineering и больше — на нормальную инженерную постановку. Агент сам находит файлы и предлагает реализацию, но не должен угадывать границы продукта.
Scope и Definition of Done работают парой
Фраза «сделай аудит» не объясняет, где задача заканчивается. Достаточно ли таблицы? Должны ли сохраняться старые значения? Кто считается actor для фоновой job? Что происходит при rollback основной транзакции?
Definition of Done превращает цель в проверяемый результат. Scope защищает от противоположной проблемы — слишком широкой реализации. Без него агент может заодно переписать UserService, изменить DTO и перестроить permissions. Некоторые правки окажутся разумными, но review станет дороже, а риск регрессии вырастет.
Для длинной agentic-задачи я отдельно пишу OUT OF SCOPE. Этот короткий блок часто экономит больше времени, чем дополнительные инструкции о стиле кода.
Как поставить задачу в Laravel-проекте
Возьмём ограничение: пользователь может иметь не больше пяти активных API-токенов. Слабая формулировка заранее диктует реализацию: «добавь проверку в контроллер».
Task-level вариант задаёт результат:
Добавь ограничение в пять активных API-токенов на пользователя. Изучи текущую реализацию Laravel Sanctum и все точки выпуска токена. Публичный API и формат успешного ответа не меняй. Учти конкурентные запросы, добавь feature-тесты и запусти существующий suite. Сначала покажи текущий flow и план; код пока не меняй.
Теперь агенту придётся проверить routes, authentication controller, PersonalAccessToken, транзакции и тестовые фабрики. Разработчику не нужно угадывать список файлов, но нужно проверить план: простого count() перед insert недостаточно, если два запроса могут пройти одновременно.
Сильная модель не отменяет workflow
Чем крупнее единица делегирования, тем выше цена неверного понимания. Ошибка в двадцати строках видна сразу. Ошибка в архитектурном предположении проявится после migration, новых классов и тестов, которые подтверждают не то поведение.
TASK → RESEARCH → PLAN → HUMAN REVIEW → IMPLEMENT → TEST → REVIEWДля маленькой правки этот маршрут избыточен. Для изменения, проходящего через HTTP, domain, persistence и security, ранний review плана дешевле позднего review большого diff.
GPT-5.3-Codex расширяет объём работы, который можно доверить агенту. Надёжность всё равно даёт вся система: контекст проекта, инструменты, ограничения, Definition of Done и человеческая проверка.
Между «напиши» и «сделай»
Разница между генерацией кода и agentic coding хорошо помещается в два глагола. «Напиши» обычно передаёт модели уже выбранное решение. «Сделай» передаёт цель и часть инженерного процесса.
GPT-5.3-Codex интересен тем, что рассчитан именно на второй масштаб: исследовать репозиторий, использовать инструменты, пройти несколько циклов выполнения и учитывать корректировки по ходу работы. Но крупная задача требует от разработчика большего, а не меньшего понимания системы.
Архитектурные знания теперь нужны и для того, чтобы очертить границы, заметить неверный план и проверить доказательства готовности. Модель получает инженерную задачу. Ответственность за то, какая это задача и что считать правильным результатом, остаётся у человека.
