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. This is one experience with the versions and configurations used, not a general benchmark of the two systems.

To explore this, I ran a test: I attempted to replicate FoodCheck, an app published on GitHub Pages, aiming to preserve its business logic and interface. This is the result.

The part hosted on GitHub Pages had to be static. This hosting does not run server-side code or provide a backend service. The browser can still call external services: the Worker discussed below runs outside GitHub Pages.

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), which I gave the URL to attempt a replica.

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:

• Interpreting images of complex dishes, with estimates that need checking.
• Nutritional data and rules linked to the user-entered profile, not a validated clinical assessment.
• 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.

In this test, it tended to lose focus without specific instructions. I had to break the problem into steps, review suggestions that did not fit the final deployment and repeat constraints when it proposed incompatible web-development patterns.

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 proposed common web-development configurations, including .env files and components requiring a backend). Build-time variables are not server-side secrets: any value included in code downloaded by the browser is exposed. Server-side code needed separate hosting.

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 start. I used it to attempt a FoodCheck replica.

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 the folder and files (index.html, styles.css, app.js, README.md).
• Deploy a functional initial version.

The agent also corrected some errors during the process, so sometimes I saw only the resulting version.

Nutritional database without explicit instructions

I did not have to mention Open Food Facts: the agent proposed it as a nutritional data source. In this test, that initiative fitted the application’s needs well.

From the token in the frontend to correct system design

When integrating LLaVA via Cloudflare, MiniMax initially proposed that the user input its API token into the app. That complicated the experience and required checking how the credential was handled; a shared key should not be included in public code.

When I asked for an alternative, it proposed a Cloudflare Worker as a proxy to save the token outside public code while keeping the frontend static. The Worker is still an external server-side service and needs its own access controls, limits and configuration.

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 it tried to replicate the design exactly and even deployed versions claiming success, 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, the result remains “very similar” filling in the design gaps with its own assumptions.

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 initially proposed TensorFlow.js + COCO-SSD. COCO-SSD recognises a limited set of object categories, including some foods, but does not by itself provide the ingredient and quantity analysis of complex dishes that I wanted for FoodCheck.

My lesson from this test was that both prioritised a working interface with a familiar library before solving image interpretation. I had to specify that requirement more clearly and review multimodal alternatives; a more capable model still needs its estimates validated.

What Codex brings that MiniMax doesn't

In my experience with this version of Codex, its main strength was control. When I clearly defined the design, constraints and expected result, its suggestions fitted the request better. That does not eliminate errors or guarantee the same behaviour on other tasks.

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 I wanted a working first version quickly. In my test, it made more decisions on its own, such as choosing Open Food Facts or suggesting a Worker as a proxy outside the static site. I found these decisions useful, although they needed review.

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 deployed. 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 readily available model. And if you don't implement visual fidelity, they give you a “quite similar” interface and consider it good.

That is why generation needs to be accompanied by measurement. In FoodCheck, this meant checking the deployment constraints: static files on GitHub Pages and external services for any backend, checking integrations (tokens, CORS, endpoints, “Failed to fetch”), and setting concrete visual criteria for deciding whether the replica was faithful.

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 shifts it. 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.