Codex-максинг

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

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Codex-максинг

Codex-maxxing Автор: Jason Liu Оригинальный текст:

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

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

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

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

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

Первое, что изменило моё поведение, — это компактизация.

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

• поток «начальник штаба»
• Agents SDK
• OpenAI CLI
• Codex для открытого исходного кода
• один просто для мониторинга Twitter

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

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

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

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

Преимущество — не в скорости. Оно в том, что агент получает нередактированную версию моего мышления. В Codex есть встроенный голосовой ввод, но я также использую Wispr Flow, потому что системный диктант меняет то, сколько контекста я могу вложить во всё остальное. Если я планирую работу, я могу сказать: «Кажется, какой-то парень по имени Бен в Slack это упоминал, я точно не помню что именно, просто поищи». Такое предложение слишком размытое и неудобное, чтобы печатать, но совершенно естественное, чтобы произнести.

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

Управление

Голос становится полезнее в сочетании с управлением (steering).

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

• сделай это меньше
• этот текст неправильный
• расстояние между этими двумя элементами кажется неверным
• когда закончишь, открой пулл-реквест
• дождись деплоймента (развёртывания) превью
• отправь ссылку на превью человеку, который должен его проверить, в Slack

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

Позже Heartbeats могут мониторить пулл-реквест или Slack-тред после моего ухода. Единица работы перестаёт быть «один промпт — один ответ». Она становится небольшим операционным циклом.

Память

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

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

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

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

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

Хранилище — это место, где живёт агент, отделённое от любого конкретного проекта. Репозитории содержат код. Хранилище содержит текущий контекст моей работы: людей, решения, открытые циклы, ежедневные заметки, состояние проектов и те фрагменты понимания, которые иначе теряются между потоками.

Я также храню хранилище как GitHub-репозиторий. Это даёт мне две вещи:

1. Оно может работать в облаке
2. Диффы становятся поверхностью для ревью памяти

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

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

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

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

Использование компьютера и браузера

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

Самое полезное различие в моей голове:

• $browser — для локальных веб-поверхностей, которые я хочу инспектировать и аннотировать
• @chrome — для залогиненного состояния браузера и нескольких вкладок
• @computer — для работы, которая существует только как GUI

Если я итерирую над локальным приложением, мне нужен $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 может продолжать работать с машины, на которой уже находятся ваши файлы, разрешения и локальная настройка, пока вы проверяете процесс с мобильного, просматриваете результаты, отвечаете на вопрос, одобряете следующий шаг или меняете направление, не возвращаясь к рабочему столу. OpenAI описывает это как способ работать с Codex откуда угодно.

Это важнее всего, когда Codex уже выполняет что-то длительное и вы хотите сохранить momentum (инерцию). Можно начать задачу, уйти, а потом управлять ею с телефона, когда она достигнет точки принятия решения.

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

Heartbeats

Закреплённые потоки полезны, но всё ещё ждут, пока вы что-то скажете. Heartbeats (сердцебиения) — это то, что делает их повторяющимися.

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

Начальник штаба

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

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

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

Мониторинг обратной связи

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

Один из моих любимых примеров пришёл из проекта с анимацией. Я опубликовал видео в Slack и попросил Codex проверять тред каждые 15 минут на предмет обратной связи, рендерить новую версию при появлении комментариев и отвечать обратно в тред, тегая рецензента. MCP-сервер Slack не мог загружать файлы, поэтому агент использовал @computer, чтобы нажать кнопку «Добавить файл» и опубликовать обновлённый рендер.

Интересно не то, что он проверял 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 может генерировать артефакты. Важно, что я могу инспектировать и аннотировать их, не разрывая цикл.

Управление веб-поверхностями

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

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

• index.html для лёгких статических артефактов
• Storybook для ревью UI-компонентов
• 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 мест, где можно запоминать, возвращаться, инспектировать и действовать, тем меньше моя работа умирает между промптами. Вот что мне важно. Не то, что агент может писать код за меня, а то, что больше моей работы может продолжать двигаться после того, как я ухожу.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot