Технический контекст
Я тоже все чаще ловлю себя на том, что не включаю отдельный plan mode. В связке GPT-5.5 и Codex модель действительно лучше держит ритм задачи: сначала раскладывает работу, потом переходит к реализации без постоянного пинка с моей стороны. Для practical AI implementation это очень приятный сдвиг.
Но тут я сразу приторможу: в официальных материалах OpenAI нет прямого обещания, что модель сама надежно заменяет отдельный планировщик. Документация говорит о другом: GPT-5.5 сильнее в agentic workflows, поддерживает reasoning.effort, работает через Responses API и лучше пользуется инструментами. Это не то же самое, что гарантированное автоматическое переключение между фазами plan и act.
Я покопался в доступных гайдах и картина такая. GPT-5.5-Codex правда стал увереннее в длинных инженерных задачах, меньше зависает в «вот мой план» и чаще доходит до действия. Но если нужен предсказуемый продовый контур, обвязка все еще решает: режимы, tool policies, ограничения на холостые ответы, иногда явный strict-agentic слой.
То есть пользовательское ощущение «планировщик больше не нужен» я понимаю отлично. На уровне UX так и есть: трение стало ниже. На уровне AI architecture я бы формулировал аккуратнее: не отмена planner-подхода, а рост базовой способности модели самой держать цикл работы.
Влияние на бизнес и автоматизацию
Первое последствие простое: меньше ручного микроменеджмента в разработке. Если раньше приходилось отдельно выбивать из агента план, потом отдельно толкать в исполнение, теперь часть этой механики можно убрать и ускорить AI integration в продукте.
Второе: дешевле становится не inference сам по себе, а orchestration вокруг него. Меньше служебных шагов, меньше лишних сообщений, проще сценарии automation with AI там, где задача не требует жесткого аудита каждого шага.
Но проиграют те, кто слишком рано выкинет контроль. В чувствительных процессах, где важны проверяемость, approvals и трассировка действий, отдельная фаза планирования все еще полезна.
Я бы смотрел на это так: для внутренних dev-задач и быстрых агентов можно смело упрощать поток. Для продовых систем с риском ошибки лучше тестировать на своих сценариях, а не верить в магию. Если у вас как раз упирается скорость команды или агент то планирует, то топчется на месте, можем вместе разобрать ваш процесс: в Nahornyi AI Lab я такие штуки обычно докручиваю до внятной AI automation без лишней театральщины вокруг «умного агента».