This debate surfaced in Chinese AI developer communities this week, and it cuts straight to something the English-language hype machine keeps glossing over.
A non-technical user posted about trying Codex after seeing dozens of "this tool changed everything" videos. She hit connection errors, got hallucinated nonsense, and asked the honest question: is everyone else lying, or am I doing something wrong?
The thread exploded to 738 comments. The consensus answer was: you're doing it wrong. Get GPT Plus. Use GPT-4 or GPT-5 to plan your task first. Have the LLM structure the prompt. Then paste that into Codex. Install the right skills. Constrain each step. Review your diffs.
I think that consensus answer is wrong. Or at least, it's wrong about what it's explaining.
The Claim Being Made
The implicit argument in "you used it wrong" is that Codex is a powerful autonomous coding agent that produces great results when properly configured. The setup friction is just a one-time cost. Once you're past it, the tool is genuinely capable of handling complex tasks on your behalf.
This is the version of Codex that gets demoed. An engineer types a vague goal, walks away, comes back to a working PR. The narrative is: AI is doing the software engineering now.
What the Actual Workflow Reveals
Look at what the "correct" workflow actually involves:
- You have a goal or idea
- You talk to GPT to clarify your requirements
- GPT helps you decompose the problem into steps
- GPT structures a prompt with constraints per step
- You paste that into Codex
- Codex runs the code
- You review the diff to catch what it broke or missed
- You adjust and re-run
Step 7 alone requires you to understand the codebase well enough to evaluate whether the output is correct. Steps 2 through 4 require you to have already done the hard cognitive work of software design: understanding the problem, identifying edge cases, setting scope boundaries.
Codex is executing step 6. The rest is you.
The Skill Being Obscured
Here is the contrarian claim: people who get great results from Codex are not benefiting from Codex's autonomy. They are benefiting from their own pre-existing ability to write tight specifications.
The commenter who built a semester of lesson plans in two hours had a clear, repetitive, well-defined task with a known output format. The person who built a WeChat mini-program in an afternoon had a scoped feature set and knew when "done" looked like.
Those are not beginners learning to code with AI. Those are people who already think clearly about requirements, and who found a fast executor for work they had already mentally specified.
For the original poster, the problem is not the setup. The problem is that she arrived with a vague sense of "I want to build something" and no concrete spec. Codex cannot generate a tight specification from a vague intention. It will try, and the result will be confident-sounding nonsense. Which is exactly what she got.
Why "You Used It Wrong" Deflects the Real Issue
Telling someone "you need to plan better before using this tool" is not a workaround. It is a description of a fundamental limitation.
Every powerful tool has prerequisites. A table saw requires you to know how to measure. A compiler requires you to know the language. Those prerequisites are taught explicitly. Nobody tells a beginner "the table saw is great once you understand woodworking."
But the Codex hype cycle does exactly that. It presents the tool as accessible to non-technical users, shows demos from people who are already skilled, and then when newcomers fail, explains it away as a configuration problem.
The configuration advice is real and correct. Yes, using GPT first helps. Yes, constraining steps matters. Yes, reviewing diffs is necessary. But those are not tips for getting the most out of an autonomous agent. They are the core workflow of a software engineer, now distributed across multiple tools.
Where Codex Actually Earns Its Reputation
None of this means Codex is bad. It means the use case is narrower than advertised.
For someone who already knows how to write software and wants to move faster on bounded, well-understood tasks: Codex is genuinely useful. It is a fast, mostly-reliable executor that removes the tedium of typing out boilerplate, converting formats, generating test cases, or implementing clearly-specified features.
For someone learning to code or trying to build something without a clear spec: Codex will accelerate you into walls. You will get a lot of output very quickly that does not do what you wanted, because you did not know what you wanted precisely enough to communicate it.
The failure mode for AI coding tools is not that they are too slow or too expensive. It is that they are fast enough to make vague thinking feel productive, right up until the moment it isn't.
The Uncomfortable Implication
If the best workflow for Codex requires you to first clarify your requirements with another LLM, you have to ask: what are you actually getting from the autonomy narrative?
You are using one AI to do the thinking, then another AI to do the typing. That can absolutely be faster than doing both yourself. But it is not the same as having an autonomous agent that can take a goal and produce a result. The thinking is still yours. The spec is still yours. The review is still yours.
The hype says the AI is doing the software engineering. The actual workflow says the AI is doing the fast parts of software engineering, and you are still doing the slow parts, just with a different interface.
That is worth knowing before you spend an afternoon fighting connection errors and wondering why your results look nothing like the demo.
Do you think there is a version of Codex usage where the planning step genuinely becomes unnecessary, or is spec-writing always going to be the human's job regardless of how good the models get?
Top comments (0)