Ask any developer today whether they still need to model a system before building it, and you might get a laugh. Why draw process diagrams and define entity relationships when you can describe what you want in plain English and have an AI generate working code in seconds? The question is fair. But it misses something important. LLMs are remarkable at generating code. They are not remarkable at being consistent.

Abstraction always wins — but not all abstraction is equal

Grady Booch observed that the history of software engineering is a history of rising abstraction. Machine code gave way to assembly. Assembly gave way to programming languages. Programming languages gave way to frameworks and platforms. Each step let developers describe what rather than how, and productivity followed.

Model-driven development (MDD) is a further step on that same path: describe the system through a formal domain model, and generate the application from it. The model becomes the source of truth — not the code.

LLMs look like another step in the same direction. Describe what you want in natural language; receive code. But there is a crucial difference: MDD generates code deterministically from an explicit model. An LLM generates code probabilistically from a prompt. Same model, same output. Same prompt, potentially different output every time.

For many applications, this distinction does not matter much. For a significant class of systems, it is the whole game.

You cannot escape the schema

Here is what does not change regardless of which path you take: you still have to design the data model. Whether you build with MDD or with an LLM, someone has to decide what a Customer is, what a Transaction contains, how an Account relates to a Ledger. Every system of record is, at its core, a schema with behavior attached.

In MDD, the schema is the explicit, formal starting point — everything generates from it. In an LLM-built system, the schema still exists, but it often emerges from prompts, gets embedded across migrations, and drifts as features accumulate across sessions. The model is still there; it is just invisible.

Choosing LLMs over MDD does not remove the need to model. It removes the discipline that makes modeling useful.

Determinism means certainty

With MDD, the implementation does not vary. Same model, same output. If the result changes over time, it is because the generator was deliberately updated — a security patch, a framework upgrade — not because a prompt landed differently. You reason about correctness once and trust it everywhere.

A practical consequence follows directly: generated code does not need to be tested. It is correct by construction. Testing concentrates entirely on the 20% of logic written by hand — the domain-specific calculations, the integrations, the edge cases unique to the business. On large systems, this is not a small saving.

Scale is where it gets interesting

LLMs can deliver most enterprise application features — multilingual support, audit trails, transactional integrity, consistent architecture — if you instruct them properly. For smaller applications, that works well.

The challenge is what happens as the application grows. Every cross-cutting concern you want consistently applied — how date pickers render, how links are styled, how list selections behave, how audit annotations appear, how transaction boundaries are drawn — needs to be in the prompt. Each consistency requirement adds instructions. The instruction set grows with the application. Eventually the context fills not with logic but with coherence rules, and the LLM spends its capacity remembering a style guide rather than building features.

MDD has none of this overhead. A calendar picker is defined once in the generation platform and applied to every date field in the application — automatically, identically, without instruction. Audit is a model property, not a prompt property. Architecture patterns are in the generator. Ten tables or a thousand tables: the generation cost is the same, and the result is coherent.

This is the real advantage of MDD at scale. Not that LLMs cannot produce these things — they can — but that the cost of keeping them consistent does not grow with the application.

Where MDD fits best

The systems that benefit most are those where consistency, longevity, and correctness are non-negotiable:

• Core banking and financial ledgers
• Insurance policy administration
• Government benefits and social services
• Healthcare record systems
• Telecommunications billing
• ERP and inventory management

Large, long-lived applications where the schema is central, the cost of inconsistency is high, and the value of deterministic generation compounds with every new module added.

LLMs and MDD together

Don't get us wrong. We're not here to praise MDD supremacy. We love spec driven development. We love creating apps with LLMs. But as we've seen the both sides, the more interesting question is not which to choose, but how to use both in system development. LLMs are excellent at building models — proposing entity structures from domain descriptions, translating stakeholder requirements into model elements, drafting the custom logic that sits outside the generated core. MDD provides the structural foundation: the 80% of the application that follows from the domain, generated consistently regardless of how large the system grows.

They are not competing abstractions. They are complementary ones. LLMs bring speed to the parts of the system where creativity matters. MDD brings certainty to the parts where variance is a defect.

Rising abstraction always wins. The question is always: what do you choose to abstract?

---

Janne Hansen, 8.5.2026
LeBLANC Finland Oy

Related

• Model Driven Government
• Describe to build
• Software production lines V2