Why AI Makes Data Modeling More Important, Not Less

In the previous post, I walked through a car rental example to show when formal data modeling pays for itself and when it doesn’t. The framework: model when the cost of a wrong answer exceeds the cost of modeling.

That framework still holds. But 2026 is the year AI agents stopped being demos and started being features: reading schemas, generating SQL, and acting on results. Some argue this makes modeling unnecessary. If the AI can figure out your data, why invest in structuring it?

I think the opposite is true. AI makes the case for modeling stronger, not weaker. Here’s why.

The Case for Skipping Modeling

Let me give this perspective its due.

Modern LLMs can read INFORMATION_SCHEMA, parse column names and types, infer foreign key relationships, and generate correct SQL for reasonably simple schemas. This is real.

A dbt Labs benchmark published in April 2026 measured this directly:

“Text-to-SQL accuracy nearly doubled, from 32.7% to 64.5% on the full question set… For questions within the Semantic Layer’s scope, both models now return correct results 100% of the time.”

Source: Jason Ganz and Benoit Perigaud, dbt Labs (April 7, 2026)

Two things stand out. First, text-to-SQL is meaningfully better than it was two years ago, but at 64.5%, roughly one in three answers is still wrong, with no error signal. When no human reviews the SQL before it reaches a stakeholder or triggers an automated action, that failure rate compounds. Second, the Semantic Layer number, 100% on questions within scope, is not a marginal improvement; it’s a different quality regime. More on that later in the post.

Compute cost has collapsed. Scanning a 10TB denormalized table on a modern cloud warehouse (Databricks, Snowflake, BigQuery) costs single-digit dollars. The performance argument for star schemas is weaker than it has ever been.

For exploration, ad-hoc questions, and small schemas, AI plus flat tables genuinely works. Some teams will never need more than this. And that’s fine. But the moment you step outside that zone, the “AI replaces modeling” argument breaks down. To see why, it helps to look at how AI actually interacts with data.

Three Layers of AI and Data

Here’s what gets missed in the “AI replaces modeling” debate: AI doesn’t interact with your data in one way. It interacts at three distinct levels, and each level changes what “good enough” structure looks like.

Layer 1: AI-assisted development. Tools like Claude Code, Copilot, and Cursor help you write SQL, dbt models, tests, and documentation. When your project has Kimball models with declared grains, surrogate key relationships, and SCD-tracked dimensions, the AI writes better code. Structural properties give it guaranteed correctness signals. YAML descriptions and clear naming add a further probabilistic improvement: the AI follows existing patterns rather than guessing at intent. With an undocumented OBT, the AI has neither the structural signals nor the metadata.

The cost of a wrong answer here is low because you review the code before it ships. But productivity suffers when you spend more time re-prompting, clarifying context, and guiding the AI than actually building.

Layer 2: AI-powered analytics. An embedded AI assistant sits beside a dashboard or lives on an insights page within the product. Think Databricks Genie, or a custom bot on a customer-facing analytics page. A business user sees a revenue dip and asks: “Why did cancellations spike in one region last week?” The AI queries the underlying data and answers. No data engineer in the loop. No one reviews the SQL.

The cost of a wrong answer here is medium. A wrong number reaches a stakeholder or a customer.

Layer 3: AI agents. An agent monitors average daily rental rate. When it drops below a threshold, it doesn’t just alert. It investigates. It slices by dimensions: is the drop across all locations or just one? Driven by a specific channel? Did the vehicle class mix change? It produces a mini root-cause analysis and sends it to the revenue team.

These agents issue sequences of queries, interpret intermediate results, and trigger downstream actions (alerts, reports, pipeline interventions) without a human reviewing the SQL. The cost of a wrong answer is high: an automated decision based on misinterpreted data, with no one in the loop to catch it.

The through-line: as AI moves from assisting a human to acting autonomously, the cost of a wrong answer escalates from “you catch it in code review” to “an automated system makes a bad business decision at machine speed.” Modeling constrains the AI’s interpretation space. It reduces the number of ways the agent can be wrong.

Where AI Gets It Wrong Without Structure

These failure modes apply across all three layers but get more dangerous as autonomy increases. The core problem: when AI queries unmodeled data and gets the wrong answer, it looks like a right answer. There’s no error message, no warning. Just a plausible number that happens to be wrong.

