How to Review AI-Generated dbt Code

You ask Cursor or Claude Code for a new dbt model. It writes the SQL and Jinja in seconds. The model compiles, dbt build passes and the pull request looks clean. Two weeks later, finance asks why a customer metric moved, and nobody can say which line changed it.

AI made the writing step fast. The review step is the same size it was, and it now covers more code that nobody on the team typed. This guide shows how to review AI-generated dbt code before you merge. It names five ways an AI-written model goes wrong after it compiles. It explains why the usual checks miss them. Then it gives you a review routine to run in the editor.

AI Made Writing Models Faster While Review Stayed Manual

Data teams adopted AI for writing code first. In the dbt Labs State of Analytics Engineering 2026 report, 72% of respondents prioritize AI-assisted coding. Only 24% prioritize AI for pipeline management, which includes testing and observability. The same report found that 71% of data professionals name incorrect or hallucinated output reaching stakeholders as a top concern.

Developers feel the gap in their own work. The Stack Overflow 2025 Developer Survey asked what frustrates developers most about AI tools. The top answer was "AI solutions that are almost right, but not quite," picked by 66%. In the same survey, 46% distrust the accuracy of AI tools and 33% trust it.

An almost-right dbt model is the expensive kind. A syntax error fails the build in seconds. A model that returns plausible numbers passes every gate, and someone outside the data team finds the error first.

Five Ways an AI-Written Model Goes Wrong After It Compiles

Each case below compiles, runs and passes the common not_null and unique tests. Each one also changes a number that someone downstream trusts.

1. A NULL Branch Quietly Returns Zero

A CASE expression handles the "no orders" case with else 0 in one column and else null in the next. In a demo Jaffle Shop project, 38 of 100 customers had never ordered. The model reported a 0% return rate for all 38 of them, when the honest answer was NULL. Any average built on that column is now wrong.

A simplified version of the pattern looks like this:

case when number_of_orders > 0
     then returned_orders / number_of_orders
     else 0      -- should be null: these customers never ordered
end as return_rate

2. A Join Multiplies Rows

Someone changes a left join to a full outer join, or joins on a key that is not unique. The CTE that held 99 rows now holds about 990. Revenue doubles on the dashboard and every row still looks valid. The dbt anti-patterns guide lists this fan-out join first among the patterns review should catch.

3. A Column Change Breaks a Model Three Hops Away

The assistant renames a column or changes its type in a staging model. Nothing fails in that model. The break shows up in a mart three models downstream, or in a dashboard that reads it. Column-level lineage answers "who reads this column", but dbt Labs gates it to an Enterprise plan with Catalog. Its own documentation says the view does not reflect usage in joins and filters.

4. Logic That No Test Checks

Data tests check the rows a model produces after it builds. They catch a duplicate key or a null. They cannot tell you that a split payment was summed into the wrong bucket. A dbt unit test checks logic on fixed inputs before the model builds, and dbt has supported them since version 1.8. Writing a dbt unit test takes time, because each scenario needs hand-written input and expected-output YAML.

5. A Macro Nobody Can Explain

Generated models lean on whatever ref() calls and macros the assistant found in your project. The compiled SQL shows the result of the Jinja and hides where each piece came from. The reviewer has to trust a macro they never read, or open five files to check it.

Why Compiling, Data Tests and Pull Request Review Miss These Bugs

Most dbt code review happens in a pull request diff, after compile and data tests pass. Each of those checks answers a narrower question than the one you care about.

Compiling proves the SQL is valid. It says nothing about whether the numbers are right.
Data tests run after the build and check shape: nulls, keys, accepted values. Wrong logic with clean shape passes.
Pull request review reads a diff. The reviewer sees the changed lines, and never sees the row counts or the downstream models.
Asking a chatbot covers only the checks you thought to name in the prompt, and the chatbot cannot see your data.

Failure	Compile	Data tests	PR diff	Check that catches it
NULL branch returns zero	Passes	Passes	Often missed	Read the logic in every branch
Join multiplies rows	Passes	Passes unless a key test covers it	Missed	Row count per CTE
Column change breaks a model downstream	Passes	Fails late, if at all	Missed	Column-level lineage
Logic no test checks	Passes	Passes	Often missed	Unit test
Macro nobody can explain	Passes	Passes	Missed	Read every ref() and macro

Model quality does not close this gap on its own. On the Spider 2.0 benchmark of real enterprise SQL tasks, o1-preview solved 17.1% at launch. The best agent on the Spider 2.0-Lite leaderboard now scores 76.23, so it still misses about one task in four. Better models raise the share of correct SQL. Someone still has to find the rest before stakeholders do.

Run a Five-Question Review Before You Merge

To review AI-generated dbt code, turn the five failure modes into five questions. Answer each one with evidence before you approve the pull request. This makes a dbt code review a checklist instead of a skim.

Is the logic correct in every branch? Look for CASE expressions, NULL handling and divisions by a column that can be zero.
Does any join multiply rows? Compare the row count of each CTE with the one before it.
What breaks downstream if a column changes? Trace the changed columns to every model and dashboard that reads them.
Is there a unit test for the logic you changed? Data tests alone do not count.
Can you explain every ref() and macro the model uses? If not, read them before you approve.

You can answer these by hand with a scratch query per CTE, a search across the project and a YAML file per test. That works, and it takes hours on a long model. The open source dbt Power User extension, a dbt VS Code extension that also runs in Cursor, does the same routine in the editor.

Answer All Five Questions Inside VS Code or Cursor

dbt Power User has 1M+ installs, and 35,000 developers use it every month. Its other name is the PowerUser Plugin for dbt. Each answer below names the feature for one review question, links to a walkthrough, and lists what else that feature does during a review. The playlist shows all five features in a live dbt project.

Logic in every branch. Profile Query sends the compiled SQL to Altimate Code with the prompt already written. The report leads with correctness bugs, such as the NULL branch above, then ranks the fixes.