Code Quality and Developer Experience Issues

Resolved 💬 2 comments Opened Jan 16, 2026 by looper200 Closed Jan 17, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.86.0

What subscription do you have?

Plus

Which model were you using?

GPT-5.2-Codex

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (WSL)

What issue are you seeing?

GPT-5.2-Codex is a great model, but as a developer working on an existing project, my experience has been frustrating.

I use Codex to implement features and improve the codebase, and I’ve noticed that the generated code is often overly verbose in the wrong way, yet not developer-friendly. Even when the code works, it’s hard to read and maintain because the model doesn’t prioritize readability, simplicity, or long-term maintainability.

It often feels like Codex optimizes for what’s safest and fastest for the model (getting the job done quickly and saving tokens) instead of what’s best for me as a developer. The result is code that feels compacted and difficult to follow, with little to no comments explaining what each function is doing. In larger tasks especially, it tends to ignore guidance like AGENTS.md notes and recommendations, even when I explicitly ask for readable, well-commented, maintainable code.

I tested Claude as well, and I was impressed by how readable and easy to understand its output is. I’m not saying Claude is “the best”—I’m sharing this feedback because I want the trainers to improve Codex. Benchmarks don’t tell the full story: developers care a lot about code readability and developer experience, not just whether the solution works.

Please improve the model’s focus on developer-friendly output: clear structure, simple implementation choices, and helpful comments. Right now, the generated code often feels like JavaScript obfuscation—almost like I asked it to make the code as hard to read as possible. This hurts maintainability and makes developers more likely to switch to another tool, even if the model is capable and the code technically works.

What steps can reproduce the bug?

Working on a large codebase and telling it to add a feature, you will see compacted code with little to no comments. and hard to understand and maintain code

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

etraut-openai contributor · 7 months ago

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 /feedback command. That will provide us with additional details including logs and conversation text.

looper200 · 7 months ago
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 /feedback command. That will provide us with additional details including logs and conversation text.

It’s not about one piece of feedback; it’s about how the model behaves in general. When the model takes on a large task, it always chooses the approach that benefits itself—generating code without explanations or comments and building functions as if it’s the only one who will review them. It doesn’t care about the developer experience, and the code is more compact than it should be. It takes the shortest route.

For example, the expected output would be something like 80% code and 20% explanation as comments, so any developer can jump in and understand the code. But Codex outputs something like 99.5% code and 0.5% very short comments that don’t explain enough. Please tell the trainers to care more about developers.

The code is often too verbose even if it works. That may work for vibe coding, but for actual developers the model should, by default, behave like a real developer working on a team—spending time explaining the code and making it easy to read and understand while achieving the same functionality and complexity.

I used a custom AGENTS.md file, but it doesn’t respect it. When a task requires a decent amount of time, it ignores what I said and just does the job while using the fewest tokens possible. The result is code that’s hard to read and maintain because it’s too compact and not explained. That might be how it was trained, but for real developers this isn’t ideal.