To AI or not to AI

I’ve been following your work around MDriven, Turnkey and TaJson for a while, and I recently revisited the “To AI or not to AI” post.
Reading it in 2026, with everything that has happened in the LLM/agent space, I have a very strong feeling: you already built a large part of what the AI world is now desperately trying to reinvent — you just do not frame it that way.
You were early, and now the market has moved to your doorstep.
1. You already solved a big piece of “guardrails”
In the current AI ecosystem, everyone talks about:
structured LLM output
JSON schemas and validation
“guardrails” between messy model output and serious production systems
When I look at MDriven Turnkey and TaJson, I see all of this already in place:
A strict, explicit domain model as the single source of truth.
Turnkey REST endpoints that accept only what the ViewModel allows.
TaJson as a declarative layer for mapping JSON into and out of that model.
Patterns for handling data “not known at design time” (FormFields/FormFiles, dynamic Name/Value lists, RawJson chunks).
This is exactly what many modern “AI reliability” tools are doing, just with different branding.
The difference is that you had it in 2019 and presented it as “good model‑driven engineering”, not as “AI guardrails”.
From the outside, MDriven already is an excellent exoskeleton for LLMs.
2. The market has shifted from “models” to “processes”
Your original post draws a clear and useful line:
“Figure out what to do” — the human, creative, messy part.
“Do it” — the deterministic execution, where tools like MDriven shine.
What changed in the last 2–3 years is that LLMs and agents have moved right into the middle: they now participate both in “figuring out” and in partially “doing”, but they do it through processes, not code.
Concretely:
Coding agents generate and refactor code and schemas.
Business agents orchestrate workflows, call APIs, and stitch systems together.
Guardrails/tools/schemas sit between these agents and production systems.
MDriven is naturally positioned to be the process spine and constraint system for such agents.
But you rarely speak in that language — you still speak mostly in terms of “applications”, “information systems” and “MDD”.
3. What you already have that maps 1:1 to today’s AI language
If I translate your existing capabilities into current AI buzzwords:
ViewModel + TaJson → “JSON schema + validation + merge policies for LLM output.”
Turnkey REST on top of ViewModels → “strongly typed tool APIs for agents.”
Dynamic properties (TreatListAsDynamicProperties, FormFields/FormFiles) → “schema‑extension zones for experimental or AI‑generated fields.”
RawJson and chunked processing via ServerSideJobs → “streaming / chunked post‑processing of large LLM outputs without blowing up memory.”
Actions like AddNew / Delete / Lookup / CleanUpAction → “business‑level policies that control how AI‑generated data becomes real domain objects.”
If you simply name these things the way the AI world now talks, a lot more people will suddenly realize that MDriven is not an “old‑school MDD tool”, but a very mature reliability layer for AI‑driven systems.
4. Where your slowness is now a strategic risk
From a friendly outsider’s perspective, the risk is not in your technology — it is in the story:
You let others “reinvent TaJson” under different names and grab mindshare.
You downplay how much of the modern AI stack is already implemented similar your engine.
You do not show end‑to‑end examples where an LLM/agent talks to MDriven through TaJson/Turnkey and is kept in check by the model.
The danger is that, if you continue to present this as “just good modeling and Turnkey tricks”, the AI world will pass you by while standing on ideas you already shipped several years ago.
5. Concrete directions that would make MDriven a first‑class AI exoskeleton
Here is what, in my view, would unlock a lot of value without changing your core philosophy:
First‑class “LLM/agent mode” in the docs and examples.
Show simple but real flows:
“LLM → JSON → TaJson → domain model → log/feedback back to LLM.”
Emphasize that the model and TaJson are the guardrails.
Generate AI‑facing contracts from ViewModels.
System prompts / JSON examples / JSON Schema or OpenAPI snippets derived from ViewModels.
Position this as: “If you talk to an LLM about your system, always talk in terms of the ViewModel we generate for you.”
Expose agent‑friendly APIs around TaJson.
Clear, minimal REST endpoints tailored for agents: “ValidateAndApplyJson”, “DryRunJson”, “ExplainJsonErrors”, etc.
Responses designed to be fed back into LLMs (“Here is what was wrong, here is how to fix it”).
Observability for AI traffic.
Metrics and logs specifically around “AI‑originated JSON”: which fields end up in dynamic properties, which get rejected, typical error patterns.
This turns MDriven into a feedback engine for prompt and policy improvement.
Name the thing.
You don’t have to chase buzzwords, but a clear label like
“MDriven as AI Exoskeleton: Guardrails for Agents and LLMs”
would instantly reframe your existing work without betraying your original values.
6. Why bother?
Because right now, a lot of teams are building fragile AI features on top of flaky JSON parsing and ad‑hoc validation code.
You already have a battle‑tested, model‑driven engine that solves these problems elegantly.
If you lean a bit into the AI vocabulary — without compromising your core idea of “Gist vs Modernity” — MDriven could become the quiet but critical backbone for many AI‑driven systems:
Agents negotiate and hallucinate at the edges.
MDriven holds the domain line in the center.
From my side, I already look at MDriven exactly this way: as an exoskeleton and safety harness for LLMs.
It would be great to see you embrace and articulate this role more explicitly — you earned it years ago.