DEV Community

Kamesh Sampath
Kamesh Sampath

Posted on • Originally published at blogs.kameshs.dev on

The Ghost in the Machine: Why AI Needs the Spirit of UML

The Ghost in the Machine

Introduction

AI can generate code at 10x speed. It still doesn’t understand the systems it’s building.

This story is about why we need to revive the spirit ofUnified Modelling Language( UML ) — not as diagrams, but as living infrastructure.

Back then, the hot trend wasModel-Driven Development (MDD) — generating code from models. UML was the flagship: Class Diagrams, Sequence Diagrams, the whole catalog. The belief was simple: if the model was correct, the system would be correct.

We were wrong.

UML didn’t fail because modeling was useless. It failed because of the Sync Tax.

You draw a class diagram. Rational Rose generates clean code. You ship it. QA finds bugs. Hotfixes go in. Production diverges. The model is now stale.

Keeping diagrams and code aligned becomes real work. Expensive work. The tax exceeds the value. So teams stop paying it.

We declared, “The code is the documentation,” and moved on.

Starting to sound familiar?

If you ask me, we are back in the MDD era. We’ve just rebranded it as AI-Driven Development.

The diagram is gone. The model remains. Only now, instead of Sync Tax , we pay the Hallucination Tax.

AI agents generate code at unprecedented speed. Ask, “Generate a Snowflake pipeline to ingest customer events,” and it produces SQL, tasks, maybe even a clean dbt model in seconds.

But the real question is: Does it understand the system it is operating in?

Specifically, when you give it that prompt, does it see the whole picture?

  • Your warehouse sizing and cost guardrails?
  • Your RBAC model and masking policies?
  • Which schema is production-certified versus experimental?
  • Which data is PII and which roles are allowed to see it?

Then there’s the Context Gap  — the ritual of re-explaining your infrastructure to an agent with limited working memory. Every new chat resets shared understanding. Yes, there are hacks. But none of them feel native.

The spirit of modeling was never about diagrams. It was about shared context.

AI has the muscle. It lacks shared context.

So here’s the twist: UML and AI are two halves of a broken whole.

UML was too rigid for humans to maintain. AI is too fluid for systems to trust.

To solve theField Velocity problem, we don’t go back to 2005.

We make AI pay the Sync Tax for us.

And the only way to do that is to encode intent as an enforceable structure.

The Living Model: From “Pretty Picture” to “Policy”

Operationalizing Human Intent
Operationalizing Human Intent: Our conceptual model for combining an AI Agent with a central knowledge repository of Architectural Memory to enforce security, governance, and infrastructure best practices for automated and compliant code generation.”

In my earlier blog on I nfrastructure-as-Intent, I wrote about how human expertise and experience can be carved into agentic Skills (In Part 1, we defined Skills as the codified expertise and human experience that turn operators into mentors for AI agents.) ** ** , turning each of us from operators into mentors.

That shift forces us to stop authoring static models and start inferring living ones.

The truth of your system already exists — scattered across scripts, RBAC definitions, masking policies, and CI/CD pipelines.

So why does AI still hallucinate?

Because of the Context Gap  — the absence of shared context.

Here is how we revive the UML spirit: by turning Skills into the rules of engagement for our AI agents.

The Guardrail Effect

When we practiced UML, we followed the structure. First system architecture. Then sequence diagrams. Then class diagrams. Step by step, we built a shared understanding.

In the AI era, shared understanding becomes shared constraints.

Instead of executing a prompt literally, the AI must query the Skills.

If a Skill declares, “All customer data requires masking primitive X,” that declaration becomes an enforceable structure. The agent generates within it, not around it. The constraint is applied at the point of creation.

That is the spirit of UML — reborn as an executable policy.

Policy is what machines can execute. Intent is what they can reason about.

Semantic Reasoning

Shared constraints unlock something UML never could: semantic reasoning.

UML provided syntactic structure. The reasoning lived in our heads.

AI can reason — but only if we give it structure.

Ask, “If I change this stream’s schema, who breaks?”

The AI uses the Skill graph to simulate impact and produce a blast-radius report before a single ALTER TABLE runs.

That is the difference between generation and understanding.

This is where intent stops being documentation and starts becoming infrastructure.

Closing the Context Gap

In my earlier post, I introduced the idea of a Shared Manifest  — a persistent memory layer for AI agents. Not as a long prompt, but as structured Skills.

With Skills, the agent carries Architectural Memory.

It knows your certified schemas. Your cost guardrails. Your intent. Because it operates inside the same world model as you.

The Living Model is not documentation. It is infrastructure.

This is Infrastructure-as-Intent in action.

We use the rigidity of the model to keep AI honest.

We use the fluidity of AI to pay the Sync Tax  — bringing the spirit of UML back as living infrastructure.

A Call to Builders

We don’t need a return to 2005-era static diagrams. We need an Architectural Memory for our systems.

Agentic AI tools have already defined the schema. Don’t panic about learning another DSL 🤣. It’s not one.

It’s a disciplined Markdown. Clear English. Proper structure. The same rigor you apply when writing a design doc.

Except now, that document is executable.

It’s not documentation for humans alone. It is codified wisdom for agents.

The era of blind velocity is over.

It’s time to give the muscle a brain.

Visuals note: The conceptual diagrams in this post were generated by Google Gemini.

About the Author

Kamesh Sampath is a Lead Developer Advocate at Snowflake, author, and long-time open-source contributor with 25+ years in enterprise software. He works across data engineering and AI with developer communities, helping practitioners turn modern data platforms into systems that hold up in production.

Through talks, writing, and hands-on demos, Kamesh makes cloud, data, and AI topics easier to understand and apply — grounded in real-world constraints. His sessions mix deep technical detail with practical patterns that developers and data teams can apply right away.

Lately, he’s been speaking about Apache NiFi (Snowflake Openflow), AI (Snowflake Cortex), and PostgreSQL.

He believes technology becomes powerful when it is shared, taught, and built together.

GitHub |LinkedIn |Blog | X

Top comments (0)