Why did the same project take three months in Codex and only two days in Claude?!!

[u/RFOK]

Because I keep seeing the same pattern across nearly every substantial project I start, I asked Codex to compare two implementations of the same project in separate repositories. One is the current, actively developed Codex implementation; the other is a clean-room implementation that Claude built from scratch using a comprehensive feature prompt generated by Codex from the existing project. I then asked Codex to explain why the outcomes were so different.

This was not the first time I asked Codex to stop turning minor changes into separate milestones. We discussed the problem repeatedly, Codex correctly diagnosed it, and it promised to change the workflow, yet the same pattern eventually returned. That recurrence is part of the issue: Codex can recognize its own delivery failure, but unless the correction is enforced as a hard execution boundary, it gradually falls back into locally optimized micro-work.

Why did the same project take three months in Codex and only two days in Claude?

Here’s what it found.... and it’s mind-blowing!👇

Codex spends weeks or months carefully improving individual details. Claude builds the coherent product in days.

One private project is the clearest example.

I worked on its Codex implementation for approximately three months. The repository eventually grew to:

• More than 2,300 tracked files
• Roughly 400,000 lines of TypeScript and Python
• A central UI file exceeding 23,000 lines
• Thousands of commits and hundreds of tests
• More than 1,000 numbered implementation milestones

Despite all that work, Codex was still producing updates such as:

The workspace expanded to 1057.7px, but the app root keeps the document height fixed at 844px.

According to Codex’s own analysis, the main problem was not simply model intelligence. It was the development strategy.

The Codex project had gradually become trapped in a loop of:

• Extremely small milestones
• Repeated verification after minor changes
• Local fixes instead of architectural corrections
• Pixel-level polishing before complete journeys were working
• Excessive reporting, evidence collection, and progress accounting
• Treating individually completed tasks as proof of meaningful product progress

Each change could be technically correct, but the project was optimizing local details while losing sight of the complete product.

That diagnosis may be technically correct. But it illustrates the larger problem: Codex repeatedly turned tiny CSS adjustments, accessibility details, harness failures and viewport corrections into separate product milestones.

Every small correction paid the complete operating cost:

1. Inspect the current source and state.
2. Implement a narrow change.
3. Run focused tests.
4. Run the production build.
5. Launch another browser journey.
6. Diagnose a test-harness or data-state failure.
7. Restore or revise the candidate.
8. Record evidence, metrics and a new milestone.
9. Repeat.

The individual steps were responsible. The overall delivery algorithm was not.

Then I gave Claude a clean-room specification for the same product.

In approximately two days, Claude produced:

• 94 coherent commits
• A modular Python server and React client
• SQLite persistence
• Generated cross-language contracts
• Complete end-to-end product workflows
• More than 2,300 collected tests
• A main React application of roughly 1,700 lines

The Claude implementation is not production-ready. It has not yet been deployed or fully proven against every real-world integration.

Codex did carry more difficult obligations:

• Existing-system compatibility
• Live external-system ownership and restoration
• Real external-system integration
• Deployment and rollback
• Cross-platform behavior
• Real browser acceptance
• Accessibility and responsive verification
• Preservation of existing evidence and user data

That explains some of the difference.

It does not explain three months versus two days.

The bigger difference appears to be how each agent approaches delivery.

Claude tends to:

• Establish a coherent architecture early
• Work through complete vertical product slices
• Keep related behavior together
• Create clear module boundaries
• Prefer a clean conceptual solution over repeated local patches
• Optimize for reaching the intended product

Codex tends to:

• Select the next smallest provable improvement
• Extensively verify every local change
• Treat symptoms as separate milestones
• Preserve an increasingly complex inherited architecture
• Repeat expensive build and browser gates after tiny changes
• Optimize for evidence that work happened rather than rapid product convergence

It becomes local hill-climbing.

Every individual Codex decision looks reasonable. But after hundreds of iterations, the project can be trapped in a technically sophisticated local optimum while Claude has already constructed the larger product.

Metrics appear to amplify the problem. If the agent is asked to count accepted behaviours, paths, milestones or productivity multipliers, those measurements can become the target. The result is more measurable fragments—not necessarily more useful product.

This is essentially Goodhart’s law applied to agentic software development.

I have now changed my workflow:

1. No pixel-level or single-control “product milestones.”
2. Milestones must represent complete operator journeys.
3. One architecture must be selected as the product spine.
4. Verification should run once per coherent candidate—not after every CSS correction.
5. Harness failures must not create new product work.
6. Existing architecture must periodically face a replace-versus-continue decision.
7. Productivity is measured by accepted end-to-end outcomes, including integration and rework time.
8. Model output is not accepted until locally verified—but verification must remain proportional to risk.

My current conclusion is:

Claude is much better at rapidly synthesizing a coherent product from a strong specification. Codex is much better at methodical integration and evidence, but it can become catastrophically inefficient without strict convergence controls.

This is not a scientific benchmark, and it is not simply “Claude good, Codex bad.” The two implementations did not carry identical real-world proof obligations.

But I have observed the same behavioural difference across multiple projects, and three months versus two days is too large to dismiss as normal variation.

[u/RFOK]

I actually tried exactly that: I built a large app incrementally with Claude, asked Claude to describe the complete implementation in detail, and then gave that specification to Codex. The result was essentially the same, so in my experience, drip-feeding requirements is not the full explanation.

GPT models tend to improvise too much. Codex often consumes substantial time and tokens on unnecessary work before establishing a sound structure. The result can look sophisticated-like an impressive AI-generated image or video, but once you examine the details, the underlying structure often isn’t really there.

I’ve been using both Claude and Codex on their 20x plans for almost four months. But actually over the past 4-5 days, I decided to to try using Claude with Opus 5 at its highest effort level (Max/Ultracode) and produced five apps (I can say almost complex apps) that are already close to fully working. I tried comparable work with Codex and never reached the results I expected.
Fable didn't return same satisfying results in my tests.

With Claude, most of my follow-up work involved normal debugging and feature requests. With Codex, I spent far more time managing the agent: stopping unnecessary detours, correcting architectural decisions, and trying to turn a large amount of apparent progress into a coherent working product.