I thought AI killed MetaObjects. Then AI drift made it essential.

metaobjects AI architecture

I. One model, the whole stack

I started building MetaObjects in 2001 because the same patterns kept repeating across every consulting project I shipped. The data model needed persistence. The services needed DAOs and DTOs. The forms on the UI needed field bindings and validation. The MVC plumbing needed to know about all of it. Hand-rolling all that for every project was tedious — and the ORMs that would later become standard (Hibernate, JPA) didn't exist yet to even take part of that work off my plate.

So I built something that read a single metadata definition and generated the whole stack: persistence layer (ORM, DAOs, DTOs), UI form bindings, validation rules, MVC scaffolding. Define the entity once; let the generators produce the layers around it. (It was originally called ItemManager and Items. The shape of it mattered more than what I called it.)

The pattern wasn't novel even then. OMG was formalizing Model-Driven Architecture as a standard the same year, and Salesforce was building its multi-tenant platform on metadata-driven principles. What I had was a working, code-generating implementation I could use on real consulting engagements — not a standards document.

As I used it on more projects, the same foundation turned out to be great for two very different problems:

Speed at inception — and at every refactor. On startups and greenfield projects, MetaObjects let me move from idea to working software fast. Define the model; get persistence, APIs, forms, validation, and the MVC plumbing wired up around it. And refactoring stayed just as fast: when a pattern needed to change across every layer of the system, I updated the generator once and regenerated — no manual sweep across files, no half-migrated code. The whole system absorbed the improvement at once. The same tool that shipped Sendside's Salesforce-integrated secure messaging platform also shipped a credit card processing gateway and a high-uptime online poker platform — all rapidly, all on the same metadata substrate.

Alignment at scale. When those systems grew, MetaObjects kept their data models coherent across teams and services. On the enterprise side — Liquent's pharmaceutical regulatory platform at PAREXEL, where multi-tenant configurations customized the system for different pharma customers without code changes by overlaying customer-specific metadata on the base model; and the Logical Content Store at Cengage that became an issued US patent (US11314702B2, co-invented with Michael Seiler) — the same metadata foundation that gave projects speed at inception kept them coherent as they grew.

I never marketed MetaObjects. It was the unfair advantage I used to ship faster and keep things consistent on the work I was already doing. For 25 years it lived inside my consulting projects and my own products, quietly doing its job.

II. Why I set MetaObjects aside

By 2022, my job had changed shape. I was leading large engineering organizations — Chief Software Architect, then Divisional CTO at Cengage — and the work that filled my days was strategy, architecture decisions, M&A diligence, building leaders. Not writing the code. MetaObjects had always been my tool for shipping fast and refactoring fast, and I wasn't shipping or refactoring anymore.

Around the same time, low-code platforms were getting good in the enterprise. I spent serious time with Boomi on the integration side and OutSystems on the application side, and what I noticed was that both were essentially metadata-driven development solutions in vendor packaging. The same architectural idea I'd been using privately for two decades — define the model, let the platform generate the layers around it — productized and sold as a category.

There was a trap, though. The low-code platforms gave you the speed by owning your runtime. Your application lived inside their world. You paid in proprietary lock-in. MetaObjects had always been the opposite — it generates code you own, with zero runtime dependency on MetaObjects itself. Throw the platform away and your code keeps running.

Then AI arrived. The codegen story looked promising — models that could generate consistent code on demand. I noticed early signs of drift in the outputs but figured the AI vendors would solve it. Schema awareness, project-wide context, multi-file consistency: these felt like obvious next features. MetaObjects, for that stretch, was something I'd planned to mothball.

III. The drift didn't get solved

It showed up in my own side projects first.

I'd ship a feature in one part of a project with AI assistance. The next week, I'd add another feature elsewhere with AI assistance and notice that the model had generated a different representation of the same concept than it had the week before. Different field names. Different types for the same logical identifier. Plausible APIs that referenced functions that didn't quite exist the way they were called.

Inside any single AI-assisted session, the code was internally coherent. Across sessions — across files, across services, across the same project — the consistency broke down. Each generation was locally correct and globally divergent.

