DEV Community: Nilesh Kumar

LookML vs dbt Semantic Layer vs a Compiled Semantic Layer

Nilesh Kumar — Wed, 23 Sep 2026 14:42:39 +0000

LookML and dbt made the same bet: definitions belong in code that humans write and review.

The next question is whether a human should be writing them at all.

Both were right about the problem

Scattering metric definitions across dashboards was genuinely bad. Version control, review, reuse — real engineering discipline applied to meaning. That was a step forward and it stuck.

The shared constraint

	LookML	dbt Semantic Layer	Compiled layer
Authored by	Engineers, by hand	Engineers, by hand	Generated from your sources
Coverage equals	Authoring effort	Authoring effort	Estate size
New concept	A pull request	A pull request	Resolved on demand
Schema change	Maintenance debt	Maintenance debt	Drift detected automatically
Governance	Dashboards and folders	Upstream in the warehouse	Compiled into every query
Undefined question	Ticket	Ticket	Resolved or explicitly refused

The first two rows are the whole comparison. Everything else follows from them.

Why it matters more now than it did in 2019

When the consumer was a human analyst filing a ticket, "coverage equals authoring effort" was an acceptable trade — the request rate was bounded by how fast people could type.

Agents don't have that bound. They ask at machine rates, about things nobody anticipated, and a modelling backlog becomes the system's effective capacity.

The honest framing

This isn't LookML vs dbt. Those two differ mainly in syntax and ecosystem, and either can be the right choice for analytics engineering discipline.

The real axis is whether your semantic coverage scales with your data or with your headcount. That's the question that decides the next five years, and neither hand-authored option answers it well.

The full breakdown — the three-way comparison, migration considerations, and where each fits in a modern stack — is here:

👉 LookML vs dbt Semantic Layer vs a Compiled Semantic Layer

Originally published at colrows.com/blogs/lookml-vs-dbt-semantic-layer

What Is a Semantic Compiler? Deterministic SQL for AI

Nilesh Kumar — Wed, 16 Sep 2026 15:16:16 +0000

"Semantic layer" describes where something sits. "Semantic compiler" describes what it does.

The second one is falsifiable, which is why we use it.

Map it onto a compiler you already know

Compiler concept	Semantic compiler equivalent
Source language	A business question
Symbol table	The versioned semantic graph — entities, metrics, relationships, policies
Type checking	Does this metric exist at this grain, for this scope?
Link step	Proving a join path. No path, no binary.
Static analysis	Policy predicates injected before emission
Code generation	Dialect-perfect SQL for the target engine

Once you see the mapping, the design constraints follow automatically — and so does the property that matters.

The property that matters

Nobody asks a C compiler to try producing correct assembly. It either compiles or it fails with an error you can act on. That guarantee is the entire value proposition, and every compiler engineer takes it for granted.

Apply the same standard here: the system either produces correct, governed SQL or it fails loudly. It never produces plausible SQL.

That single difference is the whole argument for compiling rather than generating. A generator's failure mode is a confident wrong answer. A compiler's failure mode is an error message.

Why this isn't just naming

It changes what you can build on top. Deterministic output means you can cache it, audit it, reproduce it point-in-time, and reason about it in a regulated workflow. Probabilistic output means every downstream guarantee is statistical.

The LLM still does what it's good at — turning language into structured intent. It just stops being the component that decides what your business means.

The full breakdown — the compiler architecture in detail, the type system, and how join proof works — is here:

👉 What Is a Semantic Compiler? Deterministic SQL for AI

Originally published at colrows.com/blogs/what-is-a-semantic-compiler

Databricks Genie Alternatives: Beyond Curated Spaces Inside Unity Catalog

Nilesh Kumar — Fri, 11 Sep 2026 15:55:30 +0000

Genie is only as good as the Space somebody curated for it.

Which means the product you're really evaluating is your own team's capacity to keep curating.

Where Genie performs

A well-built Space with good example queries genuinely works. For a bounded analytical domain with an owner, it's a reasonable choice and it's already in your Databricks bill.

The four questions that decide it

Question	Why it matters
Who curates Spaces, and what happens when they leave?	Curation is the product
What does it do outside the curated examples?	Refuse, or improvise a join?
What covers data outside Databricks?	Scope stops at the lakehouse boundary
Is Unity Catalog governance enforced in the generated query?	Or around it?

Question two is the important one. A system that improvises when it runs out of precedent will produce a confident answer built on a guessed relationship, and nothing in the output signals that it did.

