Codex уже не только пишет код. Что реально изменилось в ChatGPT

За последнее время ChatGPT и особенно Codex обновлялись настолько быстро, что я в какой-то момент сам перестал понимать, где просто новая кнопка, а где уже действительно меняется способ работы с AI.

Я посмотрел несколько свежих обзоров на YouTube, почитал статьи и официальные материалы OpenAI, часть функций попробовал сам. И решил собрать для себя и для блога нормальное резюме: что сейчас появилось в ChatGPT и Codex, что из этого реально меняет рабочий процесс и какие сценарии уже показывают другие пользователи.

Это не попытка пересказать один конкретный ролик и не очередной список “10 новых функций ChatGPT”. Мне интереснее собрать общую картину, потому что изменения уже начинают складываться в систему.

Если очень коротко, то раньше ChatGPT в основном был собеседником, которому мы отдавали отдельную операцию: написать текст, найти информацию, сделать таблицу, предложить код. Сейчас всё больше функций двигают его в сторону исполнителя, которому можно дать файлы, браузер, программы, рабочий процесс, конечную цель и критерии готовности.

В этой точке уже меняется сама модель работы с AI.

Что изменилось в общей картине

Главный сдвиг я бы сформулировал так:

ChatGPT постепенно перестаёт быть только местом, где мы получаем ответ. Всё больше задач можно доводить внутри него до готового рабочего результата.

Это не означает, что AI теперь “делает всё сам”. Но вокруг модели появился целый рабочий контур: проекты, локальные файлы, браузер, голос, долгие задачи, публикация сайтов, повторяемые навыки, расписание и удалённое управление.

По отдельности каждая функция может выглядеть небольшим обновлением. Вместе они меняют сам способ постановки задачи.

Раньше типовой сценарий был таким:
“Вот мой вопрос - дай ответ”.

Сейчас всё чаще можно строить другой:
“Вот моя рабочая среда, исходные материалы и результат, который мне нужен - выполни работу и покажи, что получилось”.

Это хорошо совпадает с тем, как я вообще проверяю нейросети на реальных бизнес-задачах. Для меня ключевой вопрос не в том, насколько убедительно модель отвечает, а в том, можно ли потом использовать результат и отвечать за последствия.

Chat, Work и Codex теперь решают разные типы задач

Одна из причин, почему сейчас легко запутаться, - внутри ChatGPT стало несколько разных рабочих режимов.
OpenAI разделяет Chat, Work и Codex, и я бы для себя объяснял их максимально просто.

Chat - обсудить

Это обычный разговорный режим. Подумать, задать вопрос, разобрать документ, попросить текст, получить идею, быстро что-то уточнить.
То есть Chat остаётся удобным там, где главная единица работы - ответ в диалоге.

Work - получить законченный рабочий результат

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

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

Codex - работать внутри технического проекта

Codex остаётся более технической средой: файлы, папки, репозитории, терминал, команды, браузер, локальный проект и инструменты разработки.

При этом границы уже начинают пересекаться. Codex используют не только для написания кода, а Work может собирать полноценные рабочие артефакты. Поэтому вопрос теперь не только в выборе модели. Нужно ещё понимать, в какой рабочей среде разумнее выполнять конкретную задачу.

Локальные файлы и папки становятся частью контекста

Отдельно стоит выделить работу с локальными файлами и папками.

Раньше при работе с AI мы постоянно переносили контекст руками: загрузил файл, вставил кусок текста, объяснил структуру проекта, потом ещё раз напомнил, где что лежит.

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

Для программирования это очевидно полезно. Но ровно та же логика начинает работать шире: исследование может жить рядом с исходными документами, сайт - рядом с контентом и графикой, внутренний инструмент - рядом с данными и инструкциями.

Вместо постоянного копирования контекста мы постепенно приходим к модели, где агент работает там же, где лежит сама работа.

Браузер становится не только источником информации, но и инструментом проверки

