Most conversations about AI in analytics start in the wrong place. They usually begin with generation: Can AI write a dbt model? Can it produce tests? Can it create documentation? Can it define metrics? Can it answer questions directly from raw warehouse tables?

Those are useful questions, but they skip the harder one. For most data teams, SQL is not the bottleneck. Understanding the data is. I’ve been working extensively with dbt, and data modeling has never been faster. But that speed often comes with a trade-off. I find myself moving quickly, only to circle back to Snowflake to run ad hoc queries, investigate why a uniqueness test failed, and then return to dbt to adjust the logic. It becomes a loop: build fast, validate late, fix, and repeat. Sometimes I do take the time for proper data exploration, but it’s expensive. It requires focus, and in practice, it’s not always feasible when you’re dealing with urgent requests, tight timelines, and constant interruptions.

Before an analyst, analytics engineer, data engineer etc. can build a useful model, they need to know what the raw data actually represents. They need to understand which columns are reliable, which fields are mostly null, which IDs are safe enough to join on, which values are malformed, which tables are genuinely related, and which relationships reflect real business concepts rather than accidental schema overlap.

That work is slow, manual, and easy to underestimate. It is also the work that determines whether a model can be trusted. AI can generate SQL quickly, but when it skips data understanding, it produces something worse than slow analytics: fast, confident, plausible nonsense.

The real opportunity is not “AI replaces data modeling.” The stronger pattern is: profile first, govern the meaning, then generate.

SQL Generation Is Useful, But It Is Not the Unlock

AI is already useful in modern analytics workflows. In dbt-style environments, coding assistants can draft transformations, suggest tests, write documentation, propose metric definitions, and help analysts move faster once the modeling intent is clear. dbt Labs frames AI-assisted data modeling as additive to—not a substitute for—tests, lineage, and project context. That is a real productivity gain. Nobody needs to romanticize hand-writing boilerplate SQL.

But boilerplate is not the hard part of data modeling. The hard part is knowing whether a model should exist at all, what grain it should use, which joins are valid, which fields can be trusted, and which business rules need to be preserved.

The role of AI in analytics is increasingly less about replacing the modeler and more about accelerating the modeler once the right context is available. AI works best when it operates on top of governed models, metadata, lineage, profiling results, and semantic definitions instead of trying to infer business logic from raw tables alone.

That distinction matters. A language model can look at a table called orders and infer that customer_id probably joins to customers.id. Sometimes that will be right. But it cannot know from names alone whether customer_id is populated consistently, whether guest checkout creates nulls, whether historical records use a different identifier, whether the table is order-grained or line-item-grained, or whether refunds are stored as negative orders.

Those are not SQL problems. They are data understanding problems.

The Hidden Bottleneck Is Context Generation

A useful data model depends on context, and that context usually comes from exploration. Analysts check null rates, uniqueness, distributions, duplicate patterns, outliers, malformed values, date ranges, candidate keys, and likely relationships across datasets. They open tables, scan columns, run ad hoc queries, inspect distinct values, test joins, count duplicates, and slowly build a mental model of the source system. Roundups of data profiling tools and practice still describe that slow loop as the price of trustworthy downstream metrics.

Then, if the team is lucky, some of that knowledge makes it into dbt models, documentation, tests, or a semantic layer. If the team is unlucky, it stays in one analyst’s head.

This is where many AI data workflows break. An LLM can generate a syntactically correct dbt model without knowing whether the input fields are reliable. It can produce a plausible join without knowing whether the join multiplies rows. It can write a metric definition without knowing whether the measure has business meaning. It can document a column based on its name while missing the fact that 80% of its values are null.

The bottleneck is not transformation. The bottleneck is creating a structured, reusable representation of what the raw data means.

Exploration Should Become Machine-Readable Context

The next generation of AI-assisted data modeling should start before the model is written. Instead of asking an LLM to reason from raw schemas and table names, teams should first create a compact, governed context layer from the source data.