The two categories of alternative

Warehouse-native assistants — same architecture, same curation dependency, different vendor. Switching gets you a different logo and the same ceiling.

Semantic execution layers — resolve intent against a graph that maintains itself, so coverage isn't a manual artefact. Join paths proven rather than inferred. Policy compiled into the SQL. Coverage spans the estate rather than one platform.

The distinction that matters: does the system's knowledge of your business grow because someone curated it, or because the system read your sources and maintains itself with drift detection?

If it's the former, you haven't bought a product — you've bought a commitment.

The full breakdown — the scored comparison, the curation cost model, and how Unity Catalog governance composes — is here:

👉 Databricks Genie Alternatives: Beyond Curated Spaces Inside Unity Catalog

Originally published at colrows.com/blogs/databricks-genie-alternatives

APIs vs MCP vs A2A: What Enterprise AI Teams Need to Know

Nilesh Kumar — Wed, 09 Sep 2026 16:46:10 +0000

APIs, MCP and A2A get discussed as competing standards. They're not. They solve different layers of the same problem.

Here's the clean separation.

Three layers, three jobs

	Connects	Consumer	Solves
APIs	Applications to services	Code you wrote	Deterministic, contract-based access
MCP	Agents to tools and data	An LLM-driven agent	Discovery and invocation without bespoke glue
A2A	Agents to other agents	Another agent	Delegation and multi-agent coordination

An API assumes the caller already knows what it wants and how to ask. MCP assumes the caller must discover what's available and figure out how to use it. A2A assumes the caller wants to hand off a goal rather than make a call.

Why you end up with all three

They compose. A production agent stack typically has A2A between agents, MCP from agents to capabilities, and plain APIs underneath MCP servers doing the actual work.

Choosing between them is usually a sign the question was framed wrong.

The layer none of them provides

All three move requests. None of them governs meaning.

Whichever combination you land on, something still has to answer:

Which entity does customer refer to, at what grain?
Does a valid join path exist between these two concepts?
Is this caller entitled to these specific rows?
Can this answer be reproduced six months from now?

Those aren't transport concerns and no protocol will grow into them. They belong to a semantic execution layer sitting behind whichever protocol carries the request.

The protocols move the request. Something else has to govern the truth.

The full breakdown — the full architectural comparison, when to reach for each, and how they compose in production — is here:

👉 APIs vs MCP vs A2A: What Enterprise AI Teams Need to Know

Originally published at colrows.com/blogs/apis-vs-mcp-vs-a2a

Enterprise MCP Adoption: Why the Model Context Protocol Became Infrastructure

Nilesh Kumar — Wed, 02 Sep 2026 16:24:46 +0000

Twelve months ago MCP was a spec people argued about on GitHub.

It is now the default way agents reach enterprise systems — 10,000+ public servers and roughly 97M SDK downloads a month.

The wiring question is settled

That adoption curve ends the debate about whether to standardise agent-to-tool connectivity. You should, and the standard exists.

What it doesn't settle is the meaning question. MCP defines how a request travels. It says nothing about whether two agents on the same wire agree what revenue means, or whether either was entitled to ask.

Enterprise adoption splits in two

Track	Status at most organisations
Connectivity	Largely solved, increasingly commodity
Comprehension and control	Barely started

Teams that treat MCP as the finish line build a very efficient path to inconsistent answers. Teams that treat it as transport — with a governed semantic layer behind it — get agents that actually ship.

Why it became infrastructure so fast

Because the alternative was N×M integrations. Three agent frameworks, four data sources, twelve brittle connectors, and someone renames a column and three agents break at once.

MCP collapses that to one server per source. That's a real engineering win and it explains the curve.

The part to plan for now

The protocol is commoditising, which means it will stop being a differentiator within a year. What sits behind your MCP server — schema or semantics — is the decision that persists.

Expose the schema and every connecting agent infers meaning independently. Expose the semantics and they all compile through the same versioned graph, with the same proven joins and the same policy.

Same protocol. Same effort to connect. Completely different answers.

The full breakdown — the adoption data, what changed in the ecosystem, and how to plan the layer behind the server — is here:

👉 Enterprise MCP Adoption: Why the Model Context Protocol Became Infrastructure

Originally published at colrows.com/blogs/mcp-enterprise-adoption

Vanna AI Alternatives: When RAG-Trained Text-to-SQL Needs Governance

Nilesh Kumar — Wed, 26 Aug 2026 14:09:20 +0000

