Theo’s Codex prompt critique gets one big thing right: the harness is part of the model
By AgentRiot Editorial
Theo says OpenAI removed a prescriptive Codex front-end prompt after he raised the issue. That causation remains his firsthand account. The public evidence is the larger point: system prompts, tool rules, and orchestration shape a coding agent as much as the model name on the picker.
Theo’s Codex prompt critique lands on a point that gets lost in model-name debates: the harness is part of the product.
In “I need you to hear me out (it’s REALLY good)”, Theo says GPT-5.6 Sol worked better for him inside Claude Code than inside Codex. It is not a controlled benchmark. It is a developer’s account of the difference between two coding environments, with examples of generated interfaces, subagent behavior, and day-to-day command-line friction.
His more consequential claim is about Codex itself. Theo says he found a prescriptive front-end guidance block in its system prompt, raised it with a friend working on Codex front-end work, and later saw the guidance change. “They listened to me,” he says around 9:33. OpenAI has not confirmed that he caused a specific edit, so that remains his firsthand account.
The larger argument does not depend on that private exchange. A coding model arrives with system instructions, tools, permissions, context rules, subagent behavior, UI conventions, and a runtime that decides when to ask, act, wait, summarize, or continue. Change those inputs and the same model can feel materially different to use.
The public prompt change is real
Theo’s criticism focuses on front-end instructions that he describes as unusually prescriptive. He reads examples that steer the agent toward particular interaction patterns, icon choices, card behavior, radius limits, and color treatment. The objection is not to design guidance itself. It is to a global rule set becoming a quiet constitution for every task, including projects with an established design system or no visual work at all.
That can produce a specific failure mode. A prompt that insists on one visual vocabulary can make generated work look consistent while ignoring the product’s existing conventions. A large front-end block also travels with backend tasks, command-line tools, and library changes where it has little to contribute.
The video cannot isolate the prompt as the cause of any one generated interface. Requests, repository context, tools, screenshots, model version, and plain randomness all matter. But the public repository does establish a version-level template change.
At commit 9ff47868, Codex exposes separate model_messages.instructions_template records for GPT-5.6 Sol, Terra, and Luna. Those GPT-5.6 templates retain a general “Autonomy and persistence” section, but omit the older GPT-5.4 template’s # Frontend tasks section and its “AI slop” wording. The broad front-end block Theo criticizes is absent from the public 5.6 templates.
That is evidence of a real instruction-template change. It does not establish the exact rollout timing across every Codex surface, or prove that Theo’s private conversation caused it.
A model name does not make two harnesses equivalent
Theo’s test case is GPT-5.6 Sol running through Claude Code rather than Codex. His point is not simply that one terminal interface looks better. He is arguing that the harness changes system instructions, tool integrations, subagent behavior, and long-running work.
“GPT-5.6 Sol” identifies a model offering. It does not promise the same behavior in every environment that can route requests to it. A harness decides what the model receives, which tools it can call, how those tools are described, how history is managed, and what the supervising developer can see and control.
That is why model comparisons that ignore the surrounding environment are thin evidence. A polished interface does not prove a better model. A successful coding run cannot tell us whether the result came from the weights, a stronger system instruction, cleaner repository context, a more forgiving approval policy, or a better task split.
OpenAI’s Codex prompting guide and subagents documentation support the product-side version of the same point: prompts, task structure, tools, and delegation policy shape how Codex behaves. What remains unmeasured publicly is the contribution of each layer.
Prompts decide when an agent acts
The useful part of Theo’s critique is his focus on behavioral defaults, not the argument over card radius.
He points to instructions that, in his reading, lean toward implementation unless the user explicitly asks for planning or exploration. That maps to a familiar complaint: an agent begins editing when the developer wanted analysis, or keeps pushing forward when a short question would have saved time.
A good agent prompt does not maximize activity. It separates reversible local work from consequential actions. It makes planning available without making every task ceremonial. It tells the agent when to surface a decision, when to inspect before editing, and when a concise explanation is more useful than an unsolicited patch.
The test is behavior across varied work: whether the agent respects an existing design system, avoids unwanted edits, recovers after a failed test, uses tools when they help, and keeps completion quality outside the narrow problem the prompt was designed to solve.
Without that measurement, a prompt edit can be an improvement, a regression, or a change in taste presented as product policy.
Orchestration changes the experience too
Theo also returns to orchestration: how a harness breaks work into stages, assigns subagents, tracks progress, and assembles results.
He praises Claude Code workflows as a practical way to coordinate subagents, while arguing that other harnesses leave too much orchestration to the user. That is a report from his own setup, not a neutral ranking of every coding agent. He also describes rough edges with GPT-5.6 Sol outside Codex, including formatting issues and incomplete token-usage visibility until work finishes.
A useful orchestration layer can make a model feel more capable by giving it a better job structure. It can also hide costs, make task ownership harder to inspect, or encourage parallel work when the tasks are not truly independent.
OpenAI has been moving Codex toward more explicit delegation. Its documentation describes subagents as a way to split suitable work and gives users controls over that delegation. The relevant product question is not whether more subagents look impressive in a pane. It is whether a developer can see what each one owns, review the outputs, interrupt the right task, and understand what changed before a merge or deployment.
What vendors should prove
Theo’s video is deliberately combative. It is not an audit of OpenAI or a benchmark proving Claude Code wins. His routing setup and workflow preferences are not a general deployment guide, and neither OpenAI nor Anthropic documentation establishes that every customer should reproduce them.
The practical standard is straightforward: when a vendor changes a prompt, show what improved and what it cost. Test it against front-end work, backend work, maintenance, planning, code review, and incident response. Measure whether it respects existing project context. Show whether it reduces unwanted autonomous actions instead of simply increasing the number of actions. Give developers enough visibility to identify whether a system instruction, tool policy, or model behavior caused the result.
Theo’s claimed intervention may remain impossible to verify from outside OpenAI. The engineering lesson does not: the harness is where much of a coding model’s behavior gets decided.
Sources
- Theo: “I need you to hear me out (it’s REALLY good)”, YouTube, 30:47.
- Codex changelog, OpenAI Developers.
- Codex prompting guide, OpenAI Developers.
- Codex subagents, OpenAI Developers.
- OpenAI Codex model catalog at commit
9ff47868, including GPT-5.4 and GPT-5.6 instruction templates.