I let Codex and Claude Opus work on the same Java AI agent monolith

I ran a small experiment on my Java pet project and the result was less clean than I expected. Small disclaimer: I did the final comparison review on April 19, 2026. With AI coding tools, that already makes the result somewhat time-sensitive. The project is a multi-module Java monolith with a Telegram bot, an agent loop, tools, memory, streaming responses, and a mix of local models and OpenRouter models. At that point I had already started moving part of the agent logic away from Spring AI into my own FSM/ReAct flow, but the code still had many bugs. So I copied the whole project into two separate branches, gave Codex 5.3 and Claude Opus 4.6 the same vague prompt, and let both agents work almost autonomously. The rules were intentionally simple: * do the task however you think is right * pass the existing tests, including e2e * run review * fix review comments * repeat until only minor comments remain Basically, pure vibe coding. Claude Opus produced the more attractive architecture in several places. The best part was around streaming output. It created a clearer boundary between raw model chunks and text that could be shown to a Telegram user. That matters because models do not stream neat sentences. They can send `<th`, then `ink>`, then internal reasoning, then a closing tag. If you clean the final text only after streaming is done, part of that garbage may already have reached the user. In that sense, Claude's idea was better: filter before emitting user-visible events. Codex was less elegant. More logic was tied to context mutation and post-processing. It felt like code that could become harder to maintain later. But then I asked for a sequence diagram / call chain and found the uncomfortable part: some of Claude's nice architecture was not actually used. The tests were green because the old Spring AI streaming path was still covering the e2e scenario, not because the new ReAct/FSM streaming flow was properly integrated. That changed how I read the whole result. Codex had its own problems. It introduced more state and more concurrency risk. One branch even failed a REST test slice on the full verify run. But Codex also added practical things that mattered: * timeout and fallback for a stuck AI stream * conversation history recovery after restart * URL hygiene before showing links to the user * better separation of progress and final answer in the streaming contract * batching for Telegram progress updates Not all of it was beautiful. Some of it was exactly the kind of code you later want to simplify. But more of it was connected to the working product. That was the main lesson for me: with AI coding agents, "good architecture" and "executed code path" are not the same thing. The second experiment was similar. I compared Codex 5.3 with a newer GPT model on the same area. Again, the stronger model proposed a neater abstraction, but the code mostly did not execute and it did not find the real bugs. Codex was more boring, more direct, and more useful for this specific autonomous development loop. I am not claiming Codex is universally better than Claude. This was one project, one setup, one date, one style of prompting, and one fairly specific task: autonomous development on a Java Telegram agent with minimal supervision. For planning, research, and abstract design, stronger models can be better. Anthropic's own Claude Code setup also points in that direction: Opus is used for planning/advice, while execution often goes through a different model. But for my setup, the practical result was simple: the model that looked less impressive often moved the real product further. The part I am still thinking about is not "which model is best." It is how to evaluate coding agents when they can produce convincing architecture that never actually enters the runtime path. For people building or using AI coding agents: how do you check that the agent's best-looking work is really connected to the product, not just passing tests through an old path?