A promise that arrived twenty years early
When the Object Management Group launched Model-Driven Architecture in 2001, the pitch was seductive. Describe your system once, at a high level of abstraction and let automated transformations carry that description down to running code on whatever platform you cared to target. The model, not the code, would be the primary artefact. Code would become a generated by-product, the way object files are a by-product of a compiler. Business meaning at the top, machinery at the bottom and an automated bridge between them.
The structure was clean, and the model-driven development standard I keep for my own work still captures it well: a Computation Independent Model for the domain, a Platform Independent Model for structure and behaviour, a Platform Specific Model for the implementation detail and transformations carrying you down the stack. The headline benefit was portability. One PIM, many PSMs, re-targetable as platforms changed.
It mostly did not become the default way software gets built. The reasons are worth stating plainly, because they explain why the idea deserves a second look now.
Why it stalled
The Standard/Classic vs Modern MDD page is blunt about classic MDA’s weaknesses and rightly so: weight and friction. Heavy UML CASE tooling. A steep learning curve. Round-tripping that rarely worked cleanly. The difficulty of bending general-purpose UML to a specialised domain. And, underneath all of it, a reputation for promising more automation than most teams could deliver.
Two of those failures matter most for what comes next. The first is the transformation barrier. Writing the rules that turned models into useful code, in languages like QVT or ATL, was itself specialist work. The abstraction that was meant to free you from low-level effort just relocated it. Teams stopped writing Java and started writing the thing that wrote the Java and the second job was not obviously easier than the first.
The second is round-trip drift. Generate code from a model, let a developer edit that code by hand and you have two sources of truth pulling apart. The principle “generate, don’t hand-edit below the line” exists precisely because, in practice, people edited the code, the model rotted and within a release or two the diagram no longer described the running system.
So MDD survived where it could absorb these costs: long-lived enterprise systems, regulated domains, stable problem areas with recurring shapes, projects targeting several platforms from one model. Low-code platforms like Mendix and OutSystems are arguably its most commercially successful descendants and they succeeded by hiding the models and the language, from the people who did not want to see them. Everywhere else, code stayed king.
What changed and the distinction that matters
The thing that broke classic MDD was the cost and rigidity of the bridge from a high-level model to working software. That is exactly what large language models are good at.
Before going further, one distinction worth holding on to. MDD and spec-driven development are not the same thing. MDD makes a formal model, conforming to a metamodel, the contract and lets a transformation engine generate the code. SDD makes a structured specification the contract and lets humans or agents write the code. The current wave of tools, GitHub’s Spec Kit and AWS’s Kiro among them, are mostly SDD: Kiro turns a prompt into requirements in EARS notation, a design and a task list, then writes code against them; Spec Kit’s slogan is that specifications stop serving code and code starts serving specifications. These are the cousins of MDD, not MDD itself. They are worth watching, but the question here is narrower and more interesting: does AI make the model-driven approach, with its formal model and metamodel, more workable? I think it does, in four specific ways.
First, it collapses the transformation barrier. The reason transformations had to be hand-built in QVT was that a deterministic tool needed a fully formal input. An LLM does not. It will read a PIM, a DSL program, or a half-formal domain description and produce platform code directly. The interpreter that MDD spent two decades trying to construct by hand now exists as a general-purpose component you can call. Modern practice already collapses the strict CIM to PIM to PSM ladder into a model-to-code step in one move and AI is what makes that step cheap. Whether you actually want an LLM running that step, rather than just helping you build it, is a separate question that the stakes decide, one I return to below.
Second, it lowers the cost of the right language. My own standard argues that a focused DSL usually beats stretching UML and the catch was always that you had to build and maintain the language yourself. LLMs make drafting a grammar, a metamodel and a generator far less daunting, which tilts the build-versus-reuse maths towards purpose-built languages that read naturally to domain experts.
Third, it gives you a drafter for the models themselves. The AI section of Standard/Classic vs Modern MDD already names this: generating draft domain models from natural language, producing instance models that conform to an Ecore metamodel, recommending completions. The human still owns the model and the metamodel; the LLM drafts and suggests and its output is checked against the metamodel before it is trusted.
Fourth, executable models plus AI shorten the feedback loop. You can run or simulate behaviour at the model level, with an LLM filling gaps and validate intent before committing to a platform at all.
The middle ground and who stands on each side
Here is the part I find most compelling. Model-driven development can now be a workable middle ground between business and code, with the division of labour finally falling where it belongs. Humans own the first part. The second part is generated rather than hand-written. I have phrased it before as “human decides, AI executes” and I still think that is the right shape, with one refinement I come to shortly: which machine executes the second part matters enormously and it is not always an LLM.
The first part is deciding what the system should do and why: the CIM and much of the PIM, the domain, the rules, the constraints, the trade-offs and crucially the metamodel that defines what a valid model even is. This is the work that needs knowing the business, talking to the people the software serves and making judgement calls that have no correct answer, only better and worse ones. It does not generate cleanly from anything. It is the genuine scarce resource.
The second part is turning a sufficiently precise model into correct, idiomatic code on a given platform: the descent that ate most of a developer’s day and most of MDD’s tooling budget. It is mechanical in the way that matters. Given a clear model and a metamodel to conform to, the space of good answers is constrained and producing one is something a generator does mechanically, whether that generator is an LLM or a deterministic transformation. Which of the two you choose is not a detail. It is what the next section is about.
For most of software’s history these two parts were welded together, because the only way to specify intent precisely enough to execute it was to write the code. Code was the specification, which is why business and engineering have always needed a lossy translation layer between them. What AI offers is a credible separation. The human works in a model a domain expert can read and argue about. The machine carries it to the running system. The model in the middle stops being a document that rots in a wiki and becomes the thing you genuinely edit to change the software, which is the Standard’s “models are living documents” principle made practical rather than aspirational.
That reframing softens the two worst failures. Round-trip drift hurts less when the model is the artefact you maintain and the code is regenerated rather than patched, because there is one source of truth by design. And the transformation barrier falls away, because the formal transformation language is replaced by natural language plus a metamodel a non-specialist can learn quickly.
The asymmetry of trust: where AI belongs and where it must not
So far I have written as though AI’s job is to carry the model down to code. That is the right instinct for low-stakes work and the wrong one for the cases that matter most. The sharper claim, and the one I now think is the real point, is that the two translations in model-driven development have opposite needs and want opposite tools.
The upper translation, from a human need to a formal model, is sense-making. You rarely know exactly what you want until you have talked it through, and this is where an LLM earns its place. Not as a generator you trust blindly but as a collaborator that explains options, surfaces the implication you missed, proposes a structure for the domain and argues back when an idea does not hold together. Here non-determinism is not a defect. Nothing the model produces is trusted directly. A human reads it, pushes on it and signs off on a model. Two runs that give two different explanations are fine, even useful, because the work is exploration and the output is shared understanding plus a reviewed artefact. This is the part classic MDA did badly. The route into a good model was heavy, formal and unfriendly. AI is exactly what makes it humane.
The lower translation, from that model to running code across one or more stacks, is the opposite kind of work. It is execution, and in a bank, a government system or a hospital it is where liability lives. Here you want the property an LLM cannot give you. The same model must produce the same code, every stack, every time, so an auditor can trace any line of running software back to a decision in the model and so that nothing reaches the delivered system that was not in your stated intent. A deterministic generator gives you that. A probabilistic one does not. The risk is not hypothetical: recent academic work on LLMs in model-driven engineering found they tend to produce abstract, implicit constraints that are not fit for forward engineering without manual refinement. So in regulated domains you keep the LLM out of the runtime path. You want clarity and trust at the point where risk is realised, not fluency.
Splitting the layers this way resolves the trust problem rather than ducking it. Quiet, non-reproducible failure only bites if you let the LLM write the production code. Put the determinism where the risk is, keep the LLM where exploration pays and the worry mostly dissolves. It also rehabilitates the half of classic MDA that I called a cost. The deterministic, portable transformation from one model to many platform targets is not dead weight. In a regulated setting it is the asset, because it is auditable and reproducible. AI did not make it obsolete. AI fixed classic MDA’s other failure, the brutal top of the funnel, and left the trustworthy bottom intact.
One caveat keeps the cost honest. You can still use an LLM to draft, refactor and maintain that deterministic generator. You just do not let it run the transformation. The LLM touches the generator at authoring time, under review and test, never at execution. That keeps down the build cost that was classic MDA’s killer, without putting probability back into the path between your intent and the code a regulator will inspect.
Where I would not oversell it
I want to argue this case, but it would be dishonest to argue it without the objections, because some are the same ones that sank MDD the first time and they have not fully gone away.
The abstraction-versus-control tension is not repealed, only moved. When generated code is subtly wrong, someone still has to drop into it, understand it and decide whether to fix the code or the model that produced it. If the honest answer is usually “fix the code”, we are back to round-trip drift in new clothes. The discipline that makes this work is the same the old approach demanded and rarely got: change the model, regenerate and resist reaching past it. That is a cultural problem more than a technical one and culture is the harder of the two to shift.
Precision in natural language is itself a skill. The reason formal models are formal is that English is ambiguous and ambiguity is exactly what you cannot afford when a machine acts on your words literally. Martin Fowler’s account of driving an LLM to write tested code lands on treating it as a junior partner: set the architecture, ask it to show its reasoning, tweak as you go. That is craft, not magic and pretending otherwise is how teams end up with prototypes that break in production.
Finally, the comfortable cases are still the comfortable cases. Stable domains with recurring patterns gain most. Genuinely novel work, where nobody yet knows what the system should do, gains least, because there the bottleneck is deciding the intent and no amount of code-generation help accelerates a question that has not been answered.
Do I actually think it is valuable?
You asked me to take a side rather than hedge, so here it is.
Yes, with conditions and the conditions decide everything. The lightweight end of the spectrum, a DSL or a structured model with an LLM as the transformation engine and a metamodel as the contract, is genuinely valuable right now and more broadly applicable than classic MDA ever was. The economics that confined model-driven work to large, well-funded, stable projects have changed, because the two biggest costs, building transformations and building the language, both fell sharply. That widens the set of projects where driving software from a model beats writing it directly.
The heavy end, full classic MDA with UML, MOF and QVT, reads differently once you separate the layers. Its deterministic, portable descent from model to many stacks is not dead weight to be replaced. In banking, government and healthcare it is the asset, because it is auditable and reproducible. What AI changes is not that engine but the path into it. Classic MDA is less rescued than rebalanced: keep its trustworthy descent and let AI carry the load it always struggled with at the top.
The sweet spot is the modern model-driven middle, now with the labour split by layer: a purpose-built model that domain experts shape together with an LLM, a deterministic generator that carries it down to code and a metamodel plus human review holding the two together. In high-assurance domains that split is not a nice-to-have. It is the whole reason the approach beats letting an agent write production code directly. That is where the real division of labour shows itself: humans and AI together own the what, and the how is owned by whichever engine the stakes call for, an LLM where a wrong guess is cheap and a deterministic generator where it is not.
The deciding factor is not the technology. It is whether a team will hold the line: maintain the model, regenerate the code, verify the result against the metamodel and never quietly patch its way back into two sources of truth. Teams that hold it get much of what MDD promised in 2001, finally at a cost that makes sense. Teams that do not will rediscover, faster than before, that the map is still not the territory.