У Codex есть встроенная работа с браузером. Официальная документация Browser описывает сценарии, где агент может открывать страницы, взаимодействовать с интерфейсом, собирать актуальную информацию и проверять созданный результат.

Здесь ключевая часть - именно проверка результата.

Раньше модель могла написать код страницы и сообщить: “Готово”. Но между правильным кодом и готовой работой ещё оставалась проверка.
Открывается ли страница?
Работает ли кнопка?
Отправляется ли форма?
Не сломалось ли что-то рядом?

Теперь часть этого цикла агент способен пройти сам:

сделал -> открыл -> посмотрел -> проверил -> исправил.

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

Я уже показывал на отдельном эксперименте, насколько сильно отличаются “правильный фрагмент кода” и “готовая работа”. В тесте восьми нейросетей на задаче верстальщика часть моделей понимала задачу и даже предлагала правильное решение, но до полноценной приёмки доходили далеко не все результаты.

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

Sites сокращает путь от идеи до маленького приложения

Отдельное направление - ChatGPT Sites.
Sites можно создавать из Work, а в настольном приложении и из Codex. Смысл здесь не столько в том, что ChatGPT умеет сделать ещё один сайт. Важнее, что часть пути от идеи до опубликованного результата собирается в одной среде.

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

идея -> требования -> разработка -> файлы -> хостинг -> настройка -> публикация.

Теперь для простых сценариев она может стать заметно короче:

идея -> обсудил -> собрал -> проверил -> опубликовал.

Для серьёзного производственного продукта этого, конечно, недостаточно. Там остаются безопасность, резервирование, мониторинг, нагрузка, права доступа, тестирование, управление версиями и другие вещи.

Но для внутренней формы, небольшого кабинета, калькулятора, прототипа или временного инструмента это уже очень практичный сценарий.

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

Голос постепенно превращается в способ управлять работой

Ещё одна функция, которая сначала выглядит почти косметической, - голос внутри рабочих режимов.
Но если агент выполняет длинную задачу, голос становится не просто другим способом написать запрос. Он превращается в интерфейс управления работой.

Можно по ходу сказать:
“Здесь не меняй”.
”Посмотри ещё этот файл”.
”Я имел в виду другое”.
”Переделай только эту часть”.
”Проверь, что старое осталось работать”.

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

Для меня это важнее самой технологии распознавания речи. Меняется поведение пользователя: вместо одного длинного запроса появляется нормальный рабочий диалог во время выполнения.

Plan и Goal - это два разных способа поставить задачу

Вот эту разницу я бы точно запомнил.
Plan нужен, когда перед выполнением сначала стоит разобраться, как вообще подходить к задаче. Агент собирает контекст, уточняет детали и предлагает план.

Условно:

“Я примерно понимаю, чего хочу. Давай сначала определимся, как будем это делать”.

Goal работает от другого конца. Вы задаёте конечное состояние, ограничения и критерии завершения, а агент сам двигается к этому результату через несколько шагов. OpenAI описывает Goal как работу до проверяемого условия остановки.

Условно:

“Мне нужен вот такой результат. Вот условия, при которых я считаю задачу выполненной. Найди путь”.

Для меня это уже не столько функция AI, сколько управленческая механика.
Plan - я сильнее контролирую маршрут.
Goal - я сильнее фиксирую конечный результат и границы.

И чем больше действий агент умеет выполнять самостоятельно, тем важнее становится второй навык: нормально сформулировать, что именно означает “готово”.

Record & Replay позволяет показать процесс вместо длинной инструкции

Отдельно для бизнес-процессов стоит выделить Record & Replay.

Проблема многих внутренних процессов в том, что сотрудник умеет делать их руками, но не умеет нормально описать.

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

Очень быстро появится фраза вроде:

“А вот здесь я просто смотрю по ситуации”.