Here are three ways this plays out, using the car rental model from the previous post.

These three aren’t exhaustive. Conformed-dimension drift (the AI treating the “same” entity as different things across fact tables) is another failure mode, covered by Part 1’s conformed-dimensions fix and left out here to keep the walkthrough focused.

1. Semantic Ambiguity: Multiple Valid Interpretations of the Same Question

The question: “What’s the average daily rental rate?”

What the AI sees in the OBT: Columns named rental_amount, insurance_fee, days, is_cancelled, currency. No documentation on what rental_amount includes, whether insurance should be subtracted, or whether cancelled rows should be filtered out.

What the AI might do:

The correct business definition:

Average Daily Rental Rate = SUM(rental_amount - insurance_fee) / SUM(days), applied to non-cancelled rentals only (is_cancelled = false).

Each interpretation above gets one or more of those conditions wrong. The AI picks one confidently and returns a number. No error. No warning.

2. Grain Confusion: Counting the Wrong Thing

The question: “How many rentals last month?”

What the AI sees in the OBT: One row per rental-day. A 3-day rental produces 3 rows.

What the AI does: SELECT COUNT(*) FROM rentals_obt WHERE ... and returns 3x the actual rental count. Maybe it notices rental_id and deduplicates, but only if the column name is obvious and the AI decides to.

3. Temporal Correctness: Reporting the Present as the Past

The question: “What was the vehicle’s class when this rental was made?”

What the AI sees in the OBT: A vehicle_class column with the current value. If the fleet team reclassified the vehicle from Standard SUV to Premium SUV last month, every historical rental shows Premium SUV.

What the AI does: Returns the current classification for all rentals. The AI has no way to know the value has changed. The current value looks perfectly valid. The error is invisible.

What Good Structure Looks Like for AI

A well-modeled dimensional structure addresses all three failure modes above. The dimensional model itself does the heavy lifting. A Semantic Layer can add another level of guardrails on top.

The Dimensional Model Alone

In a Kimball model, the fact table carries the same raw columns as the OBT: rental_amount, insurance_fee, days, is_cancelled. What changes is the structure around them. An AI reading a star schema gets structural guarantees that no amount of OBT documentation can replicate. YAML descriptions add a probabilistic improvement on top, but the structural guarantees hold even when documentation is sparse.

Mapped to the three failure modes:

• Semantic ambiguity is reduced because the grain is declared, FK paths are explicit, and the schema narrows the AI’s interpretation space. YAML descriptions help the AI correctly interpret what rental_amount includes and which rows to exclude, but the structural guarantees exist even without the descriptions.
• Grain confusion is eliminated because each fact table declares its grain upfront. fct_rentals has one row per rental. fct_rental_days has one row per rental-day. COUNT(*) gives the right answer by design, no deduplication required.
• Temporal correctness is built in because dimensions track history with validity windows. The temporal join pattern shown in the previous post ensures every rental references the vehicle attributes at the time of the event, not the current values.

This is already a significant improvement over an OBT.

Going Further with a Semantic Layer

A Semantic Layer sits on top of your dimensional model and defines business metrics as code. Instead of writing SQL, consumers (whether human or AI) request a named metric, and the Semantic Layer generates the correct query.

dbt’s MetricFlow is one implementation. Here’s what the average daily rental rate metric looks like, building directly on the fct_rentals columns described in the previous post:

# dbt Semantic Layer: MetricFlow
# Full docs: https://docs.getdbt.com/docs/build/metrics-overview

# Measures: pure aggregations on the fact table, no business rules baked in
measures:
  - name: net_rental_revenue
    description: "Rental amount minus insurance fee, per rental"
    expr: rental_amount - insurance_fee
    agg: sum
  - name: days_rented
    description: "Total rental days"
    expr: days
    agg: sum

# Metric: applies the business rule (exclude cancelled rentals) at the metric level
metrics:
  - name: average_daily_rental_rate
    type: ratio
    description: >
      Net rental revenue divided by total days rented,
      for non-cancelled rentals only.
    type_params:
      numerator: net_rental_revenue
      denominator: days_rented
    filter: "{{ Dimension('rental__is_cancelled') }} = false"  # where is_cancelled = false

