People come up to me quite often and ask, “Can Codex do this?”
Then they spend the next two or three minutes explaining exactly what “this” is: the problem they want to solve, what the application should do, and what a good result would look like. Sometimes they share what they’ve already tried, what worked, and what didn’t.
And I’m thinking: you should literally just say all of this to Codex.
That whole explanation was already the prompt.
Prompt engineering is dead. And not dead.
If prompt engineering means learning a secret language before asking for help, then I think it’s mostly dead. Especially with reasoning models, there usually isn’t a magic keyword that unlocks the right answer. I don’t think you should stare at a blank screen for an hour trying to craft the perfect prompt.
But it’s also not dead, because clarity still matters. Ambiguity makes work harder for Codex just as it does for anyone else. If I scrambled the paragraphs in this article or switched to a language you don’t understand, it would be harder to follow. Even tense matters: “I tried this” isn’t the same as “I want you to try this.”
What do you actually want? What context matters? What constraints should Codex know? What would a good outcome look like?
Talk to Codex the way you would talk to someone you’re working with.
I like to start with the outcome: what is my goal? That’s also the broader shift with agents. Instead of scripting every step and asking for each intermediate output, I can explain what I want to achieve, set the boundaries, and let Codex help figure out the path.
Say the messy version
Most ideas don’t arrive as clean specifications. They sound more like:
“Okay, I have all these files. The formats are slightly different. I need a report by Friday. I think most of the data is there, but this one export is a bit weird…”
That’s fine. Just say it.
When you ramble, you often give Codex more signal. You mention the detail you would have removed from the polished prompt. You change your mind halfway through. You say, “Actually, no, I don’t want that.”
Changing your mind reveals what you don’t want. A detour might reveal a hidden constraint. Thinking out loud helps both you and Codex understand the task.
With voice dictation, you press the microphone, talk through the brief, check the transcript, and send it.
If it’s available in your setup, Voice mode goes further. You can follow up, interrupt, change direction, or pick up a new thread of thought. You can also use it to coordinate work: start another task, check an existing one, ask what’s blocked, or steer work that’s already running.
I’ll be honest: talking to a computer still feels a bit strange. In the office, I hold a DJI mic in my hand. Headphones with a microphone work too.
But it’s better than letting a good idea stay stuck in your head because you haven’t found the perfect way to write it down.
Ask the ridiculous question
There’s a familiar meme version of this:
“Codex, make me a billion-dollar B2B SaaS. Make no mistake. One-shot it.”
You’re not going to one-shot a billion-dollar company. But the conversation might uncover something real: a problem you understand, someone who has it, and a first step worth taking. It’s good old-fashioned problem-solving: break a complex problem into smaller, achievable steps.
The value is in the conversation itself. It can take you from a ridiculous question to something you can actually ship today.
A few practical ways to start
If the idea is still fuzzy, ask Codex to interview you:
“I’m still figuring this out. Ask me one question at a time. Push on anything vague, then help me turn it into something concrete.”
Or be very direct:
- What are my blind spots?
- What would make this fail?
- What am I overthinking?
- What is the smallest useful version?
- What do you need to know before you can start?
Codex’s Plan mode is useful when you want more structure. It can ask clarifying questions, offer options, and work through an approach before implementation.
But I don’t think every idea needs to begin there. Sometimes an open-ended conversation flows better. We don’t divide every conversation with a colleague into planning and executing. Talk first. Let the shape of the problem emerge. Move into a plan when the work needs one.
Ask Codex about Codex
There’s a second meaning to “talk to Codex”: ask it questions about itself.
Ask what it can see. Ask which mode makes sense. Ask what tools are available. Ask how it plans to verify its work.
If the OpenAI Docs skill is available, ask Codex to check the documentation. You can also inspect the public Codex repository, or clone it and ask Codex to explain how it works.
If Codex misses the mark, ask why
“You did this, but I actually wanted that. Where did we go wrong?”
Maybe your request was ambiguous. Maybe an AGENTS.md file or skill pulled the work in a different direction. Maybe a plugin, permission, or tool wasn’t available. Maybe Codex made a bad assumption.
Ask what it understood, which instructions it followed, what failed, and what you could have made clearer. Codex can often use the context still available to help audit the collaboration itself.
Where available, you can open a side chat with /side while Codex is running, without interrupting the main chat. Ask what’s done, what’s left, what’s blocked, and how you can help. You’re basically its manager at standup.
If you want something explained in plain English, select the text in the transcript and choose “Ask in side chat.”
Get the idea out of your head
On a road trip, I started talking to Codex about a presentation. That became the structure for the talk and this article. I talked through the rough idea, changed my mind a few times, and kept going.
Often the biggest blocker isn’t the model. It’s us. We think the idea isn’t ready. We don’t know the right prompt. We’re worried we haven’t explained it properly.
The interface will get better. And if you have ideas for how talking to Codex should feel, I’d genuinely love to hear them.
Just ask Codex.
