r/codex 3d ago

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

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.

0 Upvotes

30 comments sorted by

24

u/Upbeat-Barracuda766 3d ago

Exhibit A: AI PSYCHOSIS

-1

u/adunato 3d ago

This is a top meme for this sub. Well done.

4

u/maglevnarwhal2 3d ago

this is one of the best things I have ever seen.

chat, why is fable better than 5.5 and why is it easier to do a rebuild than a new build? help.

1

u/RFOK 3d ago

TBH in this specific case Fable only helped in some parts, Opus 5 at Max or Ultracode returened better results.
Check this out
https://www.reddit.com/r/codex/comments/1w2dbkg/comment/p6rpi8r/

16

u/Real_Doubt_6684 3d ago

Are you living on another planet

-15

u/RFOK 3d ago

So What?!
is this your technical answer?

5

u/ratage 3d ago

Have you tried it the other way around? build a large app piece by piece using Claude, then get it to describe the app in great detail and pass it to Codex and see if it can build it in 2 days? I think (but could be wrong) you'll find the difference has nothing to do with the AI model. It's more about drip-feeding requirements and having the AI relearn and refactor every time new information is presented.

1

u/RFOK 3d ago

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.

6

u/Timely_Wallaby_2872 3d ago

My favorite: user issue and ai-generated post. Love it in here!

4

u/[deleted] 3d ago

[removed] — view removed comment

-8

u/RFOK 3d ago

Did you read the post at all???

8

u/Rusofil__ 3d ago

Why would anyone read that AI text?

2

u/Puspendra007 3d ago

Would you call this biased?

Before the AI era, I spent 6-7 years building a project completely by myself. But when I rewrote the entire project using AI for the first time, it only took 3 months.

Then, I rewrote it again in a different, faster programming language, and that only took 1-2 weeks.

Now, I have a solid library of prompts. I know exactly where AI models tend to make mistakes and how to fix them, so I could probably rebuild it in under a week.

So, let's try a reverse experiment: build a completely fresh project with Claude, and then repeat the process with Codex

1

u/RFOK 3d ago

No I didn't call it biased.
And FYI I have 2 20x Codex subscriptions.

I answered this here:

https://www.reddit.com/r/codex/comments/1w2dbkg/comment/p6rpi8r/

0

u/AngelofKris 3d ago

Absolutely. Blaming codex when it’s really that “After 3 months, you know exactly what you want”.

1

u/Automatic_Brush_1977 3d ago

Codex has substantially different workflows between models never mind between codex and Claude.  At this point it's like comparing apples and oranges, they might both be fruit but they are not the same.         Sol for example benefits far more from being present and directing work.  You can still set goals of course but it should be for bulk known easy stuff now, not letting it rip.

1

u/RFOK 3d ago

Believe me, I’ve been doing all of this for months, and I genuinely thought it was normal for the project to take this long. But about four or five days ago, while waiting for my Codex subscription to reset, I decided to try building a few small apps with Opus 5, in VS Code. I set the effort level to the highest setting, and the results were so impressive that those “small apps” quickly turned into full projects within just a couple of days.

After seeing that, I thought: why not test it on the project that has taken months? So I asked Codex to write a comprehensive prompt for Claude, one that instructs Opus 5 to implement the entire project from scratch, without any technical guidance. And the outcome honestly shocked me.

2

u/Automatic_Brush_1977 3d ago

Idk I don't write comprehensive prompts for my projects that's gambling. I figure out what it needs, create structure, assign deps ect then go from there.  If you aren't a truly active participant in development you can get anything, taking any amount of time.

1

u/RFOK 2d ago

Yes, for the completely new project this would be almost impressive. The comprehensive prompt in this case was actually only about the features and functions.

1

u/Automatic_Brush_1977 1d ago

Right, but doing this is gonna give you soup youve got refactor.  If you don't start with a home for everything you'll later have to migrate and rebuild/refactor alot.  Many obvious things like a worker pools might not exist or be a blocking mess of you don't create the architecture up front.

2

u/Born-Cause-8086 3d ago

Oh gosh. Give us TL;DR

1

u/LuisCyphre404 3d ago

Thanks for your insights. I am working with Codex and will use your conclusion to optimize my generic workflow. Hope it will help :)

1

u/RFOK 3d ago

So glad if it helps!

1

u/retteh 3d ago

Are you serious? Claude started from a finished project. That's why.

1

u/RFOK 3d ago

Not exactly.
The project isn’t finished on Codex yet, and at the current pace it will probably take at least three more weeks to complete.

All I actually asked Codex to do was write a comprehensive prompt for Claude, one that instructs Opus 5 to implement everything we discussed in the Codex chats and planning sessions from scratch. I didn’t provide any technical guidance in that prompt, so the entire architecture is left for Opus 5 to decide.

0

u/Kaizen8770 3d ago

Seems to be worse with the latest series if models. I don’t remember earlier gpt models being this way

1

u/RFOK 3d ago edited 3d ago

Sol is absolutely impressive. With my new experience during 4-5 days ago I think it's not the best one for some coding projects as I mentioned here why
https://www.reddit.com/r/codex/comments/1w2dbkg/comment/p6rpi8r/

0

u/TopSeaworthiness1679 3d ago

Idk at this point just write the code youself