How to Get the Most Out of Codex

WILD

Administrator
Staff member
ADMIN
SELLER
SUPREME
MEMBER
Joined
Jan 21, 2025
Messages
219
Reaction score
637
Deposit
0$
I actively used AI assistants to develop before Codex. Basically – through the environments that are made specifically to work with the code: preparation of sets of changes, editing code repositories and releasing ready-made edits.

Around November, I started using them not only for programming, but also for another work routine. He made presentations in Slidiv, used AI assistants as secretaries for notes from voice input and sought what other materials you can entrust to such a tool: index.html, PDF, table, set of slides.

The latest updates of the Codex application for the first time made such a wide mode of operation natural. Codex still handles the code well, but the most important change in the other is that it gives the work a place where it can go on.

My behavior was influenced not by one separate tool, but a bundle: a long-lived branch, general memory, access to actions on my computer, the ability to direct the task along the course of the case and the place where you can view the result itself.
Long-lived branches

The first thing that changed my way of working is to compress context.

Now I have a fixed branch for every important direction:

my personal "chief of the headquarters";

Agents SDK;

OpenAI CLI;

Codex for open source code;

A separate branch for monitoring Twitter.

These are not short chat rooms. These are the big working branches that I have been squeezing for several months. They accumulate history, preferences and old solutions. Everything that you do not want to restore every time you return to the task.
Quick transition to fixed branches

To fixed branches can be quickly crossed through Command-1 - Command-9.

This approach has a price. Long branches are not free. If you return to them later, the conversation is likely to no longer be in a fast storage layer, so the cost may be higher than that of a new short branch. But for important areas, the continuity of work is worth it.
Voice input

Voice input helps to transfer Codex more real thinking.

It's not about speed. The main thing is that the AI assistant receives an unedited version of thoughts. Codex has built-in voice input, but I also use Wispr Flow: the dictation at the level of the entire system changes how much context can be transmitted to other applications.

When I plan to work, I can say:

I think some Ben wrote about it at Slack. I don't remember exactly what. Just find it.

Such a phrase is inconvenient to print: it is vague, with reservations and without a clear structure. But it sounds natural aloud.

The same thing works with transcripts of conversations. If you need to write the text, you can call a person, record a conversation or chat personally with the Granola on the phone, and then take the transcript as a basis. Many plans become better when the model sees a rough thought, not just a polished wording.
Managing the task during work

The voice becomes more useful when it can be used to manage a task.

In Codex, you can add the following command after you call the tool. For example, I check the site and say in parallel:

Do it less;

here is the wrong text;

between these two elements too large indentation;

when you are finished, create a request for changes;

Wait for the preliminary assembly;

send a link to view the person who should check it out at Slack.

I don’t have to wait for each step to decide what to do next. I continue to add intentions while the AI assistant is still working, and then I can leave – the turn of the action has already been formed.

After that, Heartbeats can monitor the request for changes or a branch in Slack. The work stops looking like “one query – one answer.” It becomes a small repeatable cycle.
Memory

When the branches began to live longer, they needed a common memory outside the same code repository.

It is not only important that the very fact of preserving the history of messages. A long branch can remember a lot, but this memory remains locked inside it if useful information is not kept in a stable form. The meaning of memory is to turn what the branch has learned into a material that can be verified, edited, compared and used again.

Most of my long branches start with Obsidian storage:

vault/
― – TODO.md
- - people /
🙂 – – projects/
:── the agent/
- - - is a denomination /
Explain with

At the top level lies the AGENTS.md file with instructions. Approximately as follows: when you learn more about people, move projects forward or close open tasks, update the corresponding pages in the repository.

This repository is the place where the AI assistant lives, apart from any particular project. Code storage contains code. Obsidian storage contains the current working context: people, solutions, open tasks, daily notes, the state of the projects and those parts of understanding that would otherwise be lost between the branches.

I also keep this storage as a project on GitHub. It gives two things:

you can work with it from the cloud;

Changes become a convenient surface to check the memory.

When the AI assistant updates the vault, I look at the changes and see that he found important enough to remember. This step is needed. I do not want long-lived branches to quietly accumulate vague impressions in the history of the chat. I want to see specific records: this person prefers this, this project is waiting for such an action, this decision is made, this task is closed.

That’s why I like the memory in the form of files. Files make the AI assistant compress the experience in a form that will survive the branch itself. If the branch disappears, it will be badly shrinking or become too expensive for constant use, useful knowledge will remain.

At this point, fixed branches begin to be felt not as chat rooms, but as different workers who read the same notebook.

Codex has built-in memory features: Settings > Personalization > Memories. I perceive them as a local layer of auxiliary memory. They are useful for sustainable preferences, repeatable workflows, project rules, and known bugs. But this is not a replacement for the stored instructions and a clear repository.