That context should include column profiles such as null rates, uniqueness, common values, distributions, formats, and patterns. It should capture likely relationships, candidate keys, foreign-key-like behavior, and join confidence. It should flag anomalies such as outliers, malformed values, duplicate records, unexpected categories, and broken assumptions. It should also help describe the grain of each table: whether it behaves like events, entities, snapshots, transactions, or aggregates.

This is not just “data profiling” as a quality-control exercise. It is profiling as AI infrastructure.

Profiling outputs become a compressed representation of the dataset. They allow an AI system to reason about the shape, quality, and relationships of the data without needing unrestricted access to every raw row. That matters for accuracy, but it matters even more for sensitive data.

The safer pattern is not to send raw customer records, health data, financial transactions, or employee information into a general-purpose model. The safer pattern is to keep raw values in the warehouse or controlled semantic layer while giving AI the metadata it actually needs: schema summaries, lineage, statistics, quality signals, and governed metric definitions. AI gets enough context to help, but not more sensitive data than the task requires.

The Right Workflow Has Two Phases

A stronger AI-assisted analytics workflow has two phases.

First, enrich the context. Use automated profiling, lineage extraction, schema analysis, anomaly detection, join discovery, and semantic mapping to understand the raw data. Capture the results in a durable format that humans can review and AI tools can reuse. dbt’s notes on AI and data transformation describe a similar split: speed up mechanics once intent and context exist.

Second, generate inside that context. Once the system understands grain, candidate keys, quality issues, likely relationships, semantic constraints, and access rules, AI can safely help draft models, tests, documentation, and metric definitions.

This changes the analyst’s role in a useful way. Instead of spending hours manually browsing columns one table at a time, the analyst reviews generated evidence: “This table appears to be event-grained.” “This column is unique in 99.8% of rows.” “This join looks valid but creates 1.3x row expansion.” “This field has a high null rate after 2024-06-01.” “This category appears only in one region.”

That is a better use of human judgment. The analyst still decides what the data means, but they are validating structured observations instead of starting from a blank query editor.

A Semantic Explorer-style workflow

The Semantic Explorer beta on this site is one concrete pattern: profile and join-check in the browser, then export YAML and summaries for assistants. The steps below stay tool-agnostic.

Imagine a data team onboarding a new source system into dbt. The old workflow is familiar: an analyst inspects raw tables, writes exploratory SQL, checks distinct values, guesses joins, asks the source-system owner for clarification, and eventually creates staging models. Some tests are added if there is time. Documentation comes later, or not at all.

A better workflow starts with automated exploration. The system scans the raw data and produces a context package like this:

table: raw_app.orders

observed_grain: one row per order event

candidate_keys:
  - column: order_id
    uniqueness: 99.98%
    null_rate: 0.00%

quality_notes:
  - customer_id is null for guest checkout orders
  - status contains unexpected value "pending_manual_review"
  - order_total has negative values associated with refunds

relationships:
  - join: raw_app.orders.customer_id -> raw_app.customers.customer_id
    confidence: high
    warning: nulls present for guest checkout

  - join: raw_app.orders.order_id -> raw_app.order_items.order_id
    confidence: high
    relationship_type: one_to_many

Now the analyst can bring that context into Cursor, Claude Code, dbt Cloud, or another coding assistant. The prompt no longer says, “Model these raw tables.” It says, “Use this profiling context. These are the candidate keys. These joins appear valid. This table is order-event-grained. These fields have quality warnings. Preserve order grain. Use governed metric definitions where available.”

That is a fundamentally different task. The AI is no longer guessing from schema names alone. It is building inside a reviewed context.

From there, AI can draft staging models with appropriate casting and renaming. It can propose dbt tests based on actual profiling results. It can generate documentation that reflects observed behavior instead of column-name speculation. It can suggest semantic models that reuse approved dimensions and metrics.

