Two parallel approaches have emerged for AI-agent-driven editing of Mendix applications:
- PED (Progressive Element Disclosure) — a Studio Pro MCP server exposing JSON-based tools (
ped_read_document,ped_get_schema,ped_update_document,ped_check_errors). Live connection to an open Studio Pro project. Agent-turn-based, schema-on-demand, one-shot error-fix protocol. Optimised for interactive, single-project pair-modelling. - mxcli + MDL — a CLI binary driven by a SQL-like text DSL, recently refactored to support multiple backends: one that manipulates
.mprfiles directly (offline, CI-native), and one that uses the ModelAPI inside Studio Pro (live, interactive). Same DSL, same skills, same composition model across both. Ships with a VS Code extension providing visual and textual editing, multi-root workspaces for multi-app solutions,catalog.db(SQLite) for project metadata, and Starlark-based custom lint rules.
This memo captures a strategic conversation about where mxcli/MDL should invest to avoid duplicating PED and instead own the territory where it has structural advantages.
The dual-backend refactor collapses the "live vs offline" distinction that used to separate PED from mxcli. Both can now edit a running Studio Pro project interactively. What remains — and what is durable — is a different axis:
How does the agent interact with the model?
- PED: MCP tool calls. Each operation is a JSON request/response inside the agent's context window. The LLM is the compute node; tools deliver data into context and emit edits.
- mxcli: CLI invocations over a text DSL. The agent composes scripts, pipes, and shell commands. The LLM is an orchestrator; compute happens in subprocesses outside context.
Every durable strategic difference — text artifacts vs transcripts, CLI composition vs in-context reasoning, CI-native vs session-bound, catalog-query vs document-walk, training-corpus compounding vs runtime-only — flows from this axis. It is not affected by the backend target.
With the dual-backend in place, the set of PED-preferred scenarios shrinks but doesn't disappear. Honest list:
Durable PED advantages:
- MCP-native distribution. Drops into Claude Desktop, Cursor, and similar clients with zero shim. Capability is easy to match; distribution is not.
- Typed, self-describing tool surface. An agent that has never seen PED can still use it. mxcli requires the agent to know MDL (closing as LLMs learn it, but not yet closed).
- Opinionated safety rails as protocol. One-shot fix protocol, radical-operation prohibitions, abstract-type navigation. Safety is steered by the protocol itself, not by convention.
- First-party Studio Pro integration. PED ships inside Studio Pro and gets internal model changes first. mxcli's live backend depends on ModelAPI stability and release cadence.
- Smaller envelope for trivial single-element edits when already inside an MCP client.
Contingent (no longer PED-unique):
- Live immediacy — mxcli-live matches it.
- Visual pair-modelling in the open editor — both can drive it.
Rule of thumb: in an MCP client, for a trivial ad-hoc edit, PED is still the lower-overhead choice until an mxcli-mcp wrapper exists. Those edits are low-value and fine to concede — they are the on-ramp, not the destination.
- No text artifact. No diff, no review, no commit, no replay. The change exists only as a transcript.
- No CLI composition. Every byte of work passes through the agent's context window. No
jq, nowc -l, noparallel, no SQL over a catalog. - Session-bounded. No fleet operations, no CI, no multi-project reasoning.
- Scales poorly with project size. At 100+ modules the context-window ceiling is hit hard regardless of backend.
- One-shot fix protocol is fragile. No pre-apply validation; post-apply repairs have a tight budget.
These are properties of the protocol, not the connection. They persist whether PED is talking to a live project or (hypothetically) an offline one.
The refactor adds strategic reach but also adds real engineering concerns that didn't exist with .mpr-only operation. Surface these honestly — customers at scale will ask.
- Two backends, two failure modes. Live backend has to cope with Studio Pro caches, parallel user edits, ModelAPI lock contention, process restarts. Offline
.mprediting sidesteps these. - Catalog freshness against live edits. If
catalog.dbwas refreshed from the.mprbut the ModelAPI is making changes, the agent's queries can go stale mid-session. Cache invalidation against live state is a new correctness problem. - Semantic consistency across backends. Per-statement atomicity on
.mprmay not match the live-backend's atomicity guarantees. Customers who rely on offline semantics need to not be surprised when running live. - ModelAPI surface coverage. Some operations may work against
.mprbut not ModelAPI, or vice-versa. The "same script, any backend" promise depends on maintaining parity.
Worth naming these explicitly — they are strategic differentiators that neither PED nor previous-mxcli could claim.
- Recordable live editing. Developer uses Studio Pro naturally; mxcli records the MDL equivalent of each change. Session ends with a reviewable, replayable script. Permanently solves "how did this project get into this state?" — and it is impossible in PED (no artifact) and in Model SDK (no live hook).
- Same-script, multi-target execution. Author MDL once; run against
.mprin CI, against live ModelAPI during pair-modelling, against a cached copy for analysis. PED has one target by construction. - Bi-modal sessions. Start live for exploration, switch to offline scripted mode for the bulk change, commit the script. Same tool, same DSL, no context switch.
- Live dry-run.
mxcli checkagainst the live backend previews consistency errors before the user sees them in Studio Pro. - Live lint and test inside Studio Pro. Real-time CI-quality feedback during editing, not batch-after-save.
The VS Code + textual MDL + multi-root workspace + (proposed) multi-document semantic search/replace stack addresses problems that are structurally impossible for a session-bound, single-project agent protocol. Highest-value segments:
- Cross-project refactoring — rename or restructure an entity used across 30 pages, 50 microflows, 4 modules, 3 apps. Visual editing is unusable; PED runs out of context. MDL + semantic search/replace turns hours into minutes.
- Module promotion and monolith splitting — move entities/microflows/pages between modules and apps, bump shared module versions across consumers.
- Migrations and modernisation — K2, Nintex, OutSystems, Oracle Forms, legacy Mendix. One-time, high-value, high-willingness-to-pay work with consulting-partner economics. Skills already exist in the demo1 project.
- Mass model generation — bootstrap apps from OpenAPI/ERD/database-schema inputs. PED's turn-by-turn cost makes 40-entity bootstraps impractical; MDL expresses the same in one script.
- Governance and audit — lint packs as PR/CI gates,
mxcli reportas fleet-wide health dashboard, MDL diffs as auditable change records. PED has no equivalent — it is by nature interactive. - Power-user textual editing — dense microflows, bulk page tweaks, refactoring-heavy sprints. Retains senior developers who feel boxed in by visual-only tooling.
The buyer pattern matters: these are platform / CoE / governance teams at enterprises with 5+ Mendix apps, delivery partners running migrations, and ISVs shipping to many customer instances — not individual developers asking an AI to help with a widget.
mxcli has a structural token advantage that grows with project size, edit breadth, and session length.
Four mechanisms:
- PED navigation and schema cost scales with operation complexity; MDL edits don't. PED uses progressive disclosure — documents are read one level at a time, children returned as stubs until explicitly navigated. Targeted edits of a known path can be efficient. However, any write requires a per-type schema fetch (typically 1–5k tokens per type), and creating or understanding complex structures requires navigating multiple levels across many paths before the first edit is made. An
ALTER PAGE … { INSERT AFTER txtEmail … }is ~30 tokens and requires no schema fetch, no navigation, and no awareness of the surrounding document structure. - Catalog queries replace document walks. Answers over
catalog.dbare 50-token SQL queries returning 200-token tables. The PED equivalent requires loading every candidate document. The gap widens linearly with project size. - Schemas amortise differently. PED fetches schemas per session, per type. MDL's grammar lives in the parser; the agent pays once for a bounded skill-file set (~2–10k tokens) that amortises across edits.
- Error loops are asymmetric.
mxcli check --referencesvalidates before apply; failed attempts cost only script size (~100–500 tokens). PED failures require path re-reads and schema re-fetches to diagnose current state, within a one-shot fix budget.
Back-of-envelope for a realistic refactor (rename Customer.Email → Customer.EmailAddress across 1 entity + 3 microflows + 2 pages + 4 filters):
- PED: ~50–80k tokens of tool I/O (progressive navigation reads + per-type schema fetches + 9 updates + check + potential re-reads for diagnosis).
- MDL: ~1–2k tokens (catalog query + one ~400-token script + check + exec results).
Long-term compounding via LLM pretraining. As MDL is published and used publicly, frontier models will learn the grammar natively — analogous to SQL. Implications:
- Skill files shift from teaching syntax to encoding higher-level patterns (architectural invariants, CRUD conventions, migration recipes, governance rules).
- Same skill-file budget holds 5–10x more patterns; density per token rises.
- Effective attention at any context size improves because less is spent on framework overhead.
Strategic implication: the gap is not just "nicer" — at enterprise scale it becomes a capability gap. There will be problems an MCP-bounded agent runs out of context trying to solve, that a CLI-equipped agent completes cleanly.
Caveat: realising the long-term pretraining advantage requires treating LLM-corpus seeding as an explicit product investment (public repos, community Q&A, reference datasets, open patterns), not assuming it happens automatically. Training lag to frontier models is ~12–24 months.
This is qualitatively different from the token-efficiency point. It reframes the agent architecture.
- MCP model: the LLM is the compute node. Tool results flow into its context. It reasons over the data, emits edits.
- CLI model: the LLM is an orchestrator. Pipes, filters, and subprocesses do the compute. Only judgment-requiring results enter context.
Most questions about a Mendix project don't need judgment — they need filtering, counting, joining, grep. Pushing that to the shell is essentially free.
Concrete capabilities this unlocks:
- Data that never enters context.
mxcli catalog query "… WHERE type='RestCall' AND url LIKE '%legacy%'" | wc -l— the agent reads "47." Via MCP the equivalent scans every microflow. - Intermediate files as durable memory.
mxcli report … --format json > report.json; jq '…' report.json— the agent can re-query later without re-materialising. MCP results are ephemeral. - Composition with the entire Unix ecosystem.
jq,rg,fd,awk,sqlite3,git,gh,curl,xargs,parallel, Python one-liners. Fifty years of network effects for free. MCP servers only compose with other MCP servers a client has been explicitly configured for. - Parallelism for one token of invocation.
parallel mxcli validate ::: apps/*.mpr | grep ERROR. MCP is turn-based. - SQLite as universal interop surface. Any tool, language, or BI system can hit
catalog.db— no custom protocol needed. Quiet moat. - The LLM doesn't need to be the smartest component. A pipeline plus a deterministic lint pass does 80% of the work. Agent decides intent; shell does arithmetic. Cheaper and more reliable.
Honest counterpoints:
- MCP has cleaner safety boundaries (typed args, no bash accidents) — matters for novice users, not for platform teams in their own shells.
- Shell fluency requires capable agents — aligned with the target segment, which already uses frontier-class agents.
- Discoverability requires learning MDL syntax — but
mxcli syntax --jsonprovides a machine-readable feature registry organised by topic (domain-model, microflow, page, security, workflow, …) with drill-down and a built-in LLM caching hint. Skill files distributed viamxcli initbring patterns and examples directly into the agent's context. The discoverability gap is narrowing.
Automated testing is the keystone that upgrades the pitch from "mxcli is the right tool for portfolio-scale Mendix engineering" to "mxcli is the only tool that makes agentic Mendix engineering safe at portfolio scale." Three mechanisms carry this.
Testing reshapes the edit loop. PED's one-shot fix protocol exists because there is no way to verify an edit beyond structural ped_check_errors. With real tests the loop becomes:
agent writes MDL → check (syntax) → exec (apply) → test (behaviour) → iterate
Every stage except "agent writes MDL" runs outside the agent's context. The agent consumes pass/fail + focused error excerpts — not logs, not document re-reads, not re-fetched schemas. This is the TDD-style agentic loop Claude Code and Cursor are built around. mxcli fits it naturally; PED cannot participate because Mendix testing requires CI or a build, neither of which is inside Studio Pro.
Tests unlock operations PED is structurally forbidden from doing. The Maia safety rules prohibit radical operations (rename, delete multiple elements, restructure) without explicit approval — correct, because without a correctness check the blast radius is unbounded. With a deterministic test suite the equation inverts: an agent can attempt a radical refactor and the test suite decides whether it was correct. This means the single biggest class of high-value tasks PED cannot safely attempt — large-scale refactoring, migrations, shared-module evolution — becomes safe in the mxcli workflow because the correctness check is mechanical, not judgment-based.
The cost equation sharpens further. Most mistakes are caught by deterministic test runs (~100 tokens of output) rather than LLM diagnosis (thousands of tokens of re-reading). Failed attempts cost runtime + a summary, not context bloat. For complex refactors, this is often the difference between "completes in three iterations" and "runs out of context."
Portfolio-scale regression is a testing story. parallel mxcli test ::: apps/*.mpr | grep FAIL makes "did the shared-module bump break any of 20 consumer apps?" trivial. This puts mxcli into the critical path of enterprise release processes — a sticky position.
Skill-file implications. As LLMs learn MDL syntax natively, skills shift toward "how to test and what to assert" — where real domain expertise lives (validation patterns, boundary conditions, invariants, regression traps). Syntax content decays; testing content compounds.
Honest counterpoints:
- Mendix's testing ecosystem is historically weak. The UnitTesting module works, but a "my Mendix app has meaningful tests" culture is not widespread. This is a product opportunity but also a gating variable — expect to invest in evangelism and scaffolding, not just tooling.
- Generated tests have the "tests the mock" risk. Coverage metrics will be flattering; semantic value can be low. Invest in property-based and behavioural testing patterns explicitly, not just "a test per microflow."
- PED could in principle drive tests too — but only from inside Studio Pro, which isn't where CI lives. The structural gap persists.
The strategic case above focuses on the execution phase (generating and applying changes). In practice, an agentic editing session has six phases, each with different token and model-tier costs. Treating the workflow as monolithic understates the advantage in the phases that happen most frequently.
| Phase | Description | MDL | MCP (PED) |
|---|---|---|---|
| 1. Understand requirements | Parse user intent | Same (LLM reasoning) | Same |
| 2. Understand project context | Learn existing app structure | Catalog SQL: ~500 tokens/query | Progressive tree navigation + schema fetches: multiple round-trips, cost scales with breadth explored |
| 3. Generate plan | Decide what changes to make | Low — feeds from cheap phase 2 | High — feeds from expensive phase 2 |
| 4. Generate steps | Produce the change operations | MDL script: ~500–5k tokens | Tool calls: 10–100k tokens |
| 5. Verify results | Check correctness | mxcli check: ~200 tokens |
Schema fetch + error response per doc |
| 6. Correct and iterate | Fix errors | Replace specific lines, re-check | Fix partial state, one-shot budget |
Phase 2 is the hidden cost. The catalog's advantage is usually argued for edit operations, but it's equally large at comprehension time. Understanding an existing 50-entity domain model via MCP requires loading 50+ documents into context. mxcli catalog query answers "what entities exist, what are their attributes, what associates them?" in three SQL queries totalling ~2k tokens — constant regardless of project size.
Phase 2 quality determines phase 4 cost. An agent that spent 2k tokens building project context via SQL is more likely to write correct MDL on the first attempt than one that spent 40k tokens walking documents and still has an incomplete picture. The phase 2 advantage compounds forward into generation and correction.
Phases 5 and 6 are asymmetric. mxcli check validates before execution and returns per-statement errors with line numbers. Corrections are surgical. ped_check_errors fires after partial application with a one-shot fix budget — the agent must diagnose what the document's current state is and fix it in a single attempt. Error recovery cost for MCP scales with operation complexity; for MDL it is bounded by script size regardless of complexity.
The preceding sections quantify the token and cost difference. There is a deeper explanation for why the gap is structural — one that connects to a well-understood principle in how LLMs best interact with complex systems.
Multi-layer sequential dependency vs. single-layer token prediction
MCP tool orchestration requires the LLM to maintain coherence across multiple dependent sequential layers for every operation:
- Intent — parse user intent
- Plan — sequence of operations required
- Tool selection — which tool for this step
- Parameter construction — exact parameters, given current state
- State update — track UUIDs, array indices, reference paths after each tool response
- Dependency management — ordering constraints, cross-reference consistency
- Error recovery — diagnose partial failure, replan, repair
- Repeat — each subsequent operation restarts at layer 3 with updated state
Each layer is stochastic, and errors compound upward. A UUID mis-tracked in layer 5 silently corrupts the parameter construction in layer 4 of the next call. The LLM is simulating a stateful interpreter across many sequential, mutually dependent steps — which is not what transformer next-token prediction is trained to do reliably.
MDL generation reduces this to a single coherent inference pass:
Intent → tokens
State is already embedded in the generated text. After writing create entity Customer, the entity name is directly in context — no UUID tracking, no index recomputation, no state extracted from a history of tool responses. The compiler handles all the deterministic layers: reference resolution, UUID assignment, dependency ordering.
The "generate code to compute" analogy
When an LLM is asked to compute the 1000th prime or perform complex arithmetic, the reliable approach is to write Python and execute it — not to iterate the computation inside the context window. LLMs are trained to generate correct code; they are not trained to maintain arithmetic state across sequential steps.
MCP orchestration puts LLMs in "compute it yourself" mode: track UUIDs, recompute array indices, maintain cross-document consistency across 50+ turns. MDL puts LLMs in "generate the script" mode: understand intent, emit declarative statements, let the compiler execute. The same principle applies to both: externalise the deterministic computation to the right tool, keep the LLM in the regime it was trained for.
The pattern appears across the industry
This is not a novel insight. DSL or scripting layers have emerged independently in every domain where LLMs have been applied to complex stateful systems:
- 3D and CAD: Blender generates
bpyPython scripts, not sequences of UI tool calls. Maya uses MEL scripts. AutoCAD uses AutoLISP. - Infrastructure: Terraform HCL and CloudFormation YAML, not sequential cloud API calls. Each resource references IDs from previous ones — the same cross-reference problem MDL externalises to the compiler.
- Data transformation: dbt SQL models, not step-by-step ETL calls. The dependency DAG is declared; the engine resolves execution order.
- General computation: GitHub Copilot, Codex, AlphaCode — all "generate code," not "call tools." The canonical case.
In every domain where pure tool-call orchestration has been pushed hard, a DSL or scripting layer has emerged. Tool calls become the implementation of the compiler — not what the LLM authors. mxcli + MDL is the application of this established pattern to Mendix.
Why this directly explains the model tier and capability gaps
The multi-layer sequential state management of MCP is exactly the task class where smaller models degrade systematically: errors compound across layers, state diverges mid-session, and the model needs Opus-tier capacity just to maintain coherence. Single-pass text generation against a learnable grammar is exactly the task class where 32B local models are competitive with frontier models.
The model tier gap (Section 7), the local model viability (Section 8), and the generation time difference (Section 9) are all downstream consequences of this architectural difference. MDL is not a productivity shortcut over MCP — it is a different computational model: LLM as code generator, compiler as executor.
The preceding analysis focuses on token count. There is a second cost dimension that changes the strategic picture significantly: which model tier is required to execute the task reliably.
MCP tool calling requires Opus for non-trivial tasks. The execution is inherently stateful and multi-turn:
- Index tracking — adding elements to an array shifts subsequent indices. Every mutation changes the ground truth that subsequent operations must reference. Skill docs can remind the model to track this; they cannot do the tracking — that happens in the model's working memory at runtime.
- Dynamic reference resolution —
$id(/entities/3/attributes/1)is valid only until the next mutation reshapes the array. The model must recompute correct paths after every operation. - Dependency ordering — entities before associations, activities before sequenceflows. The rules are stateable in a skill doc; applying them correctly while simultaneously constructing payloads across 20+ turns is a working-memory problem, not a knowledge problem.
- Partial state diagnosis — when
ped_check_errorsfires after 15 operations, the model must reason about which operation caused the problem and what the document's current shape is. This is exactly the multi-step reasoning task where smaller models fail consistently.
MDL generation is viable on Sonnet. It is a declarative, all-at-once text generation task. The executor handles all state management — ID assignment, reference wiring, ordering — regardless of what model produced the script. Errors are reported per statement with a specific message; the fix is replacing one line. No state tracking required.
Skill documents can partially close the gap — but only for knowledge problems. Schema patterns, common type names, ordering rules, error recovery recipes: all of these can be encoded in skill docs and do raise PED's reliability floor for simple operations. What skill docs cannot address is runtime state management. The index arithmetic, path recomputation, and partial state diagnosis that MCP requires at execution time are not knowledge problems — they are execution problems. The ceiling moves with better skill docs; it does not disappear. And it falls precisely at the complex, high-value operations where cost pressure is most acute.
The compound cost multiplier:
cost = tokens × price_per_token(model_tier)
If MCP requires Opus (approximately 4× the per-token price of Sonnet) and uses 10–50× more tokens for the same task:
ratio = (tokens_MCP / tokens_MDL) × (price_Opus / price_Sonnet)
≈ 10–50 × 4
= 40–200×
This is not theoretical: teams report 500M+ tokens/month on Opus-tier models for PED-driven workflows. The MDL approach changes the cost model rather than optimising within it.
Model tier by phase:
| Phase | MDL | MCP (PED) |
|---|---|---|
| Understand project context | Sonnet (SQL → table output) | Opus (document walk, schema inference) |
| Generate plan | Sonnet | Sonnet |
| Generate steps | Sonnet (write MDL script) | Opus (stateful multi-turn, index tracking) |
| Verify | Sonnet (parse check output) | Sonnet |
| Correct | Sonnet (fix specific lines) | Opus (fix partial state, one-shot budget) |
MDL allows the full workflow to run on Sonnet. MCP forces Opus on the two most token-intensive phases — and those are also the phases that occur most frequently in a real session.
MDL's declarative structure opens a capability that is structurally out of reach for MCP: reliable execution by local, on-device models.
Why MDL works for local models:
- The grammar is SQL-like and consistent — coding-specialised local models (Qwen Coder, Gemma) transfer well from pretraining on SQL and similar DSLs
- Output is bounded — most MDL scripts are a few hundred tokens, within the reliable generation window of 32B-class models
- The feedback loop is deterministic —
mxcli checkreturns a line number and specific message; the fix is mechanical - No runtime state management — the executor handles all ID assignment, reference wiring, and ordering regardless of what model produced the script
Why MCP does not work for local models on complex tasks. The index tracking, dynamic reference resolution, and partial state diagnosis that MCP requires are exactly the multi-step dependency tasks where 32B local models fail relative to frontier models. The practical ceiling for local models on MCP is roughly "create one entity with three attributes." A 20-activity microflow via MCP on a local model produces broken references or misordered elements before completion.
What works on 64GB M5 Max (e.g., Qwen Coder 32B at Q6, ~22GB):
| Task | Local model viability |
|---|---|
Catalog SQL queries, show structure |
High |
| Create entity, enumeration, association | High |
| Simple microflows (5–10 activities, linear) | Medium |
| Complex microflows (decisions, loops, 20+ activities) | Low |
| CRUD page layout | Medium |
| Full app generation (domain + microflows + pages) | Low without scaffolding |
mxcli check error correction (per statement) |
High |
Graceful degradation by complexity:
try locally (Qwen Coder 32B, zero API cost)
→ mxcli check clean: commit
→ broken after one fix: escalate to Sonnet
→ still broken: escalate to Opus
The validation gate is deterministic so the escalation decision is mechanical. A failed local attempt costs milliseconds and nothing — not a broken partially-applied project.
Strategic implications:
- Zero cost for routine work. Local inference has no per-token cost. Routine CRUD generation, catalog queries, and check/fix cycles cost nothing in API fees.
- Privacy for enterprise. Project code never leaves the customer's infrastructure. No data in cloud API calls. A meaningful adoption blocker removed for banks, insurers, and government customers — the primary target segment. Every PED tool invocation sends a payload to a cloud API.
- Offline and air-gapped operation. mxcli + local model runs in customer datacentres with no internet access.
- On-device speed. An M5 Max running Qwen Coder 32B generates short MDL scripts in seconds — often lower latency than a round-trip to a cloud API for a simple operation.
The cost floor: MDL on a local model is free. MDL on Sonnet is low cost. MDL on Opus is reserved for genuinely complex tasks. MCP on a local model is unreliable for anything non-trivial. MCP on Opus is the only viable path for complex work — and it is the most expensive option at every level.
The preceding sections focus on token and monetary cost. Time is a third cost dimension — and for the buyer who has waited a full working day for a PED-generated app, it is the most visceral one.
Why PED is slow by construction.
Every MCP tool call is a sequential round-trip with model inference in the loop:
agent decides → sends tool call → Studio Pro responds →
agent receives → agent reasons → agent decides next call → repeat
Each cycle pays: Opus inference latency (large model, slow per-token output) + API network round-trip + Studio Pro processing. These cannot be pipelined — each call depends on the result of the previous one because of index tracking and dependency ordering. A non-trivial app generates hundreds to over a thousand sequential tool calls:
| Component | Approx. tool calls |
|---|---|
| Domain model, 50 entities | ~250 (schema fetch + navigate + create/update + check per group) |
| 20 microflows | ~300 |
| 30 pages | ~600 |
| Error recovery (+20–30%) | ~300 |
| Total | ~1,450 |
At 5–15 seconds per call (Opus latency + network + SP processing), that is 2–6 hours of wall-clock time for tool I/O alone, before accounting for re-reads and correction loops. User reports of full-day generation times are consistent with this structure — they are not outliers.
Why MDL is fast by construction.
The agent generates the MDL script in one inference pass (or a handful of short ones). Execution is then a single local subprocess call:
mxcli check → 1–3 seconds (local validation, no inference)
mxcli exec → 10–30 seconds (local SQLite writes, no inference)
A 50-entity domain model with all attributes and associations executes in the same call as a 5-attribute entity — execution time is disk I/O, not inference latency. For the same complex app:
| Step | Time |
|---|---|
| Script generation (1–2 inference passes) | 2–5 minutes |
| Validation + execution | < 1 minute |
| Total | 5–10 minutes |
The wall-clock ratio is approximately 20–100× faster.
The human experience difference.
A full-day generation changes the interaction model fundamentally:
- The developer is blocked for the duration — no feedback, no steering, no correction mid-flight
- If the output misunderstood a requirement, the entire day is lost before that is discovered
- Cognitively expensive: the developer has to re-engage after a context break measured in hours
MDL at 5–10 minutes enables a qualitatively different working model:
- The developer reviews the script before execution and catches intent errors early — before any project is touched
- A first result arrives fast enough to iterate: 10–20 generation-review-refine cycles fit in a single working day
- Co-creation replaces delegation-and-wait
The developer time cost compounds the API cost.
API token cost is visible on a bill. Developer time cost is invisible but larger. A senior developer waiting a full day for a generation attempt costs €600–1,000 of salary, independent of API fees. At MDL speeds, a generation attempt costs 10 minutes of developer attention. For a platform team running daily generation or modification tasks across a portfolio, this is the line item that makes the business case.
Iteration quality. MDL-generated applications will systematically be better than PED-generated ones — not because the model is smarter, but because the team can afford to iterate, refine, and correct. One PED attempt per day vs. ten MDL iterations per hour is a difference in outcome quality that compounds over a project.
The linting system already embodies the right design principle: Starlark handles quantitative rules (naming conventions, complexity thresholds, structural checks); skill files handle qualitative guidance (architectural judgment, design heuristics). The same split applies to generation — and once applied, it clarifies exactly what belongs in the compiler itself.
The three layers:
| Layer | Handles | Mechanism | Example |
|---|---|---|---|
| Compiler (mxcli) | Correctness — type safety, semantic completeness, dependency resolution | Type system, semantic analysis built into the tool | Catch $Amount + $Customer/Name as a type error |
| Starlark scripts | Quantitative patterns — deterministic implementation of known patterns | User- and community-defined generation scripts | create_crud(module, entity) always produces the same microflows |
| LLM skills | Qualitative judgment — what to build, which pattern fits | Skill files read by the LLM | "Should this be a workflow or a microflow?" |
Moving patterns from skills to Starlark
Skills currently encode two different things. Implementation patterns — how to correctly build CRUD, an approval workflow, a master-detail page — are quantitative: given the same inputs, the correct output is always the same. These should move to Starlark generation scripts, parallel to how quantitative lint rules already live in Starlark.
Judgment — when to use a workflow vs. a microflow, how to structure a domain model for a given use case, which UI pattern suits the requirement — is qualitative. These stay as skills because they require contextual reasoning the LLM provides.
The result: skill files become shorter and higher-value. They encode when and why, not how. The Starlark scripts encode how, deterministically and testably.
The Starlark generation extension system
The same extension mechanism that exists for lint rules applies to generation. Users and organisations define named generation scripts:
# myorg/patterns/crud.star
def create_crud(ctx, module, entity):
ctx.mdl(f"create entity {module}.{entity} ...")
ctx.mdl(f"create microflow {module}.DS_Get_{entity} ...")
ctx.mdl(f"create page {module}.{entity}_Overview ...")
ctx.mdl(f"alter navigation ...")Invoked from MDL:
apply pattern myorg.crud (module: Bookstore, entity: Book);Organisations encode their conventions once. The LLM invokes the script with parameters — a task well within local 7B model capability. The pattern expands deterministically. Mendix could ship an official standard library of patterns; organisations override or extend them with their own conventions.
What genuinely belongs in the compiler
After moving patterns to Starlark, what remains for the compiler is correctness guarantees — things neither Starlark nor skills can provide:
Type system for MDL expressions. MDL expressions have types: $Customer/Name is a String, $Amount > 100 is a Boolean. mxcli currently checks that $Customer/Name refers to an attribute that exists, but not that it is used as the right type. A compiler catches:
set $Total = $Customer/Name + 100; -- String + Integer: type error
call Mod.ACT_Process (Amount: $Customer/Name); -- wrong parameter typeThese are caught today only when Studio Pro opens the file.
Cross-document semantic analysis. mxcli check --references verifies that Mod.ACT_Process exists. It does not verify that the caller passes the correct parameter types. A full semantic pass resolves the call graph and checks types across document boundaries — the guarantee a typed language gives you.
Forward reference and dependency resolution. MDL scripts currently require declaration-order: entity before association, microflow before call site. A compiler builds a dependency graph and resolves order automatically, freeing the LLM and Starlark scripts from having to get this right.
Multi-error reporting. A compiler makes a full pass and reports all errors at once. Faster iteration, especially for generated scripts.
Completeness model. mxcli check warns when a declared feature is architecturally incomplete — entity without access rules, CRUD without navigation. A semantic check that belongs in the compiler, not in a Starlark script.
Impact on strategic metrics
| Metric | Today | + Starlark patterns | + Compiler type system |
|---|---|---|---|
| LLM output for CRUD | ~150–200 lines MDL | apply pattern crud (...) |
Same — errors caught earlier |
| Token cost | Low | Near-zero | Near-zero |
| Model tier needed | Sonnet | Local 7B | Local 7B |
| Correctness | High (skill-dependent) | Deterministic patterns | Deterministic + type-safe |
| Errors caught at | Studio Pro open | mxcli exec | mxcli check |
Mendix customers exist with projects comprising 100+ modules, 1,000+ entities, 1,000+ microflows, and 500+ pages. At this scale the thesis stops being about efficiency and becomes about what is mathematically possible inside a single agent session.
Rough token sizes of a project at that scale:
| Element | JSON tokens (est.) | MDL tokens (est.) | Compression |
|---|---|---|---|
| Entity, 10 attributes | 1–2k | 50–200 | 10–20× |
| Simple microflow (5 activities) | 3–5k | 300–1,000 | ~10× |
| Complex microflow (30 activities) | 15–30k | 1,500–5,000 | ~8× |
| Form page | 5–15k | 500–3,000 | ~5–10× |
| Grid page with complex layout | 20–50k | 2,000–8,000 | ~5–8× |
| Domain model, 50 entities | 50–150k | 10–30k | ~5× |
Full-project corpus at this scale:
- Full JSON: ~5–15M tokens.
- Full MDL: ~500k–1.5M tokens.
- Frontier context windows today: 200k–2M tokens.
Neither representation fits fully in context. The project is physically unobservable as a whole from inside an agent session. The question becomes: how does the agent know what to load without loading everything?
PED has no external index. The only way to learn about a microflow is to read it. At 1,000 microflows, questions like "what writes to Customer.Email?", "are naming conventions consistent across modules?", or "is this refactor safe?" cannot be answered because the answer requires information the session can't hold. This is a capability ceiling — not a cost problem an agent can work through with patience.
mxcli has catalog.db. The project's structure lives on disk. The agent issues SQL queries:
SELECT microflow FROM activities WHERE type='CommitObject' AND entity='Customer';
SELECT caller FROM microflow_calls WHERE callee='Sales.VAL_Customer';Query cost is ~500 tokens in, ~200–2k out, regardless of project size. The agent reasons over answers, not over documents.
Three concrete scenarios at enterprise scale:
- Bootstrapping a 50-entity app from a spec. MDL: one script, ~10–30k output + ~5k skill load, single shell call. PED: 50 × (schema + payload + response) ≈ 35–80k tokens I/O plus domain-model re-reads. Realistic: 50–120k per session, and hits boundaries well before 200 entities.
- One edit in a 1,000-microflow project. MDL: catalog query for conventions (~500 tokens) + MDL (~500) + check/exec (~500) = ~2k total. PED: needs exemplars — 3 reference microflows × ~10k = 30k baseline, plus schemas and the edit = 40–60k for a single microflow addition, because there is no cheap way to learn the project's conventions.
- "Add audit-log fields to all entities in a 1,000-entity portfolio." MDL: agent writes a template + catalog query, produces a ~100k-token script on disk (zero agent context), sees pass/fail summary. Agent footprint ~5–10k total. PED: 1,000 update calls minimum = 500k–1M tokens; impossible in one session; multi-session handoffs compound error rates. Essentially not doable as a single task.
What an enterprise actually feels: a platform team running daily governance sweeps across a 100-module portfolio spends real money on agent tokens — potentially millions per day. The delta is:
- 10–100× on API cost (bounded vs. linear in project size).
- Unbounded on latency — many PED tasks simply do not complete at this scale.
- Quality degradation — attention thins at high context fill even when it technically fits. An mxcli agent has reasoning headroom an equivalent PED agent does not.
The enterprise pitch is not "mxcli is cheaper." It is "mxcli can do things your current setup cannot do at all."
Caveats that need real investment to hold at this scale:
- Catalog coverage must be deep. If
catalog.dbdoesn't index microflow internals (activity types, attribute reads/writes, call edges, XPath constraints), the agent falls back to reading documents and the advantage collapses. Cataloguing is the highest-leverage backend investment. - MDL expressiveness for complex microflows. If MDL for a 30-activity microflow is 20k tokens (close to JSON), the compression argument weakens. Dense, pattern-aware MDL (
FOREACH, sub-flow references, reusable fragments) preserves the ratio. - Template-first generation. At 1,000-entity scale, the agent must generate a generator (template + catalog query), not enumerate statements. This is a skill-file investment — teach the pattern explicitly.
- Validation at volume. 1,000 ALTER statements = 1,000 possible partial-failure points.
CREATE OR REPLACEidempotence, per-statement safety, and rollback semantics matter more as N grows.
- PED will not stand still. Models will get better at JSON/schema traversal; per-op costs narrow. The absolute token gap will shrink. What doesn't narrow are the structural edges (catalog, text artifacts, composition, offline execution, CI gating) — anchor the story there.
- Training lag is real. Publishing docs doesn't automatically seed pretraining. Requires volume: public repos, Stack-Overflow-style Q&A, blog content, open reference corpora. Treat as product investment.
- MDL v1 becomes a permanent commitment once it lands in model weights. Backward-compat discipline is now strategic, not just developer-courtesy. SQL's conservatism is the right model; early-JavaScript churn is the antipattern.
- Name collision risk. "MDL" has other meanings. Make sure the distinctive training signal is the grammar (
CREATE PERSISTENT ENTITY …,.mdlextension, statement shape), not the acronym. - These arguments assume capable agents. Not a broad-consumer story; this is platform-team and power-user territory. The local model path (section 7) is the exception: for routine tasks, even a 32B local model is sufficient.
- Skill docs address knowledge problems, not execution complexity. PED skill documents can raise reliability for simple and moderate MCP operations by encoding schema patterns, ordering rules, and error recovery recipes. They cannot address runtime state management — the index tracking, reference computation, and partial state diagnosis that drive Opus dependency on complex tasks. The ceiling moves with better skill docs; it does not disappear.
- catalog.db coverage must be invested in for the query-as-composition argument to hold. Shallow metadata limits the reach.
- Mendix testing maturity is a gating variable. The testing advantage only lands for customers who invest in test suites. Meeting customers where they are — scaffolding, generators, patterns — is part of the product, not just a documentation problem.
- Generation time estimates are architectural, not measured. The 5–15 seconds per MCP tool call and the 20–100× wall-clock ratio are derived from observed Opus latency and tool call counts, not from a controlled benchmark. The MCP BSON benchmark proposal (
docs/11-proposals/PROPOSAL_mcp_bson_benchmark.md) is designed to produce measured data. Until then, treat the time claims as directionally correct and order-of-magnitude reliable, not as cited figures.
- Bidirectional
.mpr↔ MDL —mxcli diff,mxcli merge,mxcli apply. Every downstream capability (reviewable history, portable migrations, semantic merge, replay across fleet) compounds off this. - Semantic multi-document search/replace — reference-aware and type-aware, not text-grep. The wedge for cross-project refactoring.
mxcli queryas first-class SQL surface overcatalog.db— machine-queryable, composable withjq/awk/Pandas/BI. Extend catalog coverage aggressively.- Stable pipe-friendly I/O —
--format json|csv|tsveverywhere, no decoration on stdout, structured stderr, meaningful exit codes. - Machine-readable
--help— agent-planning-friendly JSON description of commands and flags. - LLM-corpus seeding programme — public GitHub corpus, partner blog content, open reference migrations, explicit "Rosetta" datasets (intent → MDL) suitable for pretraining ingestion.
- MDL backward-compat governance — keyword-adding discipline, deprecation policy, versioning story, published conformance tests.
- Starlark lint ecosystem — shareable rule packs (
@security/owasp,@governance/gdpr, per-customer packs), registry, CI integrations. Network-effect moat. - Fleet operations as a first-class product —
mxcli fleet apply, cross-project impact analysis, portfolio-level reports. - Pipeline recipes published as skills — reframe agent behaviour from "load and reason" to "compose and decide."
mxcli testas a first-class command with structured output modes (JUnit XML, TAP, JSON). Wrap the existing Mendix UnitTesting module + UI-test runners; don't reinvent. This is what turns the CI loop from "check and apply" into "check, apply, verify" and unlocks safe radical operations.- Test generation paired with model generation. When mxcli generates 40 CRUD microflows from a schema, generate their tests in the same pass. Closes the trust gap on mass generation.
- Test-informed safety policy. Codify that radical operations are permitted when pre- and post-tests both pass. Make it a customer-facing promise, not an internal agent convention.
- Fleet test runner.
mxcli fleet test --projects apps/*.mpr --since <sha>. Cross-project regression becomes a product, not a feature. - CI templates (GitHub Actions / GitLab / Azure DevOps) wiring check → exec → test → lint → report. Lowers adoption cost to near zero for platform teams.
mxcli-mcpwrapper. Exposemxcli check,mxcli exec,mxcli query,mxcli testas MCP tools so mxcli drops into Claude Desktop / Cursor / Claude Code without shim. Neutralises PED's strongest remaining claim (MCP-native distribution) and is technically trivial.- Recordable live editing as a headline feature. The dual-backend enables live edits that also produce reviewable MDL scripts. Name it, brand it, demo it — nobody else has this. Turns every Studio Pro session into a git-reviewable change set.
- Live-backend catalog freshness. Event-driven refresh (or a ModelAPI-backed live catalog) so queries don't go stale mid-session. This is the hardest technical investment but it's load-bearing for the composition story when the backend is live.
- Backend-semantics documentation. Explicitly document atomicity, error handling, lock behaviour, rollback across
.mprand live backends. Avoid customers discovering semantic differences by incident. - Local model compatibility testing. Benchmark MDL generation on Qwen Coder / Gemma tiers against the doctype-test corpus. Publish the task complexity threshold where local models are reliable. Establishes the cost floor and the on-premises privacy story for enterprise customers.
- Workflow phase benchmarking. Measure token and model-tier cost across all six agentic phases (comprehension → planning → generation → verification → correction) for MDL vs. MCP on representative tasks. Converts the analytical efficiency argument into cited data points.
- Starlark generation scripts. Extend the existing Starlark lint system to the write path: generation scripts that produce MDL instead of findings. Same engine, same extension mechanism, same community sharing model. Quantitative implementation patterns (CRUD, approval workflows, master-detail pages) move from skill files (LLM-applied, probabilistic) to Starlark scripts (deterministic, testable). Ship a standard library of common patterns that organisations adopt or override with their own conventions.
- Type system for MDL expressions. Add type inference and type checking to
mxcli check: catch parameter type mismatches, wrong-type attribute references, and cross-document call-graph type errors before Studio Pro opens the file. The most impactful genuine compiler addition — moves a class of errors from runtime discovery to check-time. - Completeness model. Extend
mxcli checkto warn on architecturally incomplete features: entity without access rules, CRUD without navigation, microflow with unreachable paths. Shifts the tool's guarantee from "syntactically and referentially valid" to "architecturally complete." - Forward reference resolution. Allow MDL scripts to declare elements in any order; the executor resolves the dependency graph automatically. Removes ordering constraints from LLM- and Starlark-generated scripts.
- Duplicating PED's single-project interactive lane.
- Beginner/onboarding guidance.
- Rebuilding general Mendix knowledge the agent can get from any source.
- Feature parity for its own sake — test every feature proposal against "Does this get better as the customer's app count goes from 1 to 20?" If no, it's in PED's lane.
An eleven-slide deck with a core six-slide arc (Slides 1–6) and five deep-dive slides (Slides 7–11) for technical audiences. Slide 1 sets the axis — the dual-backend refactor means "live vs offline" is no longer what separates the tools. Slide 2 frames the territory. Slide 3 makes the efficiency case. Slide 4 is the architectural moat. Slide 5 is the safety upgrade. Slide 6 is the enterprise closer. Slides 7–11 cover: why DSL generation is the industry-validated pattern for agentic work, the compound cost multiplier, local model viability, generation time, and the three-layer compiler/Starlark/skills architecture.
Thesis: the dual-backend refactor collapses "live vs offline." Both PED and mxcli can now edit a running Studio Pro project interactively. What remains — and what is durable — is how the agent interacts with the model.
The two protocols:
- PED: MCP tool calls. Each op is a JSON request/response inside the agent's context. The LLM is the compute node.
- mxcli: CLI over a text DSL. The agent composes scripts and pipes. Compute happens in subprocesses outside context. The LLM is an orchestrator.
Everything durable follows from this axis:
- Text artifacts vs. transcripts.
- CLI composition vs. in-context reasoning.
- CI-native vs. session-bound.
- Catalog queries vs. document walks.
- Training-corpus compounding vs. runtime-only.
Consequence: mxcli now matches PED on every connection target and retains every composition, artifact, and scale advantage. The strategic position is strictly stronger after the refactor, not merely equivalent.
New capability neither tool had before the refactor: recordable live editing — Studio Pro edits that also produce a reviewable MDL script. Unique to mxcli; impossible in PED.
Honest concession: in an MCP client, for trivial ad-hoc single-element edits, PED is still lower-overhead until an mxcli-mcp wrapper exists. Concede the on-ramp; own everything beyond it.
Thesis: PED is for a developer with one open project. mxcli/MDL is for a team with a portfolio. Don't duplicate; diverge.
PED's lane (concede):
- Single-project, interactive pair-modelling in an MCP client.
- Beginner onboarding and immediate visual feedback.
- Ad-hoc widget or microflow edits in the open editor.
mxcli/MDL's territory (own it):
- Cross-project refactoring — rename/restructure across 30+ documents in multiple apps.
- Migrations — legacy modernisation, version bumps, mass model generation.
- Governance — lint-as-CI, MDL diffs as audit artifacts, fleet-wide reports.
- Power-user textual editing in VS Code, including multi-root multi-app workspaces.
Buyer profile: platform / CoE teams, delivery partners, ISVs — not individual developers.
Decision test for every feature: Does it get better as the customer's app count goes from 1 to 20?
Thesis: mxcli's token advantage isn't a convenience — at enterprise scale it's the difference between problems an agent can solve and problems it can't.
Four mechanisms compound:
- Document reads scale with project size; MDL
ALTERstatements don't. - Catalog (SQLite) queries replace document walks.
- MDL grammar amortises into LLM weights as the corpus grows publicly.
check --referencesfails fast, before apply — failures cost script size, not re-reads.
Back-of-envelope for a cross-doc rename (9 affected files):
- PED: ~50–80k tokens of tool I/O.
- MDL: ~1–2k tokens.
Long-term: as MDL lands in LLM pretraining, skill files shift from teaching syntax to encoding patterns, lifting density per token 5–10x and freeing reasoning headroom for hard problems.
Caveat: realising the pretraining advantage requires active corpus seeding (public repos, blogs, Q&A, reference datasets) and MDL backward-compat discipline — both are product investments.
Thesis: MCP forces every byte through the LLM's context. CLI pipes move work out of the context entirely. This is a structural architecture difference, not a feature difference.
The reframe:
- MCP: the LLM is the compute node.
- CLI: the LLM is an orchestrator; pipes, filters, and subprocesses do the compute.
What this unlocks:
- Data that never enters context (
… | wc -l,… | jq,… | grep). - Intermediate files as durable session memory.
- Composition with the entire Unix ecosystem —
jq,rg,sqlite3,git,parallel, Python. Fifty years of network effects, free. - Real parallelism (
parallel mxcli validate ::: apps/*.mpr). catalog.dbas SQLite = universal interop surface for future tools, dashboards, BI.
Strategic positioning: this makes mxcli not "a CLI for Mendix" but Mendix's place in the Unix ecosystem — a much bigger and more defensible position than anything MCP-bounded can become.
Required investments to realise it: stable pipe-friendly output modes, mxcli query as first-class SQL surface, aggressive catalog coverage. (mxcli syntax --json already provides machine-readable command discovery.)
Thesis: without tests, an agent editing a portfolio is a liability. With tests, the same agent is a force multiplier. mxcli's CI-native loop is the only place this can land — PED is session-bound and can't participate in CI.
The edit loop changes shape:
agent writes MDL → check → exec → test → iterate
Every stage except "agent writes MDL" runs outside the agent's context. Pass/fail + focused errors are what enter context — not logs, not re-reads.
What tests unlock that PED structurally cannot:
- Radical operations become safe — rename, restructure, monolith-splitting, shared-module evolution. The correctness check is mechanical, not judgment-based.
- Portfolio regression becomes trivial —
parallel mxcli test ::: apps/*.mpr | grep FAIL. - Mass-generation trust — generated tests paired with generated microflows close the "did the agent get this right?" gap.
Cost implications reinforce Slide 2: most mistakes caught by a ~100-token test result rather than thousands of tokens of LLM diagnosis. Difference between "completes in three iterations" and "runs out of context" on complex refactors.
Positioning upgrade: from "mxcli is the right tool for portfolio-scale Mendix engineering" to "mxcli is the only tool that makes agentic Mendix engineering safe at portfolio scale." That is categorically stronger and architecturally out of PED's reach.
Caveat + opportunity: Mendix testing culture is historically thin. The scaffolding, generators, and patterns to change that are a product investment — and also a differentiated one, because nobody else is solving it.
Thesis: at 100+ modules / 1,000+ entities / 1,000+ microflows, the conversation stops being about efficiency. PED hits a mathematical wall — some questions cannot be answered from inside an agent session at all. mxcli's catalog + CLI composition are the only way through.
The scale reality:
- Full project in JSON: ~5–15M tokens. Full project in MDL: ~500k–1.5M. Frontier context windows: 200k–2M. Neither fits. The project is unobservable as a whole.
- PED has no external index — the only way to learn about a microflow is to read it. At 1,000 microflows, this is structural blindness to the whole.
- mxcli has
catalog.db. Agents issue SQL queries; cost is constant regardless of project size. The project lives on disk; the agent reasons over answers.
Three scenarios that clarify the gap:
- Bootstrap 50 entities: MDL ~15–35k tokens. PED: 50–120k per session, hits boundaries before ~200 entities.
- One edit in a 1,000-microflow app: MDL ~2k tokens (catalog query locates conventions). PED: 40–60k, because exemplars must be read to learn what "idiomatic" looks like.
- Audit-log pattern across 1,000 entities: MDL ~5–10k agent tokens (template + catalog → 100k script on disk → summary). PED: 500k–1M tokens minimum; not doable in one session.
What the enterprise feels:
- 10–100× on API cost — bounded vs. linear in project size.
- Unbounded latency — many PED tasks simply don't complete at this scale.
- Quality degradation even when context technically fits — attention thins at high fill.
The pitch that closes the deal: "mxcli can do things your current setup cannot do at all." Not cheaper — possible.
What must hold for this to land:
- Deep
catalog.dbcoverage (activity types, attribute reads/writes, call edges, XPath). - MDL expressiveness that preserves compression for complex microflows.
- Template-first generation patterns taught as first-class skills.
- Idempotent, partial-failure-safe execution for volume operations.
Target buyer for this slide: platform engineering lead at a bank, insurer, telco, or large government — the person whose nightmare is "how do I maintain consistency across 40 apps built by 80 developers over 6 years." This is the slide they remember.
Thesis: The MDL approach is not a Mendix-specific optimisation. It is the standard solution to a fundamental limitation of multi-step tool orchestration — arrived at independently in every domain where LLMs drive complex stateful systems.
Why tool orchestration is architecturally hard for LLMs:
MCP requires the LLM to maintain coherence across 7+ dependent sequential layers per operation: intent → plan → tool selection → parameter construction → state tracking → dependency management → error recovery → repeat. Each layer is stochastic; errors compound upward. The LLM simulates a stateful interpreter — which is not what transformer next-token prediction is trained to do reliably.
Why DSL generation is in the LLM's natural regime:
MDL is a single coherent inference pass: intent → tokens. State is embedded in the generated text. The compiler handles what the LLM is bad at — UUID assignment, reference resolution, ordering. The LLM does what it is trained for: generating correct text against a known grammar.
The "generate code to compute" analogy:
LLMs don't compute the 1000th prime by iterating in context — they write Python. The same principle applies: generate MDL and execute it, rather than simulate the execution step by step.
Market validation:
| Domain | DSL layer | Replaced |
|---|---|---|
| 3D / CAD | bpy Python, MEL, AutoLISP |
Sequential UI tool calls |
| Infrastructure | Terraform HCL, CloudFormation | Sequential cloud API calls |
| Data transformation | dbt SQL models | Step-by-step ETL calls |
| General computation | Copilot / Codex / AlphaCode | In-weight computation |
The conclusion: In every domain where tool-call orchestration has been pushed hard, a DSL layer has emerged. Tool calls become the compiler's implementation — not what the LLM authors. The model tier gap, the local model viability, and the generation time difference in the following slides are all downstream consequences of this one architectural difference.
Slide message: "The right answer for 'LLM drives a complex stateful system' is always a DSL layer. The industry validated this pattern before we needed it for Mendix."
Thesis: the token efficiency argument understates the real cost difference. MCP forces Opus; MDL runs on Sonnet. Multiply the token ratio by the model price ratio and the cost difference is 40–200×, not 10–50×.
Six phases, two cost drivers:
Every agentic session has six phases: understand requirements → understand project context → plan → generate steps → verify → correct. MDL runs all six on Sonnet. MCP forces Opus on the two most token-intensive phases — project comprehension (document walks instead of catalog SQL) and step generation (stateful multi-turn tool calling instead of declarative script authoring).
Why skill documents don't close the gap:
Better PED skill docs raise the reliability floor for simple operations by encoding schema patterns and ordering rules. They do not address runtime state management — the index tracking, path recomputation, and partial state diagnosis that are intrinsic to multi-turn tool calling. The ceiling moves; it does not disappear. It falls precisely at complex, high-value operations.
The arithmetic:
- MCP: N tokens at Opus price
- MDL: N/10–N/50 tokens at Sonnet price (~4× cheaper per token)
- Combined ratio: 40–200×
User data: 500M+ tokens/month at Opus prices reported for PED-heavy workflows. This is the line item that makes the conversation happen.
Slide message: "It's not just fewer tokens. It's cheaper tokens. And the gap compounds across every phase of the workflow."
Thesis: MDL's declarative structure enables effective use of local, on-device models for routine work. MCP cannot. This creates a three-tier cost structure with a zero-cost floor — and removes the cloud-data constraint that blocks enterprise adoption.
Why MDL works for local models:
MDL is a text generation task with a learnable SQL-like grammar and deterministic feedback. A 32B coding model (Qwen Coder, Gemma) running on a MacBook Pro M5 Max with 64GB RAM can generate correct MDL for routine operations — create entity, simple microflow, CRUD page. The executor handles all state management; the model writes declaratively. mxcli check gives per-line error messages; fixes are mechanical.
Why MCP does not work for local models on non-trivial tasks:
Index tracking, dynamic reference resolution, and partial state diagnosis under a one-shot fix budget are exactly the multi-step dependency tasks where 32B models fail reliably. The practical local model ceiling for MCP is "create one entity with three attributes."
The three-tier cost structure:
| Tier | Model | Cost | Suitable for |
|---|---|---|---|
| Local | Qwen Coder 32B | $0 | Routine CRUD, catalog queries, check/fix |
| Cloud mid | Sonnet | Low | Moderate microflows, multi-doc operations |
| Cloud top | Opus | Higher | Complex generation, large-scale refactoring |
Graceful degradation: mxcli check after a local attempt is the gate. Failure is cheap and immediate; escalation is mechanical. No partial state to recover from.
The enterprise story beyond cost:
- Project data never leaves the customer's infrastructure — no cloud API calls
- Offline and air-gapped operation in secure datacentres
- Removes a meaningful compliance blocker for financial services and government
Slide message: "Local models for free. Sonnet for most. Opus only when you need it. And your project data stays on your hardware."
Thesis: time is the cost dimension the API bill doesn't show. For the buyer who has waited a full working day for a PED-generated app, it is the most memorable argument in this deck.
Why PED is slow by construction:
Every MCP tool call is a sequential round-trip with Opus inference in the loop. A non-trivial app (50 entities, 20 microflows, 30 pages) generates ~1,200–1,500 sequential tool calls. At 5–15 seconds per call, that is 2–6 hours of tool I/O alone — before error recovery loops. Full-day generation times are not outliers; they are the expected outcome of the architecture.
Why MDL is fast by construction:
Script generation is one inference pass (2–5 minutes). Execution is a single local subprocess call: mxcli exec runs in 10–30 seconds regardless of app size — execution time is disk I/O, not inference latency.
PED complex app: 2–8 hours (sequential tool calls + Opus latency)
MDL complex app: 5–10 minutes (one inference pass + local exec)
Ratio: 20–100×
The interaction model shift:
PED forces delegation-and-wait: the developer hands off, waits hours, then discovers whether requirements were understood correctly. MDL enables co-creation: the developer reviews the script before execution, sees a result in minutes, and runs 10–20 refinement cycles in a single working day.
The hidden cost — developer time:
API fees appear on the bill. Developer time does not. A senior developer blocked for a full day costs €600–1,000 of salary per generation attempt, independent of what Anthropic charges. At MDL speeds, the same attempt costs 10 minutes of developer attention.
The quality consequence:
MDL-generated applications will be better — not because the model is more capable, but because the team can afford to iterate. One PED attempt per day vs. ten MDL cycles per hour is a compounding quality advantage across a project.
Slide message: "One shot per day, or twenty iterations per hour. The answer determines whether your team ships or waits."
Thesis: the linting system already shows the right design. Quantitative rules go in Starlark; qualitative judgment stays in skills. Apply the same split to generation — and the result is a three-layer architecture where each layer does exactly what it is good at.
The three layers:
| Layer | Quantitative or qualitative? | Mechanism |
|---|---|---|
| Compiler | Correctness guarantees | Type system, semantic analysis, dependency resolution |
| Starlark scripts | Quantitative patterns | Deterministic generation scripts, user- and community-defined |
| LLM skills | Qualitative judgment | Skill files — when, why, and which pattern |
What moves from skills to Starlark:
Implementation patterns — CRUD, approval workflows, master-detail pages — are quantitative: given the same inputs, the correct output is always the same. They currently live in skill files, applied probabilistically by the LLM. Moving them to Starlark generation scripts makes them deterministic, testable, shareable, and invokable by a local 7B model.
What stays in skills:
Judgment — when to use a workflow vs. a microflow, how to structure a domain model for a given use case. Inherently qualitative. Requires contextual reasoning. Always LLM territory.
What the compiler gains:
Type checking for expressions, cross-document parameter type validation, forward reference resolution, and a completeness model. These are correctness guarantees neither Starlark nor skills can provide — they require systematic analysis of the full program.
The compounding effect:
| Today | + Starlark patterns | + Compiler type system | |
|---|---|---|---|
| Token cost | Low | Near-zero | Near-zero |
| Model tier | Sonnet | Local 7B | Local 7B |
| Errors caught at | Studio Pro | mxcli exec | mxcli check |
| Correctness | Skill-dependent | Deterministic | Type-safe + complete |
The network effect: organisations publish their Starlark pattern libraries. Mendix ships a standard library. The community of patterns grows independently of the mxcli release cycle. mxcli becomes the runtime for an ecosystem — not the owner of every pattern.
Slide message: "Quantitative patterns move to Starlark. Qualitative judgment stays in skills. The compiler guarantees correctness for both. The same design that works for linting works for generation."