Why Codex Still Beats Claude Code for Complex Python Monoliths

Over the last year, a developer working on a complex Python monolith has primarily used Codex. After a month testing Claude Code with Opus 4.6 and 4.7, they still prefer Codex for this codebase. The application is not a simple CRUD server — it has a newer DDD-ish layer, older well-structured code, and fragile legacy spaghetti code. The team avoids rewriting old parts unless necessary.

Key Advantages of Codex

• Harness-engineering principles: Codex reliably follows the harness-engineering workflow without explicit instructions. Claude only does so if AGENTS.md contains a directive like “Read exec_plan.md and follow it.”
• Reuses existing tools and patterns: Claude more often creates new tools instead of searching the codebase for existing ones. In a codebase with many project-specific helpers, reuse is critical.
• Better planning and context awareness: Claude frequently reads too little before placing new functionality. The developer had to repeatedly correct:

“Put this functionality in module A instead, not in the controller.”
“Do not construct the response object using the statuses you sent in the request. The API already returns the updated object — use that response.”
“Validate it in the same module that owns this boundary.”

Codex more often notices missing context and asks clarifying questions before making architectural changes.

Where Claude Excels

For frontend work, Opus 4.6 was much better than Codex 5.3 and GPT-5.4. The developer currently prefers Claude for UI tasks. They have not tested GPT-5.5 on UI-heavy work yet.

Tool Configuration

Both LLMs use a single shared skill: commands to start and stop Docker Compose and run tests inside the container.

---

This is not a benchmark, just daily-use experience from one production codebase.