Codex vs. MiniMax M2.1: replicating FoodCheck with two different AIs

Comparing two AIs programming is not just about seeing who writes better code. In practice, the most relevant difference appears in how they understand an open task, how much context they need, what decisions they make when something is not completely specified, and how they react to corrections.

To prove it, I have carried out an experiment: I have cloned FoodCheck, an app published on GitHub Pages, maintaining the same business logic and the same interface. This is the result.

The challenge had the condition that the app had to be 100% static. GitHub Pages does not run servers, handle server-side environment variables, or allow a backend traditional.

The same application, two AIs: 

• Codex (model gpt-5.1-codex-max), my previous assistant to develop the original app.
• MiniMax M2.1 (Chat-Agent), with whom I have tried to replicate it by simply giving him the URL to analyze it.

The contrast between both styles was more interesting than I expected.

FoodCheck as a case study

FoodCheck is not just an interface where you upload a photo and numbers appear. Below are critical architectural decisions:

• Advanced computer vision capable of interpreting complex dishes, not just isolated objects.
• Nutritional data and rules that depend on the user's health profile.
• Local persistence (daily logging) without database.
• Static deployment required on GitHub Pages.

These restrictions are not technical details, they are the product. And this is where the way each AI works makes the difference.

Codex as a co-pilot: very powerful, but needs well-defined tasks

With Codex (gpt-5.1-codex-max) the general feeling was that of having a solid co-pilot. With one nuance: if you do not divide the work into very specific tasks, it tends to take more detours. And also, when the app grows, sometimes it forgets what it did several messages ago and you have to explain the context again.

It's not that he makes mistakes, but that he tends to disperse if you don't guide him: he needs you to divide the problem into more concrete steps, he can propose intermediate solutions that don't quite fit with the final deployment, and sometimes he insists on standard web development patterns even though they clash with previous restrictions.

In my case, this was especially noticeable in two points: food detection and adaptation to a static app.

Simulated detection as a starting point

Just as it happened to me later with MiniMax, the starting point was a simplified dummy detection, sufficient for the UI and flow to work but not acceptable if the goal is real plate analysis.

I learned that, if you don't insist, the AI prefers to close the visible product first and then fine-tune the technical heart.

Getting to a workable solution for GitHub Pages took iterations

Codex was proposing ideas that are normal in a general web development environment (for example, .env style configurations or pieces specific to a backend). But in GitHub Pages that is not feasible.

It was necessary to iterate until we landed on a solution compatible with a static app, where the intelligent part lives outside the frontend (for example, via external services).

Conservative initiative

Not having been given an explicit indication of which nutritional database to use, Codex opted for a very small local database, with manually entered nutritional values for a few foods. From an incremental development point of view, this decision makes sense, as it allows you to move forward without external dependencies and validate the entire flow of the application.

However, it also shows the pattern of Codex as a co-pilot, tending to choose safe solutions if not forced to expand the scope. Integration with a real database like OpenFoodFacts did not arise through domain inference, but only when explicitly told to do so. Codex doesn't make mistakes, but it also doesn't assume product context if it's not asked.

MiniMax M2.1 as an agent: speed, focus and good context inference

with MiniMax M2.1 The approach was different from the beginning. I used it directly to replicate FoodCheck.

The difference was seen immediately, since in just a few minutes he was able to:

• Make a first visual and logical reading of the original product.
• Create folder and files (index.html, stys.css, app.js, README.md).
• Deploy a functional initial version.

And he only corrected himself without me seeing the error, I only saw the final result working.

Nutritional database without explicit instructions

A key detail is that I didn't have to mention OpenFoodFacts. The agent included it on his own initiative as a source of nutritional data, demonstrating a superior inference capacity about “what an app of this type needs.”

Of token in the frontend to correct system design

When integrating LLaVA via Cloudflare, MiniMax initially proposed that the user input its API token in the app. It is a quick solution, but very bad from a user experience point of view.

When asked for an alternative, the agent took a major leap: he proposed a Cloudflare Worker as proxy to save the token safely and maintain the frontend completely static.

In practice, this was the point where MiniMax showed more system instinct and greater ability to close a complete product solution, not just code.

MiniMax's weak point: interface fidelity