Record & Replay позволяет сначала показать последовательность действий на компьютере, а затем превратить демонстрацию в редактируемый повторяемый навык.

То есть раньше логика автоматизации была такой:

сначала формализуй собственную работу в инструкцию -> потом попробуем автоматизировать.

Теперь появляется промежуточный вариант:

покажи, как ты работаешь -> получи черновик навыка -> проверь и откалибруй -> повторяй процесс.

Для компаний это может оказаться полезнее многих более эффектных AI-функций. Огромное количество внутренней экспертизы до сих пор живёт именно в формате “спроси конкретного сотрудника, он знает”.

Повторяемую работу можно запускать по расписанию

Когда процесс уже понятен и проверен, его можно запускать регулярно. Scheduled tasks позволяют повторять работу в Work и Codex и использовать нужные навыки и подключённые инструменты.

Для себя я бы здесь держал очень простой порядок:

1. Сначала человек стабильно выполняет процесс сам.
2. Потом показывает или описывает его агенту.
3. Затем проверяет, что агент повторяет процесс правильно.
4. И только после этого ставит выполнение на расписание.

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

Длинной задачей уже не обязательно управлять только с рабочего компьютера

Ещё один логичный шаг - удалённое управление долгой работой Codex.

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

Сама по себе это не самая громкая функция. Но она хорошо показывает общий вектор: агент рассчитан уже не только на короткое взаимодействие “написал запрос - получил ответ”. Он должен уметь работать дольше, а человек - возвращаться к нему по мере необходимости.

И здесь снова возникает тот же вопрос: чем дольше агент способен действовать самостоятельно, тем дороже плохо поставленная задача.

Что показывают реальные примеры использования

Отдельно я посмотрел не только на официальные функции, но и на то, что люди уже пытаются из них собирать.

В разных YouTube-обзорах было несколько показательных примеров. Я не проверял первоисточник каждого пользовательского кейса отдельно, поэтому отношусь к ним именно как к иллюстрациям сценария, а не как к доказательству того, что любой человек гарантированно повторит тот же результат.

Физические устройства и умный дом

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

В другом примере была небольшая Bluetooth-колонка с пиксельным экраном. Пользователь хотел превратить её в дополнительный экран для уведомлений, хотя устройство изначально для этого не предназначалось. Агент помог разобраться в доступных материалах и протоколе связи и собрать инструмент для отправки сообщений на экран.

Здесь важны не конкретно теплица и колонка, а новый тип входа в инженерную задачу.

Раньше между мыслью “хочу, чтобы это устройство работало вот так” и реализацией почти автоматически стоял специалист. Теперь часть исследования, программирования и настройки можно пройти вместе с агентом.

Это не отменяет инженерной проверки, особенно если речь идёт об электричестве, отоплении, оборудовании и других системах, где ошибка может привести не только к сломанному файлу.

Но сам класс доступных экспериментов становится шире.

Маленькие приложения под одного человека или одну семью

В одном из обзоров была мама, которая собрала для детей собственное приложение с домашними заданиями, очками, наградами, таймером концентрации и отдельной родительской частью.

Ценность примера не в самом приложении, а в том, что оно почти никому больше не нужно.
Это софт под одну конкретную семью.

Другой пример - дизайнер, которому от большого профессионального видеоредактора регулярно требовалось только несколько функций. Вместо очередного поиска подходящего сервиса он собрал небольшой собственный редактор именно под эти действия.

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

Сейчас появляется новый класс софта:

• инструмент для одного сотрудника;
• калькулятор под внутренний процесс;
• форма для небольшой команды;
• приложение на время конкретного проекта;
• интерфейс с пятью нужными кнопками вместо ста ненужных.

Это один из заметных эффектов текущего развития Codex.
Вопрос постепенно меняется с “какой сервис мне купить?” на “какой инструмент мне на самом деле нужен?”.

Агент может связывать несколько сервисов в один процесс