Vanna proved you can get surprisingly far by retrieving similar queries and letting the model pattern-match.

Then someone asks a question that resembles nothing in the training set.

How RAG-based text-to-SQL works, and where that ends

Find queries like yours, adapt them. When the question is close to something seen before, it's fast and often right. That's a legitimate architecture and it explains the traction.

Limit	Why it's structural
Corpus coverage	Accuracy tracks how well history covers the question space
Novel joins	No precedent to retrieve, so the model improvises
No entitlement concept	Similarity doesn't know who's asking
Silent corpus decay	Schema evolves; old queries stay in the index

The entitlement row is the one that blocks enterprise deployment. Retrieval has no notion of authorisation — you can filter the result, but the query already ran with whatever credentials the service holds.

The alternative isn't a bigger corpus

More examples raise the floor and don't move the ceiling. The ceiling is that pattern-matching has no model of meaning, so it cannot distinguish "no precedent exists" from "improvise something plausible."

Resolve-then-prove instead of retrieve-then-guess:

Parse language into a typed intent
Resolve entities and metrics against a versioned semantic graph
Prove a join path exists — fail compilation if it doesn't
Inject policy predicates for the caller
Emit dialect-perfect SQL

Step 3 is what a retrieval corpus fundamentally cannot provide.

When Vanna is still the right call

Open source, fast to pilot, full visibility, no procurement. For a proof of concept on a bounded schema it's a reasonable starting point — just budget for the fact that production governance is yours to build.

The full breakdown — the scored alternatives comparison, and the architectural difference between retrieval and resolution — is here:

👉 Vanna AI Alternatives: When RAG-Trained Text-to-SQL Needs Governance

Originally published at colrows.com/blogs/vanna-ai-alternatives

Why Power BI Copilot Delivers Wrong Answers (and What It Costs You)

Nilesh Kumar — Wed, 19 Aug 2026 13:24:44 +0000

Power BI Copilot rarely says "I don't know."

It says a number. The number looks right. That's the expensive part.

The failure isn't syntax

The generated DAX or SQL usually runs fine. The failure is semantic — the right query shape over the wrong interpretation.

Failure	What happens
Ambiguous column	Two tables have `revenue`; it picks one
Misread relationship	Exists in the model, means something else
Lost filter context	Visual-level filters don't survive into the generated logic
No provenance	Nobody can tell afterwards which definition produced the number

An answer you can't reproduce isn't an answer. It's a suggestion with a decimal point.

Why prompting doesn't fix it

Copilot inherits the Power BI semantic model, which means it inherits everything that model leaves ambiguous. If two measures could plausibly answer the question, no amount of prompt engineering tells it which one your CFO means — because that information was never in the model.

You cannot prompt your way past a missing definition. You can only supply the definition.

What closes the gap

Entities and metrics resolved against a typed, versioned graph before any query exists
A proven join path — no valid path, no query, rather than a plausible guess
Policy compiled into the query per person, so different entitlements produce different SQL
An audit trail that reproduces the answer exactly, months later

On real enterprise schemas that difference is not marginal. Raw schema access scored 14.5% in our benchmark; the same model with compiled, governed context scored 98.2%.

The model was never the variable.

The full breakdown — the specific failure modes with examples, what a wrong number costs, and the architectural fix — is here:

👉 Why Power BI Copilot Delivers Wrong Answers (and What It Costs You)

Originally published at colrows.com/blogs/power-bi-copilot-wrong-answers

Snowflake vs. Databricks: Why You Need an Autonomous Semantic Layer

Nilesh Kumar — Wed, 12 Aug 2026 15:40:52 +0000

Your warehouse vendor now sells the semantic layer too. Convenient.

Right up until half the business turns out to live in the other warehouse.

Both shipped something real

Snowflake Semantic Views and Databricks Metric Views are genuine improvements. Definitions live next to the data, governed by the platform's own model, queryable by that platform's AI features.

If your entire estate is on one platform, either will take you a long way.

Almost nobody's estate is on one platform

There's a warehouse, a lakehouse someone piloted, an operational Postgres, and a SaaS system that never got migrated. A warehouse-native semantic layer can only see its own warehouse.

Consequence	What it looks like
Cross-platform joins	Fall back to hand-written SQL
Duplicate definitions	Same metric defined twice, drifting
Per-platform governance	Coverage is per-platform, so gaps are structural
Partial answers	Agent returns a confident number computed over two thirds of the data

