What mxto does and doesn't do yet
Trust is built on honest boundaries, not bigger claims. Here is exactly what mxto guarantees, what still needs a human, which Mendix™ versions it covers, and where the edges are.
Structurally safe is not the same as semantically correct
mxto guarantees your AI's changes are structurally safe: the app compiles with Mendix's own build tools, the model round-trips with nothing silently dropped, and every construct type is read and written faithfully. It does not guarantee that a change is semantically correct. A perfectly-built app can still encode the wrong business rule. mxto makes AI-authored Mendix work safe to ship; a human (or a semantic-verification layer) confirms it means what you intended.
How to think about an AI writing Mendix™
Be clear-eyed about where the capability sits, because we are not overselling it. mxto removes the mechanical barrier: an AI agent can now read every construct of a Mendix™ app and author every construct type back, faithfully and round-trip-proven. That part is real, and it is here today. What mxto does not do is think for the AI.
The honest variable is fluency, not capability. Mendix™ is a visual, model-driven platform, and its idioms are far less represented in today's language-model training data than TypeScript, React, or Python. A model that writes idiomatic React in its sleep has seen comparatively little idiomatic Mendix™. So an AI authoring through mxto produces structurally valid Mendix™ every time; producing the right Mendix™, in the platform's own vernacular, still benefits from a human who knows the domain and the platform, directing and reviewing the work. Expect to guide it, correct it, and build up patterns, exactly as you would onboard a strong engineer who is new to your stack. The model and your team get better at it together.
Practically, treat it as senior pair-programming. You set the intent and the guardrails; the AI does the reading and the authoring at a speed no human matches; mxto proves nothing was dropped or broken on the way through; you review for business meaning. The capability is here. The human-and-AI collaboration is what turns it into a correct app, and it compounds as the patterns accumulate.
What always needs a human
- Business-logic intent: does this rule match your policy? mxto authors the change; a person owns the decision.
- Merge approval: mxto produces the change and the diff; a human approves the commit to a shared Team Server branch. The loop is reviewable, not autonomous-by-force.
- Complex pluggable-widget custom content: deep custom content inside advanced widgets (e.g. a data grid with nested custom layouts) still has edges that require the Mendix™ Studio Pro UI.
- A few deep integration sub-properties: e.g. certain REST-call HTTP configuration fields have a documented manual fallback.
Supported Mendix™ versions
Certified across an 8-app portfolio spanning MX 7.23 → 11.6. Cross-version round-trip matched 100%: 1,218 domain units / 854,511 atoms re-emitted and diffed byte-for-byte with zero loss, with mxbuild passing on every gate app.
The edges, stated plainly
| Capability | Status | What that means for you |
|---|---|---|
| Read: Mendix™ model into a typed, queryable form | Full | 100% across 8 production apps, zero transform failures. |
| Write: all 70 construct types (entities, microflows, pages, security, integration) | Certified | Authored and round-trip-certified through the write path used in CI today. |
| Fully offline / air-gapped write path | Growing | A core capability today; full offline page-UI authoring is on the roadmap. Page UI authors via the standard write path now. |
| Pluggable-widget deep custom content (e.g. nested data-grid content) | Partial | Standard widgets are clean; deep custom content has Studio-Pro-only edges. |
| Java action source-body authoring | Partial | The action signature is authored; the Java body is hand-written. |
| Published SOAP / consumed OData (read) | Draft | Read is shallow today, not yet deep-certified. Tracked openly. |
Where the offline path has an edge, the SDK fills it. mxto reads fully offline with no Mendix™ SDK. On the write side, a growing amount is offline-native, and for everything else mxto falls back to the Mendix™ SDK, which is why write coverage is complete (all 70 construct types) rather than partial. Using the vendor's own SDK is deliberate, not a workaround: it keeps authoring faithful to the platform. The trade-off is cost, not capability. The SDK route asks the AI for more inference (more steps and tokens) than a pure offline path would, so you are never blocked; you sometimes pay a little more for the long tail.
What "0 unexpected diffs" means, and what counts as failure
Every write claim is proven by round-trip: mxto extracts the model, re-emits it, and diffs the re-emission against the original.
- 0 unexpected diffs = every difference is an intended change. Nothing was silently dropped, reordered, or corrupted on the way through.
- A failure = any unexplained difference: a missing attribute, a mis-wired association, a changed value. The round-trip catches these before a build, not in production.
That is the whole point: the boundary between "safe" and "needs a human" is measured and visible, not hidden.