First, take a few seconds and think about this: when do you feel the most productive and comfortable?
For me, the ideal state with Codex is when two to four long-running tasks have already been planned out and are running in parallel. While they run, I can step away and do something else: make coffee, play a game, watch a show, or read other material. One or two hours later, I come back and go straight into acceptance.
But to get there, you need clear and efficient planning. A long-running task plan is not simple. It includes acceptance criteria, sequencing, edge cases, and all kinds of small details.
Of course, AI can help you solve many of those problems and help you plan. But you still have to own the direction. What exactly is your acceptance standard? Are you optimizing for visual consistency or code consistency? Is the standard mostly subjective, or can part of it be checked objectively?
To set a good standard, you have to understand the plan deeply enough. So the first goal is not just to make a plan. The goal is to make a good plan efficiently.
If you already have full control over the project direction, and you are an experienced developer who knows exactly what should happen next, then this may not bother you much. But if the direction is still fuzzy, and you need several rounds of discussion with AI before the plan becomes solid, then speed matters a lot.
Here are a few things I have learned.
Do not keep reasoning on high or xhigh all the time
After GPT-5.5, response speed is already very good. But high and xhigh are still noticeably slower than medium. When the network is normal, medium often feels almost instant. It does not break the flow, and the answer quality is still very strong.
So for early-stage discussion, simple questions, and especially anything that needs several rounds of back-and-forth, I usually suggest starting with medium. If the question is very simple, low is also worth trying.
Some people may think: isn’t that just helping OpenAI save money?
I do not think so. The most comfortable state, as I said earlier, is to have several long-running tasks working at the same time so you can go do something else. That is the real sense of being freed up. The point is to reach that state faster, not to spend extra time on unnecessary deep reasoning before you even get there.
Use voice input more
Many people feel that voice input is not that different from typing. A keyboard is already fast enough, so why switch?
In practice, voice input is much faster than typing.
This connects directly to the previous point. Why use medium? Because it responds quickly. Once the system gets faster, your input speed needs to keep up too. Otherwise, the bottleneck simply moves back to you, and the flow is still broken.
There are many voice input options. Some are paid, some are free. In general, you get what you pay for, but there is no need to chase the best tool blindly. Use whatever fits you.
Treat acceptance criteria as part of the plan
When writing a plan, you have to care about acceptance criteria.
The plan needs to close the loop. It needs to produce a result you can actually accept. For example, after the implementation is done, you can have it run a review pass, fix the problems found in that review, then run another review pass to make sure the loop is closed.
If the loop cannot close, you will still end up fixing things manually at the end. So when possible, stretch the task timeline and let Codex do more of the work needed to produce a result that is actually good.
The real value of Codex is not that it writes code for you. The real value is that it gives time back to you. But that only works if the quality of your plan is high enough.