Others have called variants of this context drift, prompt drift, or — in Forrester's 2025 framing — agent drift: the silent killer of AI-accelerated development. I think of the system-level version, the one MetaObjects is positioned against, as AI drift: code that's locally coherent inside the prompt that produced it but globally divergent across the system that contains it. AI agents and AI-assisted humans both produce drift. Multi-agent systems amplify it. The more AI you ship in a codebase, the further the drift goes.

Then I started seeing the same drift at CareMetx, where AI-assisted development is embedded across our engineering organization as a core productivity multiplier. Different engineers, different sessions, different prompts: the same local coherence and global drift, just at organizational scale.

The refactoring problem makes it worse. Changing a pattern across many files with AI assistance is painful — the model rewrites locally and can't keep the rest of the system coherent. Big refactors that used to be "update the metadata template, regenerate the system" are now "manage a hundred locally-correct diffs that don't add up to a coherent change." Drift compounds when you try to clean it up.

The industry is talking about it — context engineering, schema-driven agent design, MCP, the 2025 wave of agent-drift papers. None of that conversation has produced an architectural solution at the system level yet. I can no longer wait for them to do it.

IV. The realization

I was looking at the wrong problem in 2022.

I had thought AI would absorb the work metadata-driven dev was doing, because AI could generate code. But the problem MetaObjects was solving was never "generating code." The problem was keeping generated code coherent at a global level across a system that grows — and making that system easy to refactor when patterns change. AI generates beautifully at the local level. It has no native mechanism for global coherence, and the vendors aren't building one.

Metadata is the missing mechanism. Define the entity once. Tell the AI to generate against that fixed definition in every service that consumes it. The schema isn't recreated; it's referenced. Outputs stay coherent across languages, services, and multi-agent systems because every actor generating code is reading from the same anchor. And when the pattern needs to change, you change the metadata template once and regenerate — the refactor is bounded and reversible instead of a hundred AI diffs to chase.

This isn't a lonely observation. The 2025 conversation around context engineering, schema-driven agent design, and knowledge-graph grounding all gesture at the same thing: AI needs structured context to stay coherent. The MetaObjects framing is sharper: the metadata layer is architectural, not a per-prompt tactic. It's where the schema lives, not what you paste in. I'll dig into how MetaObjects compares to each of those approaches in a follow-up essay.

And once metadata is the architectural spine, it doesn't stop at entity definitions. Extend it to systems, applications, APIs, payloads, and integration boundaries, and the metadata naturally constructs a graph of the estate. Expose that graph through the Model Context Protocol, and your AI agents stop guessing — they navigate. That's where the commercial side of MetaObjects is heading.

And this isn't a case for replacing AI with metadata. It's the opposite. AI is a far better consumer of metadata than humans ever were. What used to take careful template engineering to get from a schema to type-safe Java now happens through a model that reads the schema, understands the context, and produces idiomatic code in any language you ask for. The metadata is the substrate. AI is the generator. Together, they compound — coherence at scale and speed at refactor.

That's when I decided to bring MetaObjects back, AI-first this time. Starting with TypeScript — because that's where the AI codegen tooling lives now — and expanding to Java, .NET, and Python.

V. What MetaObjects v2 does about it

TypeScript-first. The original was Java-centric because that's where the consulting work lived in 2001. The new reference implementation is TypeScript — that's where the AI codegen tooling lives now (the Model Context Protocol, developer copilots, agent frameworks all assume or interoperate cleanly with TypeScript), and TypeScript's type system is expressive enough to be the schema language without losing fidelity when it maps to other languages.

Cross-language code generation. TypeScript, Java, and .NET generators are all in a usable state today — fundamentals in place, surface area growing with use. Python is the next expansion target. The same metadata defines a model that becomes idiomatic code in each language: not a Java-shaped object squashed into other languages, but type-shaped output that fits where it lands.

Cross-language codegen from a schema is not new — Protocol Buffers, OpenAPI Generator, AWS Smithy, and Microsoft TypeSpec all do versions of this. The difference is scope. Those tools generate API surfaces: wire formats, client stubs, server stubs. MetaObjects generates the whole application stack from one metadata model — persistence, DAOs, DTOs, UI form bindings, validation rules, MVC scaffolding, business-logic seams. Same architectural principle, much wider footprint.