Ещё один сценарий из обзоров - когда Codex получает не отдельную операцию, а большой конечный результат и связывает для него несколько инструментов.

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

Мне здесь не так важен конкретный ролик или качество получившегося видео. Важна сама схема:

человек задаёт результат -> агент управляет несколькими инструментами -> промежуточные результаты передаются дальше по цепочке.

Это уже другой уровень работы по сравнению с обычным “напиши мне сценарий”.

Но здесь же особенно хорошо видно, почему AI не является магической кнопкой. Чем больше этапов агент проходит самостоятельно, тем больше решений он принимает между исходной задачей и конечным результатом.

Поэтому вместе с автономностью растёт необходимость в критериях, ограничениях и проверках.

Экспертиза специалиста превращается в автоматизируемый процесс

Отдельный класс сценариев возникает в очень узких профессиях.

В одном из роликов был специалист по коллекционным карточкам. Он использовал Codex, чтобы распознавать данные карточки по фотографии, искать соответствующие предложения, сопоставлять оценки и рыночные цены и быстрее находить потенциально интересные варианты. Финальное решение при этом оставалось за самим специалистом.

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

Именно такие сценарии, на мой взгляд, хорошо показывают более реалистичное будущее, чем тезис “AI заменит специалиста”.
Специалист никуда не исчезает. Наоборот, его предметная экспертиза становится основой автоматизации.
Человек знает, что искать, что считать хорошим результатом и где ошибка критична. Агент берёт повторяемые технические действия вокруг этой экспертизы.

Что всё это меняет для бизнеса

После всех обновлений и примеров я бы не делал вывод “теперь Codex умеет всё”.
Для меня вывод другой:

Расстояние между задачей, которую человек хорошо понимает, и собственным работающим инструментом или автоматизированным процессом становится заметно короче.

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

Но вместе с этим меняется и роль пользователя. Если AI получает доступ к файлам, браузеру, программам и длинным цепочкам действий, недостаточно просто “нормально написать промт”.

Нужно уметь поставить и принять работу.

Что теперь важнее хорошего промта

Для длинной агентской задачи я бы фиксировал минимум шесть вещей.

1. Результат

Что конкретно должно существовать в конце: документ, файл, работающий сайт, заполненная таблица, опубликованный материал, изменённый проект.

2. Критерии готовности

По каким признакам можно объективно сказать, что работа закончена, а не просто выглядит законченной.

3. Ограничения

Что агенту нельзя менять, какие источники можно использовать, какие действия запрещены.

4. Права

К каким данным, файлам и сервисам ему действительно нужен доступ. Не больше.

5. Проверка

Как будет приниматься результат и что именно нужно протестировать после выполнения.

6. Точка остановки

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

Вот это, на мой взгляд, становится новым уровнем грамотности при работе с AI.

Раньше плохой запрос мог закончиться плохим текстом. Теперь плохо поставленная задача потенциально может закончиться неправильным изменением файлов, сайта или повторяющегося рабочего процесса.

Возможностей стало больше. Значит, требования к постановке и приёмке тоже должны вырасти.

Что я бы попробовал автоматизировать прямо сейчас

Я бы точно не начинал с идеи “давайте автоматизируем весь отдел”.

Первые задачи лучше выбирать там, где одновременно выполняются четыре условия:

• процесс регулярно повторяется;
• человек уже умеет хорошо выполнять его руками;
• результат легко проверить;
• ошибка обратима и не создаёт серьёзного ущерба.

Например:

• подготовка типового внутреннего отчёта;
• обработка и переименование файлов;
• сбор маленького внутреннего инструмента;
• перенос данных между рабочими системами;
• проверка сайта после изменений;
• подготовка материалов из утверждённых источников;
• повторяющаяся последовательность действий в нескольких программах;
• узкая профессиональная рутина, под которую никто не будет делать отдельный массовый сервис.

