Your data stack is about to get a lot more contributors | Cassis<br>Skip to content Product<br>Blog<br>Docs

Try for free

Talk to us

Back to stories<br>Your data stack is about to get a lot more contributors<br>AI tools are enabling business users to contribute directly to dbt models and metric definitions. The data stack isn't ready.

Matthieu Blandineau May 19, 2026

On this page

Summary

AI creates contributors, not just consumers<br>What open bar looks like in practice<br>Governing meaning is harder than governing code<br>Today, everyone is improvising. What’s next?<br>Yes, AI is transforming the way business users query and consume data. But it’s also fueling a less discussed shift: business users are starting to contribute directly to dbt models, metric definitions, and Looker views. AI tools are making it possible, and they can’t wait for tickets anymore.

That’s not a bad thing. These are the people who know how a campaign is actually attributed, which customers count as “active,” what finance means by “net revenue” versus what product means. Getting that knowledge into the data stack directly is something data teams have wanted for years. The problem is that it’s happening before anyone has figured out how to govern it. A head of analytics at a 100-person company recently told us she now runs workshops titled “GitHub: what is it?” for the marketing and operations people submitting pull requests.

AI creates contributors, not just consumers

Most of the conversation around AI and data focuses on consumption: analytics agents, natural language queries, better answers faster. There’s broad agreement that context is the key enabler, that agents need the right business definitions and metric logic to query accurately. Teams and vendors are working on consolidating that context and feeding it to AI agents.

The contribution side gets less attention. AI doesn’t just help people ask questions. It helps people who aren’t on the data team propose changes to dbt models, metric definitions, Looker views, and semantic-layer configurations. And not every contribution carries the same risk.

A marketing analyst can’t find an attribution metric that matches their use case, so they build a new one. That’s a duplication risk: now two definitions exist for roughly the same concept, and nobody downstream knows which one to trust. A RevOps lead modifies an existing pipeline metric to match a new comp structure. That’s a breaking-change risk: dashboards, reports, and agents that depend on the old definition silently shift. A product manager asks Claude to scaffold a new explore from a description of what they need. That’s low individual risk, but fifty of those with no cleanup path is a maintenance problem.

This isn’t yet universal. Most data teams aren’t drowning in PRs from product managers. But at companies where AI tooling is moving fast, the shift is already visible. A head of analytics at a gaming company described where this is going: “You won’t be able to frustrate them anymore because they’ll have access to practically everything. It’ll be open bar.”

Today, data teams have pieces of the guardrail stack: Git review for code changes, semantic definitions in dbt or LookML, ownership metadata in catalogs, content validation in BI tools. These pieces are scattered across different systems, but they work when the data team reviews every PR, when contributors know the conventions, and when volume stays low enough for human gatekeeping. The data team is the bottleneck, and that’s fine, because the bottleneck is also the quality gate.

That model is built for a world where contribution comes from a small group of technical people. When volume grows and contributors don’t share the conventions, the gate doesn’t hold.

What open bar looks like in practice

We’ve spent the last four months talking to data teams at companies ranging from 40-person startups to 15,000-person enterprises: dbt-native platform teams, Looker-centric analytics groups, mixed environments running parallel BI stacks. The failure modes are organizational rather than technical.

No inventory of what already exists. Most companies don’t have a current, searchable map of their metric definitions and business logic. Catalogs exist but are often stale or incomplete. So when a new contributor needs a metric, they build one, even if a version already exists somewhere in the stack. The same concept gets modeled in slightly different ways by different people, and nothing flags the overlap.

No shared definition of a valid contribution. When three technical people are contributing, implicit norms work. Everyone knows how models are named, where definitions live, when to create something new versus extend what’s there. Those norms don’t transfer to twenty contributors of varying technical backgrounds. And if the data team steps in to review every PR manually, the contribution model hasn’t reduced their workload. It’s relocated it.

No visibility into the blast radius of a change....