However, this autonomy that shone in the backend, failed in frontend. Where MiniMax M2.1 failed to hit the mark was in exact replication of the interface.

Although he tried to replicate the design exactly and even deployed versions claiming that he had succeeded, there were still differences. And this connects with a practical reality, which is that “similar” is easy, but “identical” is more complex.

An agent can approximate styles, but to reliably clone an interface it usually needs direct access to the original CSS, assets and a methodical visual validation (comparative captures, style inspection, etc.). Without that, you stay at “very similar” filling in the design gaps with your own imagination.

The shared stumbling block with the “minimum viable”

Despite their differences, both AIs fell into the same trap at the beginning: simulated or simplified detection. But this is not a rare error, it is a pattern. The “shell” of the product is built, and then the actual motor is connected.

Both Codex at the time and MiniMax later proposed using TensorFlow.js + COCO-SSD by default. The problem is that COCO-SSD detects only certain specific foods, but does not detect foods from a normal plate of food. For a food app, that's useless.

This teaches us a lesson, which is that AI tends to take the path of least technical resistance. He prefers to close the visible product with a standard library rather than look for the complex solution (multimodal models) that is really needed. I had to intervene in both cases to force the use of real vision.

What Codex brings that MiniMax doesn't

Codex's main strength is not speed or autonomy, but control. When the developer is clear about the design, constraints, and expected outcome, Codex behaves more predictably and less creatively in a bad way. He rarely invents unsolicited architecture, data sources, or flows if he has been given the right orders.

This reduces the risk of elegant but product-incorrect solutions. The cost is that it requires more prior work: decomposing the problem, anticipating constraints, and actively guiding the path. Codex doesn't usually close the system for you, but it does better respect what you define as correct.

What MiniMax brings that Codex doesn't

MiniMax M2.1 stands out when the problem is open and the goal is to have something complete up and running as soon as possible. Take the initiative to make the code a market solution and not a standard based on what most developers do. Its ability to infer context (such as choosing OpenFoodFacts without explicit prompting or proposing a Worker as proxy sure) demonstrates greater product and system instinct.

This autonomy greatly accelerates the first phases, but introduces a risk. The model tends to decide what is good enough if it is not given clear metrics. MiniMax doesn't wait for you to define all the details, it takes them on. That makes it a solution generator, but an assistant that needs constant auditing when fidelity matters.

Also, MiniMax seems to be a better detective. If the code fails, MiniMax often looks at the error and proposes a solution that fixes the current problem and even future problems that one has not yet seen. Codex usually limits itself to fixing only what you ask it to do.

Conclusion: two styles of AI, one human responsibility

This experiment leaves a clear reflection, and that is that today, with AIs, making an app exist is cheap. In minutes you can have files, screens, even an entire flow displayed. The complexity begins when your goal is not simply for it to work, but for it to be exactly what you want.

The two AIs, in different ways, filled in gaps. If you don't define precisely what the architecture should be, they propose one. If you do not define what “vision of complex dishes” means, they offer you the most handy model. And if you don't implement visual fidelity, they give you a “quite similar” interface and consider it good.

Therefore, AI is the approximation engine, but the developer is the measurement system. And measuring is not just passing unit tests. In products like FoodCheck it also means checking that the deployment meets restrictions (GitHub Pages, without backend), validate integration (tokens, CORS, endpoints, “Failed to fetch”), and have a tangible criterion for the subjective (what is “identical” in an interface).

If we must highlight any practical difference between both models, it could be said that with Codex the human work is concentrated at the beginning, clearly defining tasks, restrictions and architecture. With MiniMax, the effort shifts to the end by reviewing decisions, detecting incorrect assumptions, and validating that you really have what you wanted.

Neither eliminates the developer's work; It simply moves it around. Choosing one or the other is not so much a question of the power of the model as of which phase you prefer to invest your attention in. But in both cases, the end result depends less on the model than on how clearly the developer defines what counts as success.

In any case, perhaps the most interesting lesson of all is that when you have an assistant who programs quickly, work moves. It is no longer so much about writing code, but rather defining precisely what counts as correct. Because, if you don't define it, the AI ​​will define it... and it will do it in its own way.