Chronicle is particularly interesting here: it can use the recent context from the screen to create memories. I haven't used it seriously yet. The documentation explicitly states that this is a research version with voluntary inclusion and understandable risks: access rights, frequency restrictions, implementation of third-party commands and unencrypted local memory files.

But the direction is close to me: the work should leave behind a structured memory, and not just a longer chat history.
Working with a computer and browser

When the branch has memory, the next question is what it can access.

I share it for myself as follows:

$browser – for local web pages that I want to check and comment;

@chrome – for browser with a connected input and several tabs;

@computer – for tasks that can only be performed through a graphical environment.

If I rework a local app, I need $browser. If you need to work inside the browser, where I have already logged into the right accounts, I need @chrome. If the problem can only be solved with clicks in the desktop application, you need @computer.

I have open on Twitter on my Twitter computer in Safari. If I ask @computer to read Twitter there, I will lose Safari during its work. @chrome is more convenient when it is necessary for the AI assistant to use several tabs with a fit in and do not take away all the application that I use.

Connections expand access to real work. Most often, I use $slack, $gmail and $calendar, because branches on Sack, mail and calendar are places where many tasks appear before they turn into code.

Skills make repetitive processes reusable. A good starting point is Skill Creator and Skill Installer. Skill Installer allows you to add recommended OpenAI skills directly from the input field.

After the Start of Codex pets, I installed the Hatch Pet skill through it. But it is not the toy itself that is important, but a general reception: if you once did something useful, often it can be packed so that Codex repeats the process without re-excuses.
Remote management

Remote management makes long working cycles portable.

Codex can continue to work on the machine where your files, permissions and local setup are already located. And you can check the course of the task from the phone: to see what he found, answer the question, approve the next step or change direction, not returning to the workplace.

This is especially useful when Codex is already doing something long and it’s important not to lose pace. You can start the task, go, and then send it from the phone when the decision point appears.

The reason is the same as the fixed branches, voice input and Heartbeats: the work no longer has to stop just because you changed the place. The branch can continue to move, and it is enough for you to somehow unlock the next step.
Heartbeats

Fixed branches are useful, but they are still waiting for a new team. Heartbeats do the work periodically.

Heartbeat is an automation inside the branch. We can say: “check it every few hours,” and the branch itself will set the schedule. One branch may have several schedules. It can work until the condition is met and change the frequency of checks over time.
The Personal Chief of Staff

My head of the headquarters line starts every 30 minutes:

Check Slack and Gmail every 30 minutes
to the presence of unanswered messages that require my attention.

Help me understand what is most important.

If someone asks me a question, learn the answer as deeply as possible
and prepare a draft answer, but don't send it.
Explain with

When I get back to Slack, the answers often already lie in the drafts. I still decide what to send. But the most expensive part – the collection of context – is already done.
Observation of feedback

The same scheme works for verification cycles. Heartbeat may follow comments on Google Docs, comments on the request for changes or responses to Slack and continue to work as feedback comes.

One of my favorite examples was in the animation project. I posted a video on Slack and asked Codex to check the thread every 15 minutes, watch the comments, reassemble the version when comments appear and respond to the branch with the checker mark.

The Slack MCP server could not upload files, so the AI assistant used @computer: pressed the Add file button and still published an updated video.

Interesting here is not what he checked Slack every 15 minutes. Interestingly, the cycle went through a few tools: Slack for feedback, Remotion for roller assembly, @computer to download the file.

It is at this point that Heartbeats, connections and computer control cease to seem like separate capabilities. Together they turn into a working cycle that continues to go without my constant involvement.
Refund of money for stolen parcel

I recently had a package stolen. Amazon said the operator’s expectation will take about 25 minutes. I created a branch with @computer and gave her the following task:

Check every 5 minutes,
Has the support staff member joined this chat.

If you have joined, do your best,
to get a refund.

When he responds, check every minute,
to respond faster.
Explain with

By the time I got out of the shower, the return had already been drawn up.

Many of my Heartbeats are also updating Obsidian storage. For me, this is another way to maintain a clear memory.
Objectives

The new opportunity I’m still learning to use is Goals.

You should be brave with them. The weak goal is “implement a plan from this Markdown file.” A strong goal contains an understandable criterion of success, to which the AI assistant can move.

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

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

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

В Кодексе меня больше всего интересует боковая панель.

Легко воспринимать это как место для предварительного просмотра. Но это слишком узкое понимание. Боковая панель — это место, где 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. Затем, когда я вернусь к этой ветке, у меня будет свежий контент.

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

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

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

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

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

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

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