А дальше я бы смотрел не на количество сгенерированного текста и не на красоту демонстрации.
Я бы проверял один практический показатель:

Какую работу действительно удалось снять с человека после полноценной проверки результата?

Вот здесь уже появляется нормальная база для решения, стоит ли расширять автоматизацию дальше.

Моё резюме по текущему состоянию ChatGPT и Codex

Если собрать все обновления в одну картину, для меня сейчас происходит не “ещё одно улучшение нейросети”.
Собирается полноценная рабочая среда вокруг модели.

Файлы и папки дают контекст.
Браузер позволяет не только искать, но и проверять.
Sites сокращает путь до опубликованного приложения.
Voice делает управление задачей более естественным.
Plan помогает сначала спроектировать маршрут.
Goal позволяет зафиксировать конечный результат.
Record & Replay превращает показанный процесс в повторяемый навык.
Расписание позволяет запускать проверенный процесс регулярно.

Поэтому главный вопрос сейчас уже не “насколько умнее стала модель”.
Интереснее другое:

Какие реальные рабочие процессы теперь можно передать AI целиком и при этом сохранить нормальную проверку результата?

И здесь я бы не противопоставлял AI специалистам.
Наиболее практичная комбинация сейчас - специалист, который хорошо понимает свою работу и умеет превращать повторяемую часть этой работы в инструменты, навыки и автоматизированные процессы.

Возможностей у AI становится больше. А ответственность за то, что считать готовой работой, пока остаётся у человека.

Если интересна именно эта практическая сторона вопроса, все мои проверки собраны в серии про AI на реальных бизнес-задачах.

Частые вопросы про ChatGPT Codex

Что такое Codex в ChatGPT?

Codex - рабочая среда OpenAI для агентной работы внутри технических проектов. Он может получать контекст из файлов, изменять проект, запускать команды, использовать браузер и выполнять многоэтапные задачи. При этом сценарии его использования постепенно выходят за пределы написания отдельного фрагмента кода.

Чем Work отличается от Codex?

Если упростить, Work ориентирован на длинную законченную работу с исследованиями, документами, таблицами, сайтами и другими результатами. Codex сильнее привязан к техническому проекту: файлам, репозиториям, терминалу, браузеру и инструментам разработки.

Границы пересекаются, поэтому выбор зависит от конкретной задачи и того, какая рабочая среда для неё нужна.

Можно ли использовать Codex, если я не программист?

Да, если вы понимаете саму задачу, можете сформулировать ожидаемый результат и способны его проверить.

Как раз один из интересных сценариев - когда специалист хорошо знает свою профессиональную работу, но не умеет самостоятельно программировать инструмент для её автоматизации.

Что такое Goal mode в Codex?

Goal нужен для длинной работы, где удобнее определить конечное состояние, ограничения и критерии завершения, чем вручную задавать каждый промежуточный шаг.
Агент получает цель и сам выбирает последовательность действий, двигаясь к заданному результату.

Что такое Record & Replay?

Record & Replay позволяет показать последовательность действий на компьютере и превратить эту демонстрацию в редактируемый повторяемый навык.
Это особенно полезно для процессов, которые сотруднику легко выполнить самому, но трудно подробно описать текстовой инструкцией.

Можно ли поставить Codex задачу и вообще не проверять результат?

Для реальной рабочей задачи я бы так не делал.
Автономность означает, что агент может самостоятельно выполнить больше промежуточных действий. Она не означает, что итог автоматически правильный.
Чем больше прав, инструментов и времени получает агент, тем важнее заранее определить критерии готовности, ограничения и способ проверки.

С какой автоматизации лучше начать в компании?

Лучший первый кандидат - небольшая повторяющаяся задача, которую сотрудник уже стабильно выполняет руками, результат которой легко проверить, а ошибка обратима.
Сначала стоит добиться стабильного выполнения одного такого процесса. И только после этого увеличивать автономность и масштаб автоматизации.