The analyst’s job becomes sharper: review assumptions, approve business meaning, reject unsafe joins, and decide which tests should become production contracts.

Semantic Layers Become More Important, Not Less

Some people assume AI makes semantic layers less necessary. The opposite is more likely.

If AI agents are going to answer business questions, they need a governed contract for metrics, dimensions, filters, joins, and permissions. Otherwise, every answer becomes a fresh act of interpretation. dbt argues your AI stack fails without a semantic layer ; Databricks publishes a complementary view of semantic layer architecture, design patterns, and AI integration .

A semantic layer gives AI a controlled interface to business meaning. It tells the system which joins are approved, which metrics are canonical, which filters matter, which dimensions are valid, and which access rules must be enforced. That is far safer than letting an LLM infer business logic from raw schemas. For a strategy-level read on why that contract matters for trustworthy AI, see Strategy.com on semantic layer architecture and AI foundations .

This is also why “One Big Table” (OBT) thinking is a trap. A giant flattened table may look attractive for AI because it simplifies querying. There is one object to ask questions against, fewer joins, and less visible complexity. But that simplicity is often cosmetic. Pushback on “OBT is enough” shows up in practitioner threads such as Data modeling is dead / all AI needs is one big table? .

One Big Table designs can hide grain problems, duplicate logic, flatten nuanced relationships, and make metrics harder to govern. They may help a chatbot produce a quick answer, but they often weaken the reusable business model underneath.

AI does not remove the need for modeling discipline. It raises the cost of weak modeling because bad assumptions can now be repeated faster, across more interfaces, by more users.

Privacy Changes the Architecture

The privacy question is not a side issue. It shapes the entire architecture.

Many organizations cannot freely send raw sensitive data to LLMs. Even when enterprise controls exist, teams still need to minimize exposure. The principle should be simple: give AI the least sensitive representation that is sufficient for the task. Guides on LLM privacy, PHI/PII, and minimization restate the same minimization idea for regulated teams.

For data modeling, AI often does not need raw rows. It needs context. It needs to know that a column is 70% null, not necessarily the values in the non-null rows. It needs to know that a field looks like an email address, not the actual emails. It needs to know that a join creates duplicate records, not the underlying customer identities. It needs to know that a metric is governed, not every transaction behind it.

This is where profiling, metadata, lineage, and semantic layers become privacy-preserving AI inputs. They let teams expose structure without exposing unnecessary detail.

The Product Gap: Standardizing AI-Ready Context

The largest unsolved gap is standardization.

Most teams do not have a common way to encode exploration results as AI-ready context. Profiling tools produce statistics. Catalogs store metadata. dbt projects define models and tests. Semantic layers define metrics. Observability tools detect anomalies. But these signals are often fragmented.

What is missing is a shared context format for AI-assisted modeling. Such a format would describe column-level quality and distribution, candidate primary and foreign keys, relationship confidence, join behavior, table grain, row-level semantics, known anomalies, business exceptions, approved dimensions and metrics, security classifications, access constraints, and lineage from raw sources to modeled entities.

This could become a major advantage for the next wave of analytics tools. The best AI data products will not simply generate better SQL. They will generate better context before SQL is written.

Conclusion

AI will make data modeling faster, but only when it is grounded in the right context. The mistake is treating SQL generation as the center of the workflow. The real leverage comes earlier: helping analysts understand unfamiliar data quickly, safely, and systematically. Exploration is the hidden bottleneck in AI data workflows.

The future is not raw tables plus chat, it is not One Big Table plus an LLM, and it is not AI replacing modeling discipline. The stronger pattern is: profile first, govern the meaning, then generate.

Tools that can analyze raw data, detect joins, identify anomalies, summarize structure, and preserve that context for later AI-assisted modeling will define the next phase of the analytics stack. They will not just make exploration faster. They will make AI modeling trustworthy.