That last one is the dangerous failure. Nothing errors. The number is just wrong in a way nobody can see.

The walled garden problem

There is also an incentive question worth naming: a warehouse vendor's semantic layer is, among other things, a reason to move more data into that warehouse. That's not sinister — it's product strategy — but it means "should meaning live inside the warehouse?" is being answered by parties who benefit from one answer.

Meaning has to sit above the warehouse, not inside one of them: one versioned graph across the estate, join paths proven regardless of which engine holds the tables, compile-time policy applied uniformly, and dialect-perfect SQL emitted per target.

Adopt the native features. Just don't mistake them for the layer that spans your business.

The full breakdown — what each platform's feature does and where it stops, plus the cross-estate architecture — is here:

👉 Snowflake vs. Databricks: Why You Need an Autonomous Semantic Layer

Originally published at colrows.com/blogs/snowflake-databricks-semantic-layer

Semantic Layer vs. Knowledge Graph: Choosing Your AI Data Foundation

Nilesh Kumar — Fri, 07 Aug 2026 17:18:30 +0000

Knowledge graph people and semantic layer people keep arguing past each other.

One models how things relate. The other proves what a number means. You probably need both.

The honest division of labour

	Knowledge graph	Semantic layer
Models	Entities and relationships	Metrics, grain, filters, policy
Strong at	Traversal, inference, causality	Aggregation, definition, governance
Weak at	Math and consistent aggregates	Anything not modelled as a metric
Typical failure	Ontology drifts, nobody notices	Question falls outside the metric set
Answers	"How is X connected to Y?"	"What is X, exactly, for this person?"

Ask an agent "why did EMEA churn spike after the pricing change" and you need both: the causal path through the graph, and a metric definition precise enough that the number is defensible.

Where the argument actually goes wrong

Treating them as competing purchases. They operate on different layers of the same problem — one is topology, the other is semantics plus policy.

The real question is neither. It's which layer executes. A graph and a definition are both inert until something compiles them into governed SQL and runs it against your warehouse.

The execution gap

That's the piece most architectures are missing. You can have an immaculate ontology and a complete metric catalogue and still have no answer to:

Does a valid join path exist for this specific question?
Is this caller entitled to these rows?
Can I reproduce this answer in six months?

Intent → context resolution → constrained planning → governed execution. The graph feeds step two. The semantic layer feeds steps two and four. Neither performs step three.

The full breakdown — the division of labour in detail, a worked customer-risk example, and how the two compose — is here:

👉 Semantic Layer vs. Knowledge Graph: Choosing Your AI Data Foundation

Originally published at colrows.com/blogs/semantic-layer-vs-knowledge-graph

Governing AI Agents: Why Compile-Time Security is Mandatory

Nilesh Kumar — Wed, 05 Aug 2026 14:28:24 +0000

The moment you hand an agent warehouse credentials, your governance model is already obsolete.

Prompts aren't policy. Output filters aren't controls. Logs aren't proof.

Every runtime guardrail shares one flaw

It fires after the query ran. The rows moved. You are not preventing exposure — you're annotating it.

That ordering problem is not solvable by making the classifier better. It's solvable by moving the decision earlier.

What actually governs an agent

Step	What happens	What it prevents
Intent parsing	Language → typed intent	Prompt injection reaching SQL
Context resolution	Entities and metrics resolved against a versioned graph	Guessed column semantics
Join proof	Path proven, or compilation fails	Invented relationships
Policy injection	RBAC + ABAC + row/column predicates	Unauthorised rows ever being read
Audit emission	Question → SQL → predicates → result	An unanswerable post-incident review

The agent never sees a table it wasn't entitled to. Not because it behaved well — because the query was never compiled.

The test to run on any vendor

Ask what happens when a user requests something they're not entitled to.

If the answer involves filtering the result set, the data already left the warehouse and you're being sold a logging feature as a security control.

If the answer is "compilation fails," you're looking at governance.

Why compile-time is the only defensible position

Regulators don't accept "the model said so" as a control, and they never have. A number that informed a decision has to be reconstructable months later with the definitions that were in force at the time.

That means policy has to be part of query construction, not a wrapper around it — and the audit artefact has to be the SQL itself, not a description of intent.

The full breakdown — the governance architecture step by step, policy composition across scopes, and the audit format — is here:

👉 Governing AI Agents: Why Compile-Time Security is Mandatory

Originally published at colrows.com/blogs/how-to-govern-ai-agents-that-query-enterprise-data