Как выжать максимум из Codex

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

Примерно в ноябре я начал применять их не только для программирования, но и для другой рабочей рутины. Делал презентации в Slidev, использовал ИИ-помощников как секретарей для заметок с голосового ввода и искал, какие еще материалы можно поручить такому инструменту: index.html, PDF, таблицу, набор слайдов.

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

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

Долгоживущие ветки

Первое, что изменило мой способ работы, — сжатие контекста.

Теперь у меня есть закрепленная ветка для каждого важного направления:

• мой личный «начальник штаба»;

• Agents SDK;

• OpenAI CLI;

• Codex для открытого кода;

• отдельная ветка для наблюдения за Twitter.

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

Быстрый переход к закрепленным веткам

К закрепленным веткам можно быстро переходить через Command-1 — Command-9.

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

Голосовой ввод

Голосовой ввод помогает передать Codex больше реального мышления.

Дело не в скорости. Главное в том, что ИИ-помощник получает неотредактированную версию мыслей. В Codex есть встроенный голосовой ввод, но я также использую Wispr Flow: диктовка на уровне всей системы меняет то, сколько контекста можно передавать и в другие приложения.

Когда я планирую работу, я могу сказать:

Кажется, какой-то Бен писал об этом в Slack. Я точно не помню, что именно. Просто найди.

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

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

Управление задачей по ходу работы

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

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

• сделай это меньше;

• здесь неверный текст;

• между этими двумя элементами слишком большой отступ;

• когда закончишь, создай запрос на внесение изменений;

• дождись предварительной сборки;

• отправь ссылку на просмотр человеку, который должен проверить это в Slack.

Мне не нужно ждать завершения каждого шага, чтобы решить, что делать дальше. Я продолжаю добавлять намерения, пока ИИ-помощник еще работает, а затем могу уйти — очередь действий уже сформирована.

После этого Heartbeats могут следить за запросом на внесение изменений или веткой в Slack. Работа перестает выглядеть как «один запрос — один ответ». Она становится небольшим повторяемым циклом.

Память

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

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

Большинство моих долгих веток начинаются с хранилища Obsidian:

vault/├── TODO.md├── people/├── projects/├── agent/└── notes/

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

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

Я также держу это хранилище как проект на GitHub. Это дает две вещи:

• с ним можно работать из облака;

• изменения становятся удобной поверхностью для проверки памяти.

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

Именно поэтому мне нравится память в виде файлов. Файлы заставляют ИИ-помощника сжимать опыт в форму, которая переживет саму ветку. Если ветка исчезнет, плохо сожмется или станет слишком дорогой для постоянного использования, полезные знания останутся.

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

У Codex есть и встроенные функции памяти: Settings > Personalization > Memories. Я воспринимаю их как локальный слой вспомогательной памяти. Они полезны для устойчивых предпочтений, повторяемых рабочих процессов, правил проекта и известных ошибок. Но это не замена сохраненным инструкциям и явному хранилищу.

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

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

Работа с компьютером и браузером

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

Для себя я разделяю это так:

• $browser — для локальных веб-страниц, которые я хочу проверять и комментировать;

• @chrome — для браузера с выполненным входом и несколькими вкладками;

• @computer — для задач, которые можно выполнить только через графическую среду.

Если я дорабатываю локальное приложение, мне нужен $browser. Если нужно работать внутри браузера, где я уже вошел в нужные учетные записи, мне нужен @chrome. Если задачу можно решить только кликами в настольном приложении, нужен @computer.

На рабочем компьютере Twitter у меня открыт в Safari. Если я попрошу @computer читать Twitter там, то потеряю Safari на время его работы. @chrome удобнее, когда нужно, чтобы ИИ-помощник использовал несколько вкладок с выполненным входом и не забирал себе все приложение, которым я сам пользуюсь.

Подключения расширяют доступ к реальной работе. Чаще всего я использую $slack, $gmail и $calendar, потому что ветки в Slack, почта и календарь — это места, где появляется много задач еще до того, как они превращаются в код.

Навыки делают повторяющиеся процессы переиспользуемыми. Хорошая отправная точка — Skill Creator и Skill Installer. Skill Installer позволяет добавлять рекомендованные OpenAI навыки прямо из поля ввода.

После запуска Codex pets я установил через него навык Hatch Pet. Но важна не сама игрушка, а общий прием: если вы один раз сделали что-то полезное, часто это можно упаковать так, чтобы Codex повторял процесс без повторного объяснения.

Удаленное управление

Удаленное управление делает длинные рабочие циклы переносимыми.

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

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

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

Heartbeats

Закрепленные ветки полезны, но они все еще ждут новой команды. Heartbeats делают работу периодической.

