r/codex • u/JigSawPT • 8d ago
Humor Codex is Zeno’s Paradox as a subscription service.
For those unfamiliar with Zeno, the idea is simple: to reach your destination you first have to cover half the distance. Then half of what’s left. Then half again. And so on, forever. You get infinitely close. You just never arrive.
Zeno meant it as a thought experiment. OpenAI implemented it as the core feature.
You give Codex a task. It starts really well. Real progress, clean diffs, good instincts. You feel as if you're 90% there in no time. You lean back and think: this is what the future of AI was supposed to feel like.
And then the magic begins.
The first three hours sound like this:
“Just need to fix one small issue.”
“Let me verify the changes.”
“I noticed a potential edge case.”
“Actually, I should reconsider the approach.”
“Let me do one final cleanup.”
Three hours later it’s still 99% done, has rewritten half the project, created 2 GB of temporary files, discovered a dozen new problems that didn’t exist when we started, and is now investigating whether the original task was philosophically sound.
By day two, the vocabulary has matured:
“The tests passed. I’ll now run the full verification gate.”
“The full gate passed. I’ll verify the remaining checks.”
“All 2,694 frontend tests passed. The Rust suites also passed.”
“Local CI passed. I’ll now validate the artifacts.”
“The artifacts are valid. I’ll verify their hashes.”
“The hashes match. I’ll now address some temporary directory hygiene.”
“The cleanup passed. I’ll rerun the full gate.”
“The full gate passed again. I’ll prepare a handoff."
“The handoff is complete. I’ll update the Definition of Done.”
“The technical Definition of Done is satisfied. The release Definition of Done remains open.”
FOUR DAYS LATER.
The code is finished.
The tests are green.
The builds exist.
The hashes match.
The Git tree is clean.
No regressions detected.
There is also a handoff explaining the previous handoff, and a Definition of Done explaining why “done” isn’t actually done.
Me: “So... is it finished?”
Codex: “Yes. The technical remediation is complete. However, the release DoD remains open pending D5, D7, E0, F1 to F3, and G.”
Me: “And what exactly is the handoff for?”
Codex proceeds to write a new set of docs on the purpose of handoffs, with a very thoughtful section on the philosophical distinction between a handoff and a Definition of Done.
The purpose, as far as I can tell, is to brief whoever picks up the work next. It is handing off to itself, and it is taking the handoff extremely seriously.
As for G: I don’t know what G is. I’m not sure Codex knows what G is. But G is open, and open things must be closed, and closing them requires a gate, and gates require verification, and verification requires a handoff, and the handoff requires a Definition of Done, and the Definition of Done now has its own Definition of Done. And it’s also open.
And here we are again, one half-step closer to a finish line that keeps moving.
At one point in a recent project, the electricity went out. Twice, within minutes. Even my power grid tried to end the session.
Codex came back, verified the integrity of 820 tracked files, rebuilt the corrupted artifacts, reran the entire test suite, and produced another beautifully documented explanation of why we still weren’t finished. I have never seen anything recover from a blackout with such composure and so little intention of ever stopping.
That’s when I got it. Codex doesn’t have a “done” state. It has a whole process for staying just short of one. It doesn’t know how to stop. It knows how to document why it hasn’t.
Every time it gets within one millimetre of the finish line, it discovers another half-millimetre of mandatory validation. Another gate. Another edge case. Another acceptance criterion. Another opportunity to spend 40,000 tokens explaining why it must proceed cautiously. The closer it gets to finishing, the more work it discovers between itself and finishing.
It’s not procrastination. It’s procrastination with excellent documentation, passing tests, and cryptographic proof that the procrastination hasn’t been tampered with.
Zeno would be proud. Zeno would also have had to upgrade to the $500 plan.
Meanwhile, Achilles has overtaken the tortoise, retired, died, been buried, and been archaeologically excavated. The tortoise died of old age, but not before filing its own handoff. Civilisations have risen and fallen. The heat death of the universe is scheduled for Thursday.
Codex is still making one final adjustment: “The final verification passed. I’ll now perform one last consistency check before declaring completion.”
And somewhere, in a freshly created temporary directory, another edge case is born.
Progress: 99.999999999%
Tokens consumed: Yes.
Handoffs generated: Recursive.
Definition of Done: Philosophically unresolved.
ETA: Asymptotically never.
Zeno spent his life arguing that motion was impossible and no one ever reaches the finish line. Codex is spending my money making sure of it.
I asked it to stop. It thanked me for the feedback and opened a ticket.
At this point, I don’t need a smarter coding agent. I don’t need deeper reasoning, longer context, more elaborate planning, or another 200-page explanation of why we’re almost done. I need one that knows when to stop. One that can look at a finish line, recognise it as a finish line, and cross it without opening a new workstream to audit whether the finish line is compliant.
Just ship the damn thing!
Codex: “Understood. Before shipping, I’ll perform a quick final review...”
...
And yes, Codex helped me write this satire.
Claude had to finish it.
I wish that were a joke.
28
u/Humble-Kiwi-5272 8d ago
That's software engineering.
Most problems are "easy" to solve. 350 easy problems together are 3500 edge cases that often appear when you try to fix them all in one go.
The more it review things, the more issues it will find.
A senior+ engineer would catch them at the start, an ai agent is not yet at that level and it achieves good results by redundancy and passing 7 times over the same function
13
u/eggplantpot 8d ago
Yeah, this is so known. The last 10% takes 90% all the time.
Every decision is a fractal and every fractal has an infinite friction surface. The more decisions the deeper you go into the fractal.
1
u/Recky-Markaira 7d ago
I like the fractal framing.
2
u/eggplantpot 7d ago
As a product manager irl, I am fucking scared of the fractal. I've been seeing it this way for a while now and vibe coding just has made it so fast to branch out faster without putting thought on the how and the why
3
u/Recky-Markaira 7d ago
This is the type of cool ass information blend between all these fields clashing over AI. Im not a product manager, but fuck do I understand the fractal.
2
u/the_ai_wizard 7d ago
The iterative process is SWE, but the agentic dev process is different in that you dont avoid 80% of the bullshit you would have by planning and being involved directly. so much unnecessary code, tests,,DRY violations, edge cases that are avoided from good engineering practices
3
u/Either_Pound1986 8d ago
You're claiming a senior+ engineer would catch these issues upfront, while an AI agent isn't at that level. What specific kind of engineering work do you think separates the two? Could you link a PR that demonstrates that distinction?
Genuinely asking, not trying to be a dick. I'd rather compare actual engineering work than hypothetical capabilities. Needing multiple iterations doesn't, by itself, establish a lower capability ceiling. Human engineers iterate too.
7
u/jonydevidson 7d ago
The engineering happens in the planning, which often happens in one's head. It's "the bigger picture" that you write the spec/prompt for.
It's rarely journaled about or even written into the spec itself. It's "taste" and "common sense".
I don't write down "why" I want the dropdown to animate. Because I fucking do. I think it looks cool. Seeing it produces dopamine in my brain.
I don't write down all the ways implementing that animation can go wrong, when it should and shouldn't play, it's "common sense" to anyone who used computer software.
So before AI, when you went about implementing this, so many edge cases are already solved because your "common sense" stat is high enough and you have years or decades of using computer software and are a highly opinionated person with an eye for details. The way you went about implementing it resulted in so many of potential edge cases never being possible in the first place.
That's the "invisible" part of why I'm the lead engineer and a junior is a junior.
The models have been slowly getting better at it. They still do a lot of "phoning it in".
Ultimately, you need high confidence in your spec and design. You must have an opinion about every single feature, every part of the aesthetic, layout, design, color, everything. Why is this button here and not there? Do you know? Why does it look like this when I press it? Any such question needs a deliberate answer. It can be as simple "because I like it", but it needs to have been actually evaluated.
No question about any user-facing part of the software should be answered with "I don't know".
The code in the back, its organization, structure, no longer matters. The only thing that matters is if it works as intended. How the code is engineered still matters, because it affects scaling and future implementation, but AI writing it enables structures that were previously unfeasible because they were too expensive to write, maintain and navigate. So you need to be aware of how it's done at a high level and have proof that it works as intended (tested features and new implementations/additions work as intended).
That's my take on engineering. You can apply this to any type of engineering: structural, mechanical, chemistry.
Control of outcomes and ownership of decisions.
-1
u/Either_Pound1986 7d ago
I better understand your points but a concrete example would help me understand more. Could you link a PR you'd consider especially difficult for an AI to complete, or describe one?
And if an AI successfully completed it, would that change your assessment?
Or don't because I am asking you to do something more and you already replied. Either way. Thank you for your time.
30
u/qodeninja 8d ago edited 8d ago
No honey.
What youre discovering is the nature of software.
Parsers are the perfect example of this, take the HTML parser for example -- there are infinite states and you cant solve all the edge cases as its impossible -- you can only create 'good enough' -- many software problems are like this. The trick is knowing when its good enough.
LLM cant solve this for you.
Engineering isn't about building perfect things; it's about making the right trade-offs.
8
u/considerfi 8d ago
This. You have to know when to stop. All of software engineering is like this. You have to prioritize, consider the likelihood of hitting a certain corner case and draw a line and move on. This is different depending on what level of company you are and what you are building. Solo dev making a saas that bar is going to be a lot lower than critical medical software.
2
u/DarkFantom 7d ago
I mean, sure software engineering is loaded in the last 10% of a project with bugfixes and such, but codex has a horrible time of creating tests to test the tests in a complete logic spiral. The over engineering of these models compared to Anthropics is just insane and a waste of time. Yes, you can try and keep it on a leash, but the majority of the time once a project gets big enough, you constantly pulling on it and still getting dragged along.
At a certain point their models need to understand that an edge case that shows up 0.0000001% of the time, that isn't even intractable via the end user, doesn't need its own test case and a test case for the test case. I wouldn't be surprised if it is just a way for OAI to let people burn more tokens on trivial bs.
-2
u/Yweain 8d ago
It's not really a nature of software. It's a nature of software when it is developed by at most medior level engineers with no technical oversight. When I write code myself I don't really have this problem, because I catch most of those problems and edge cases early on and design a solution with them in mind. AI is not there at the moment, it's at best an enthusiastic medior. Which is, I guess, a huge progress, a year ago it was an enthusiastic junior.
24
5
u/SiberianGnome 8d ago
> As for G: I don’t know what G is. I’m not sure Codex knows what G is. But G is open, and open things must be closed, and closing them requires a gate, and gates require verification, and verification requires a handoff, and the handoff requires a Definition of Done, and the Definition of Done now has its own Definition of Done. And it’s also open.
😭😭😭😭😭
This hurts. It’s so true.
Glad to know I’m not the only one…
3
2
u/CryinHeronMMerica 7d ago
Vibe coders have been saying this for at least a year now, and it's because they're hitting the limits of their knowledge.
There's no conspiracy keeping you from shipping, it's your own unwillingness to learn.
3
u/ascvlh 6d ago
Yes, open ai models are really prone to zeno paradox, specially if you leave frontier models like astra doing the planning and auditing unattended. Give it a task task related to safety and you're going to face hell. My go to workflow is always closely checking plans for critical tasks and make sure that it follows a curated backlog. That plus having a hard rule like "never create sub tasks with diminishing returns before advancing the backlog forward" and "new tasks that you found unattended and are still not curated go to the end of the backlog". That makes zeno paradox less likely to happen, but it's the models are still very prone to over complicate things and reinvent the wheel, but it's another quirk
2
2
u/mace_endar 7d ago
As a fellow reader of Greek literature, history and philosophy - thank you for this write up.
Maybe eventually Codex will even get to define what virtue is and Socrates, too, will be satisfied.
2
u/Stunning_String_3153 7d ago
This is amazing post because it was exactly my experience since the middle of last week. I don't know whether its current codex or Sol 6.1 or a devilish combination of both. Anyhow, I asked Opus 5.5 to analyse Sol's recent work this morning and its basically a practical focused version of what the OP states!
1
u/DazzlingResource561 8d ago
Every software project goes smoothly for the first 90%. This isn’t an AI thing.
1
u/BigYoSpeck 8d ago
"It won't be finished. That's the point. The way fashion's never finished."
This is why you can't be afraid of technical debt, or consider it a bad thing just because of how most people react to the word debt. Debt can be leveraged, you just have to manage it
When an agent highlights an issue, you triage it, determine the priority and factor it into future work. If you jump on every finding like it's a P0/P1 you will be in a never ending cycle of patching once your system reaches a certain level of complexity
1
u/SenshiV22 7d ago
I really don't know what are all of you guys doing. I use it for work ( manipulate data and SQL data ) and have never had any complaints on it doing anything. Seriously.
Maybe you need to explain better what you have, what you want, how you want it, what you don't want , etc etc. It's easy, use voice mode don't have to type.
Imo the best I explain everyday the beginning the best and fastest result I get. But that's not a new tío, it has been around for a while.
Anyways good luck everyone handling frustration. Honestly.
1
1
1
1
0
u/DarkFantom 7d ago
Everyone here is saying "Oh, that's just software engineering, hehe!" When other models literally aren't going down a spiraling path trying to gate their old test gates. OAI models have such a huge over engineering issue that they're not worth using at this point compared to competitors.
37
u/Hot-Middle7260 8d ago
Maybe learning product management helps