Runtime metadata, not just compile-time. Most codegen tools stop at "produce code at build time." MetaObjects also uses metadata at runtime — which means a lot of what would otherwise be hand-written code stops needing to exist at all. Less code in the repo. Less code for AI to drift on. Less code for engineers to maintain. Less code = less drift = less bugs = faster dev. That equation is the unfair advantage I kept relearning across 25 years.

Codegen for compile-time safety. Where MetaObjects does generate code, it generates concrete entities engineers (and AI agents) write business logic against. When the underlying metadata changes, the regenerated entities change with it — and any logic written against the old shape breaks at compile time. The breakage is the feature: it surfaces drift before it ships, and it does so with the engineer's existing toolchain — type checker, linter, IDE.

Customization by augmenting metadata, not by writing code. For advanced uses — multi-tenant customization, regulatory variants, A/B configurations — metadata can be overlaid on the base model without compiling or changing the generated code. This is how Liquent's pharmaceutical platform customized for different pharma customers without code changes. It's how the same pattern scales now to AI-era systems where requirements shift faster than compile cycles.

A conformance harness across languages. Generators are useless if they drift from each other. v2 has a conformance harness that validates outputs across the supported languages — the generated code from the same metadata behaves the same way in TypeScript, Java, and .NET. When AI tools generate code that consumes this metadata, the harness catches drift before it ships.

Built to feed metadata to AI. The format is structured for LLM context. Your AI agents read metadata, your generators read metadata, your code reviewers read metadata. Every actor in the development loop is referencing the same anchor, in a form the models can use as input.

No lock-in. The lesson I took from Boomi and OutSystems is that the value proposition of metadata-driven development only holds if you also own your runtime. v2 generates code with zero dependency on MetaObjects. Throw the platform away tomorrow and your code keeps running. Metadata is the architecture; not a vendor moat.

VI. What this means for your codebase

If you're shipping AI-generated code at scale, you may already be seeing the drift problem — you may not have named it yet. The symptoms are recognizable.

  • The same entity has multiple representations across services, generated by different teams using different AI tools at different times. Nobody owns the canonical form.
  • Type definitions drift at integration boundaries. Tests pass within services and fail across them.
  • AI-generated API clients call endpoints that don't quite exist, or call them with slightly wrong shapes.
  • Schema changes ripple unpredictably. A field added in one service requires negotiations with downstream teams that didn't know they were downstream.
  • You spend more time reconciling AI-generated code than you saved generating it.

If any of that sounds familiar, the fix isn't bigger models. It isn't better prompts. It is an architectural decision about where your schema lives and what your AI tools generate against. The metadata layer is the smallest viable solution to a problem that gets worse the more AI you ship.

You can build that layer yourself. Plenty of teams have, in pieces, usually in the form of a "shared types package" or a "common contracts library." Those work until the next service team decides their needs are different enough to fork. The discipline is hard to maintain when the code is hand-written. With a metadata-driven generator, the discipline is enforced by the architecture: there is no "their" schema; there is only the schema, and every team's code is generated from it.

MetaObjects is one expression of this idea. It happens to be the one I built. I would rather you adopt the pattern in any form than not adopt it at all.

VII. What's next

MetaObjects v2 is shipping now. The open-source platform lives at metaobjects.dev; the commercial site lives at metaobjects.com. After 25 years of using it privately, I'm bringing it to market for the first time.

There's more I'm building on top of this foundation — including a cognitive-architecture framework called Draagon AI that I'll write about separately once it's ready to discuss publicly. The product family I'm shipping (Party Lore, FeltBots, the Michael Frank training platform, others coming) all sit on MetaObjects as their substrate. The dogfooding is the point.

I'll write more about what AI-first development actually looks like inside an enterprise stack, how the metadata layer composes with the rest of the system, and what we're learning at CareMetx as we embed AI into patient services workflows. If you want to follow along, my writing lives at dougmealing.com/writing, and I'm open to conversations — drop me a note.