Heartbeat — это автоматизация внутри ветки. Можно сказать: «проверяй это каждые несколько часов», и ветка сама задаст расписание. У одной ветки может быть несколько расписаний. Она может работать до выполнения условия и менять частоту проверок со временем.

Личный начальник штаба

Моя ветка «начальник штаба» запускается каждые 30 минут:

Каждые 30 минут проверяй Slack и Gmailна наличие сообщений без ответа, которые требуют моего внимания.Помоги понять, что важнее всего.Если кто-то задает мне вопрос, изучи ответ как можно глубжеи подготовь черновик ответа, но не отправляй его.

Когда я возвращаюсь в Slack, ответы часто уже лежат в черновиках. Я все еще сам решаю, что отправлять. Но самая дорогая часть — сбор контекста — уже сделана.

Наблюдение за обратной связью

Та же схема работает для циклов проверки. Heartbeat может следить за комментариями в Google Docs, замечаниями к запросу на внесение изменений или ответами в Slack и продолжать работу по мере поступления обратной связи.

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

Сервер Slack MCP не мог загружать файлы, поэтому ИИ-помощник использовал @computer: нажал кнопку Add fileи все равно опубликовал обновленный ролик.

Интересно здесь не то, что он проверял Slack каждые 15 минут. Интересно, что цикл прошел через несколько инструментов: Slack для обратной связи, Remotion для сборки ролика, @computer для загрузки файла.

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

Возврат денег за украденную посылку

Недавно у меня украли посылку. Amazon сообщил, что ожидание оператора займет около 25 минут. Я создал ветку с @computer и дал ей такую задачу:

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

К тому времени, как я вышел из душа, возврат уже был оформлен.

Многие мои Heartbeats также обновляют Obsidian-хранилище. Для меня это еще один способ поддерживать явную память.

Цели

Новая возможность, которой я еще учусь пользоваться, — Goals.

С ними стоит быть смелее. Слабая цель звучит так: «реализуй план из этого Markdown-файла». Сильная цель содержит понятный критерий успеха, к которому ИИ-помощник может двигаться.

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

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

Это не то же самое, что вести длинный разговор с ИИ, постепенно копить план в Markdown, а потом сказать: «реализуй это». Выполнение настолько хорошо, насколько хороши цель и проверка. Смелая цель без проверки — просто пожелание.

Боковая панель

Больше всего в Codex меня сейчас интересует боковая панель.

Ее легко принять за место для предварительного просмотра. Но это слишком узкое понимание. Боковая панель — это место, где Codex перестает быть просто чатом и становится средой, в которой выполняется работа.

Для меня она решает три задачи:

• просмотр материалов;

• работа с веб-страницами;

• проверка изменений.

Во всех трех случаях я могу смотреть на тот же объект, с которым работает ИИ-помощник, и оставлять замечания прямо по месту.

Просмотр материалов

В боковой панели могут жить Markdown-документы, таблицы, CSV, PDF и слайды.

Markdown можно комментировать. Таблицы показывают формулы и поддерживают правку ячеек. Я использую это для управления планами Codex по открытому коду. CSV превращаются в таблицы, а не остаются сырым текстом. PDF отображаются прямо в приложении, что особенно полезно при работе с LaTeX. Слайды можно создавать и проверять, не выходя из Codex.

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

Работа с веб-страницами

Встроенный браузер еще интереснее. ИИ-помощник может видеть его, управлять им через JavaScript с помощью $browser, а я могу оставлять замечания прямо на том, что вижу.

Есть несколько веб-сред, которые я теперь постоянно использую таким образом:

• index.html для легких статических материалов;

• Storybook для проверки частей пользовательского интерфейса;

• Remotion Studio для программной анимации;

• Slidev для презентаций;

• Streamlit для приложений с данными.

Самая простая версия часто оказывается лучшей. Можно попросить модель создать один файл index.html с JavaScript и CSS, открыть его в боковой панели и сразу начать пользоваться. Сервер не нужен.

Я экспериментирую с Heartbeats, которые со временем обновляют статический index.html. Тогда при возвращении в ветку меня уже ждет свежий материал.

У Thariq есть хороший текст о том, почему HTML лучше Markdown как формат результата. Мне близка эта мысль. Когда результат становится небольшим приложением, а не просто документом, меняется сам способ работы с ним.

Если нужно что-то тяжелее, можно использовать приложение на Vite, но тогда приходится держать сервер запущенным. Обычный index.html гораздо устойчивее.

Для работы с анимацией я часто держу рядом Storybook и Remotion Studio. Я могу оставлять замечания вроде «сделай, чтобы это подпрыгивало» или «это должно быть крупнее», а ИИ-помощник видит то же состояние браузера, что и я, включая текущий кадр анимации.

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

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

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

Для меня главное изменение не в том, что ИИ-помощник может писать код. Главное в том, что все больше рабочих процессов может продолжаться после того, как я отошел от компьютера.