Agentic development has changed how I build software. Not autocomplete, not chat-with-your-code: an agent that plans, writes, tests and refactors on its own, while I direct and review. If you write TypeScript or Java, tools like Claude Code and Cursor make this the normal way of working now. The toolchain is simply there.

If you build in Mendix, it isn't. At least not in the same way. I've spent a fair number of evenings figuring out why that is, and what the realistic options are. This post is the result.

Why Agents and Mendix Don't Naturally Mix

Three reasons, and they're worth understanding because they explain why each route below looks the way it does.

The model isn't text. A Mendix app lives in an .mpr file. Under the hood that's a SQLite database, with the model stored as BSON documents, one per unit: a microflow is a document, a domain model is a document, and so on. Agentic tools are built around reading and editing plain text in a working directory. Point Claude Code at a Mendix project and there's nothing to grep, nothing to diff, nothing to patch.

The training data is thin. LLMs are good at React because the internet is saturated with React. For Mendix, the training data is the documentation, the forum, and a handful of blogs. The models have never seen millions of Mendix examples, so they can't lean on pattern recall the way they do with mainstream languages.

There's no obvious seam. Mendix development happens in Studio Pro, a visual IDE. There's no terminal-and-files workflow for an agent to slot into. And whatever the AI produces has to land inside the visual model, correctly wired up. A microflow isn't valid because the syntax parses; it's valid because every activity, variable and connection checks out against the rest of the model.

So the real question is not whether AI can help with Mendix. It's where you give the agent its hands.

The Route I Tried First: the Model SDK

My own first answer was the Mendix Model SDK. It's a TypeScript API onto the full Mendix metamodel: entities, microflows, pages, security. Almost anything you can do in Studio Pro you can do in code, which means an agent could do it too. Let the LLM write SDK scripts, run them, and you have agentic Mendix development.

I built an MVP on exactly that idea, and it worked. Describe what you want, the agent generates a script, the script modifies the model. As a demo it impressed everyone I showed it to, including me.

Production was another story, and the problems turned out to be structural rather than fixable:

  • The SDK doesn't touch your local files. Every script opens an online working copy on Mendix's Model Server, applies its changes there as deltas, and commits them back to Team Server. That puts a network round-trip, and a cloud dependency, in the middle of every single iteration.
  • The feedback loop was brutal. Generate code, run it, wait for the working copy, commit, pull the change down, open Studio Pro, and only then see whether the agent did what you meant. Minutes per attempt, in a way of working that lives or dies on seconds.
  • The metamodel is large and strongly typed, and public SDK examples are sparse. The LLM hallucinated API surface constantly: plausible-looking property names and method calls that simply don't exist. And every hallucination cost a full round-trip to discover.

The Model SDK proved the concept. The interface was wrong. The real options today are three others.

Route 1: Maia, Mendix's Own Agent

Maia is Mendix's native AI, and it has grown from an assistant into an actual agent inside Studio Pro. It can scaffold an app from a description, create and modify microflows and pages conversationally, and suggest next steps while you model. Two details are easy to miss but matter. Maia runs on the same extension API that Mendix has opened to third parties, which is what makes route 2 possible. And Mendix is exposing Studio Pro's capabilities through MCP, so external agents can drive Studio Pro as well, instead of only the chat panel inside it.

What you get: zero setup, official support, an agent that works directly on the open project, and something every skill level on the team can use.

What you give up: it's a closed system. You don't choose the model, you can't extend its tools, and you can't wire it into your own agentic pipeline. When you hit its ceiling, there's nothing you can do about that ceiling except wait for Mendix.

Route 2: Build (or Buy) Your Own Agent in Studio Pro

That same extension API is available to everyone. I've built Studio Pro extensions with it myself (there's a series on this blog): you write TypeScript and React, your UI runs in a web view inside Studio Pro, and the API gives you programmatic access to the open model. Those are all the ingredients for an agent. Put a chat panel in the IDE, call whatever LLM you want, and translate its output into model changes through the API. Because you're working on the open project, in memory, you skip the Model Server round-trip that killed my SDK experiment.

The proof that this works is AIDE Pro by Golden Earth, currently in open beta. It runs as a Studio Pro extension, reads your entire app model for context, and creates real Mendix artifacts, from domain models to microflows to pages, from natural language. It supports Claude, OpenAI-compatible endpoints, Bedrock, Gemini, and local models. Its CLI Bridge even lets external agents like Claude Code drive its 67+ tools, which quietly turns Studio Pro itself into a tool an agent can call.

What you get: your choice of model, your own toolset, and an agent that sees exactly what you see in the live project.

What you give up: you're depending on a third party or on your own engineering hours. The extension API has a real learning curve (I can confirm), and you can only ever do what the API exposes.

Route 3: Mx CLI, Straight at the .mpr File

Mx CLI sidesteps Studio Pro entirely. It's an open-source command-line tool that reads and writes local .mpr files directly — remember, SQLite under the hood — and gives you MDL, the Mendix Definition Language, an SQL-like syntax over the model:

SHOW MODULES;
DESCRIBE ENTITY Shop.Product;
CREATE ENTITY Shop.Order (
  OrderNumber: String(20) NOT NULL,
  Total: Decimal(10,2)
);

This is the route that makes Mendix look like every other codebase to an agent: a terminal, files on disk, a readable text representation of the model. It also plays directly to an LLM's strengths. Models have seen oceans of SQL, so a compact declarative syntax lands in familiar territory and costs few tokens, far more natural for an LLM than a sprawling TypeScript API. Everything runs locally, so an iteration takes seconds instead of minutes. And the agent support is built in: a single mxcli init --tool claude generates the instructions and skill files an agent like Claude Code needs to work with your project through MDL.

What you give up is real, though. It's a community project in alpha, and the maintainers are blunt about it: it can corrupt your project files, so you work on copies. You also step outside Studio Pro's consistency checking, which quietly verifies more than you realize until it's gone. MDL is one more language to learn, and coverage may trail the newest Mendix releases.

So Which One?

The diplomatic answer is that they complement each other: Maia for the quick wins inside Studio Pro, a custom extension when you need an in-IDE agent under your own control, Mx CLI when you want Mendix to join the same agentic workflow as the rest of your stack. That's true, but it's also a bit of a cop-out, so here's my actual take.

If you want something working today and don't care how it's built, use Maia and don't overthink it. If you live inside Studio Pro but want to pick your own model and tools, look at AIDE Pro or build on the extension API yourself. And if you're a developer who wants to plug today's agentic toolchain — terminal, files, version control — directly into Mendix work, start with Mx CLI. That last route is where my own curiosity sits, and I expect I'll write more about it.