I used to hand large development tasks straight to Codex. Given requirements, it quickly changed multiple files, ran the code and checks, then explained the results. But the most difficult failures were not cases where the code was wrong. The features worked, but it was not the product I wanted.
Codex quickly and faithfully delivered on the goal I gave it. The problem was that I had not spent enough time questioning whether that goal was right.
So I started making plans with Claude first, then handing implementation to Codex. At first, the roles seemed clear. Claude plans; Codex implements. Recently, using Claude's Fable 5 alongside Codex's GPT-5.6 Sol has made this difference even clearer. Both models can now handle a much wider range of work than before. Paradoxically, though, the roles I want to give each have become more distinct.
Of course, reality did not divide so neatly. Claude's plans often broke down when they met the code. When Codex discovered new facts while reading files and running code, the plan itself had to be rewritten. Planning and implementation were less like two sequential steps and more like a process in which each kept revising the other.
It is easy to explain this difference in terms of personality: “Claude is creative, and Codex is meticulous.” But both can plan, implement, test, and review. The performance a user experiences is not determined by the model alone. System instructions, how files are found, available tools and permissions, how quickly errors come back, and the conditions for stopping work all help shape its behavior. Looking at the visible work environment and feedback structure is more accurate than speculating about private training methods.
I find Claude especially useful when the goal is still unclear. For example, there is no single right answer to “an intuitive signup screen for first-time users.” You could show an explanation first, or let people try the product right away. You could start with questions to distinguish different types of users. What matters here is not the ability to settle quickly on the first answer, but the ability to lay out different possibilities.
But the blanks Claude fills in are the model's guesses, not my intentions. A plausible result does not mean it understood the requirements correctly. So I need to treat Claude's first answer not as a finished plan, but as a hypothesis I can compare, test, and discard.
Where Codex is strongest, there are many things that can tell it it is wrong. If a file is missing, the search results tell it so. If the code is wrong, compilation or execution produces an error. If it breaks an existing feature, automated checks or the actual screen reveal it. However plausible the model's explanation sounds, there is a dense web of feedback through which reality can push back.
Implementation, then, is not simply transcribing a plan. It is an experiment that tests the plan's hypotheses against actual code. Codex reads files, makes small changes, runs the code, and traces the causes of failures. Through this repetition, it narrows the options and eliminates faulty assumptions. Errors in a plan may only emerge after much of a feature has been built, but many errors during implementation come back sooner.
As an analogy for my own workflow, Claude is strong at going from 0 to 1, and Codex at going from 1 to 100. Using the latest models, Fable 5 and GPT-5.6 Sol, has made this contrast even clearer. Claude produces several possible 1s, and Codex takes the chosen 1 to 100 by putting it up against reality. This is less an assessment of the two models' abilities in general than a description of how I use them.
But this picture leaves out one important step. The person between 0 and 1.
Even if Claude suggests three directions, which one becomes the actual 1 is not decided automatically. A person has to weigh the problem to solve, the features that cannot be given up, the acceptable scope of changes, and the cost of failure, then choose. If I hand Claude's answer to Codex without that judgment, the result is a polished implementation of a wrong hypothesis.
So when I start a large task, I ask Claude to do research and interview me about what I want. I have it separate confirmed facts from the model's guesses, and compare several approaches rather than offer one right answer. Once I choose a direction, I add the scope of changes, the behavior to preserve, the completion criteria, and the stopping conditions, then pass it to Codex.
I tell it to stop if it encounters unexpected files or dependencies, or if the scope of changes grows. Stopping is not failure. It is new evidence that the plan has collided with reality. I get back the relevant files, the commands that failed, and the assumptions that proved wrong, and use that evidence to revise Claude's plan.
Passing automated checks is not the end, either. A feature not covered by the checks can disappear while the tests still pass. So I have another model or reviewer who has not seen the work process compare the original requirements with the actual changes. Where possible, I also check the actual screens and user behavior. Another model can share similar blind spots.
Not every change needs this process. Small tasks that are easy to reverse and have a clear scope are better handed straight to Codex. Exploration and selection need to come first when requirements are unclear, multiple features are intertwined, or the cost of undoing a wrong turn is high.
This combination is not a way of working that the two companies agreed to create. It is a user manually stitching together the strengths of two competing products. Both are trying to bring research, planning, implementation, and review into their own products. So it is hard to assume that the current difference in roles will last.
The next competition, then, is more likely to center on the design of the work loop than on a single model's score. Recently, people have started calling this approach “loop engineering.” There is no settled definition yet. Some emphasize automation that replaces repetitive prompting with systems. Others also include agent execution and verification, along with feedback from developers and users.
What I want to emphasize is not simply “put people back in the loop.” Human judgment should be designed as a core part of the loop, not as an exceptional approval step. Human context and judgment need to be part of the whole cycle: setting goals, forming hypotheses, observing execution results, and deciding what to do next and whether to stop.
From this perspective, Claude, a person, and Codex form a single feedback loop. Claude broadens the range of hypotheses. The person considers the purpose and risks, then chooses the next hypothesis to test. Codex uses actual code and execution results to validate or refute that choice. The evidence gathered in the process then changes Claude's plan.
A good loop is not one that simply repeats a lot. It needs fast execution, reliable feedback, a record of the reasons behind decisions, and clear stopping conditions. If automated checks are measuring the wrong goal, a fast Codex optimizes the wrong answer faster. If faulty assumptions remain in the record, Claude repeats the same plan. The faster we go, the more often we need to question our goals and evaluation criteria.
Memory matters too. The next task needs to inherit which approaches were discarded, where they collided with reality, and why the plan changed. Observed facts must also be separated from the guesses made at the time. Stale information and faulty summaries are not memory. They are causes of the next failure.
At the end, there needs to be evaluation from outside the loop. If the model that made the plan and the model that changed the code look only at the same criteria, their blind spots repeat too. That is why we need reviewers unfamiliar with the work process, responses from real users, product metrics, and the operating environment. However fast the internal loop is, without a connection to external reality, it only becomes more refined in the wrong direction.
Loop engineering is not a technique for running AI longer. It is a technique for turning guesses into testable hypotheses and bringing evidence from failures back to the next decision. A well-designed loop quickly eliminates faulty assumptions. A poorly designed loop amplifies the wrong goal faster.
This is where development agents will pull apart in the future, more than in the cleverness of their first answers. Can the system notice when a plan is wrong? Can that fact make its way back to the next decision?
One smart model was not enough. Stitching Claude and Codex together was not enough either. What was missing was not intelligence, but a loop.
