Codex needs its own frontend design system and stronger UI training to compete with Claude
What variant of Codex are you using?
App, IDE Extension, CLI, Web
What feature would you like to see?
Codex needs stronger frontend design ability and its own design system.
Right now, Claude has a clear advantage in frontend work. Claude can give very specific design instructions: exact colors, spacing, layout choices, typography, component styling, and hex codes such as #FFFFFF. It often feels like Claude has a real design language behind it.
Codex, by comparison, is often too general. It may say things like “use gray,” “make it modern,” or “improve the layout,” but it does not always make the specific visual decisions needed to build polished frontend UI.
I would like Codex to have:
A built-in frontend design system
Better training for UI, UX, layout, typography, color, spacing, and component design
More specific design output, including actual hex colors, font sizes, spacing values, border radius, shadows, responsive breakpoints, and component states
Frontend-focused prompting behavior, so Codex can act more like a senior frontend designer, not just a code editor
Better visual taste for landing pages, dashboards, SaaS products, and modern web apps
Codex is already useful for code implementation, but frontend product work needs more than working code. It needs taste, structure, consistency, and specific visual decisions.
Additional information
There is also a feedback loop problem here.
Codex may not naturally get better at frontend UI if most users do not use Codex for frontend design work in the first place. Many people already go to Claude for UI because Claude is better at visual frontend prompting. That means Claude keeps getting more frontend context and user feedback, while Codex gets less of it.
That creates a cycle:
People do not use Codex for UI.
Codex gets less frontend feedback and context.
Codex does not improve enough at UI.
People keep using Claude for UI.
So Codex may need an intentional frontend design push, not just passive improvement from normal usage.
A dedicated Codex design system, stronger UI training, and more frontend-specific behavior would help break that cycle.
In short: Codex should not only write frontend code. It should help design the frontend.
3 Comments
Tasks not sticky too
"It often feels like Claude has a real design language behind it."
So there is a frequency of a feeling, is that it? And the feeling evokes in you a sense of, not a fake, but a "real" design, yeah? And this language is positioned posterior to Claude, huh? And thus, it follows: If Claude pulls stuff out of it's backside, why can't codex?
Sounds like like gobbledygook to me; like the user is stuck on autopilot; the very sort of automaton upon which he is reporting. Language churn might be affecting the mental process of its reporter. For him, there is no issue tracker (and thus thinking errors, as this might be categorized, may persist unfiltered). For this issue, if cognitive surrender is the aim, this works as designed and should be thusly closed for that reason.
Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.