Notice how this connects back to the failure mode. The three wrong interpretations the AI produced from the OBT all failed for the same reason: ambiguity about what to sum, what to divide by, and what to exclude. The metric definition answers all three questions in one place:

• net_rental_revenue is a measure: a reusable raw aggregation of rental_amount - insurance_fee from fct_rentals. No business rules baked in, so it can be reused by other metrics that might legitimately need a different filter
• days_rented is a measure: a reusable sum of days, same principle
• average_daily_rental_rate is a metric of type ratio: it divides the two measures and applies the “exclude cancelled rentals” business rule via a single filter: clause. The {{ Dimension('rental__is_cancelled') }} syntax is MetricFlow’s way of referencing a column through the semantic model’s entity. Putting the filter at the metric level keeps measures reusable and makes the business rule explicit as a property of this specific metric

An AI agent calls average_daily_rental_rate by name. It doesn’t write SQL. The business rule is enforced by the platform, not left to the AI’s judgment.

The Non-Additive Metric Guarantee

There’s a subtler guarantee too. Average daily rental rate is a non-additive metric: you can’t average pre-computed rates across vehicle classes or locations to get a correct total. If an AI agent computes the rate by class and then rolls those up, it gets the wrong answer. The Semantic Layer prevents this. Because average_daily_rental_rate is a ratio of two additive measures, every query (regardless of how it’s sliced) recomputes the numerator and denominator totals first, then divides. The correct aggregation is always enforced, not left to the agent’s judgment.

This is the payoff foreshadowed by the dbt Labs benchmark quoted at the top of this post: 100% accuracy for Semantic Layer queries within scope, versus 64.5% for text-to-SQL on the same question set. The same study showed text-to-SQL accuracy lifts significantly when queries run against well-modeled data (Claude Sonnet 4.6 hit 90.0% on modeled data versus the 64.5% baseline), so better modeling helps both approaches. But the Semantic Layer compounds the benefit by removing SQL generation from the path entirely.

Connecting back to multi-grain analysis:

Remember the multi-grain problem from the previous post, where operations needs rentals by channel and finance needs revenue by rental-day? The dimensional model solves this with two fact tables. The Semantic Layer takes it further by making these two perspectives explicitly queryable:

• “How many rentals this month?” queries the rentals semantic model, anchored to the pickup date
• “What’s the daily revenue yield this month?” queries the rental_days semantic model, anchored to the rental date

Same underlying data. Different grains. Different time axes. An AI querying an OBT has no structural way to distinguish these perspectives. With two fact tables and two semantic models, the choice is explicit.

The Decision Spectrum

Rather than prescribing one approach, think of it as a spectrum of modeling investment:

If your constraints point toward full auditability and regulatory compliance, Data Vault is worth exploring. If enterprise-wide integration across dozens of source systems is the primary challenge, look at Inmon. Those deserve their own deep dives from writers with direct experience to draw on.

Takeaways

1. AI makes the case for modeling stronger, not weaker. As AI moves from assisting humans to acting autonomously, the cost of wrong answers escalates. Modeling constrains the AI’s interpretation space and reduces the number of ways an agent can be confidently wrong.

2. The three failure modes (semantic ambiguity, grain confusion, temporal incorrectness) are invisible. The AI returns a plausible number. No error, no warning. Structure is what prevents the wrong answer from looking like the right one.

3. The Semantic Layer is the highest tier of guardrails. It turns your dimensional model into an API contract that AI agents can call by name, instead of writing (and potentially miswriting) SQL.

4. Match the investment to the risk, and watch for the signals. Start simple. Move to a dimensional model when the pain arrives: inconsistent metrics across dashboards, historical inaccuracies, grain confusion, teams disagreeing on numbers. Waiting for these signals is cheaper than pre-emptively modeling the wrong thing; ignoring them is expensive.

What’s Next

This post and the previous one cover the “why” of modeling. In follow-up posts, I’ll go deeper into the “how”:

• Kimball + dbt Semantic Layer: a code-level walkthrough showing how facts, dimensions, entities, and metrics work together in practice
• Building AI-ready data platforms: what your data warehouse needs to look like to reliably support agent-driven analytics

If Part 1 made the case for modeling and this post made the case for doing it sooner rather than later, I’d like to hear what’s pushing you one way or the other on your own team. The best frameworks come from shared experience, not theory.