The worst bug I ever inherited was a job that silently dropped 40% of records for 6 months before anyone noticed. No test caught it and no alert fired. Nobody owned the target table, so nobody looked. The code ran green every night and did the wrong thing every night.
I think about that job a lot lately, because the industry has decided to build a lot more of them and build them faster.
dbt Labs' 2026 State of Analytics Engineering report surveyed 363 practitioners and leaders between December 2025 and February 2026. 72% of teams now prioritize AI-assisted coding. Only 24% prioritize AI-assisted pipeline management, meaning testing and observability. So 3 times as many teams are working on shipping code faster as are working on checking it.
The code is the cheap part now, and checking it is where the value is. Teams that spend on generation and skip the guardrails are running up debt that someone like me will get paid to clean up in 2028.
The numbers from dbt's 2026 survey
- Trust in data as a priority went from 66% to 83% in a single year. According to dbt Labs' own writeup, that's the steepest single-year increase in the survey's history.
- Speed as a priority rose from 50% to 71%.
- Cost reduction barely moved, from 48% to 53%.
- 71% worry about hallucinated or incorrect outputs reaching stakeholders.
- 41% say ambiguous data ownership is still a problem, roughly flat from last year.
- 57% report higher warehouse and compute spend, while only 36% report bigger team budgets.
- 77% of managers emphasize AI for productivity.
Put those in a row and you get teams that want to go faster, say they care much more about correctness, and are putting their effort into the speed half.
To be fair to the respondents, wanting speed and trust together is reasonable. Every stakeholder I've ever had wanted both. What bugs me is the ratio. Speed moved 21 points, trust moved 17, and the tooling investment went overwhelmingly to speed.
The report tells you trust jumped, but it doesn't say why, and it names no single incident or regulation behind it. My guess, and it's only a guess, is that enough teams shipped an AI-generated model that quietly produced a wrong number in front of an executive. Once that happens, trust becomes very important very fast.
Data trust jumped 17 points and nobody bought tests
Trust is a priority for 83% of respondents, but only 24% put resources into the machinery that produces it.
I've been in those planning meetings, and the gap comes down to economics.
AI-assisted coding pays off right away and is easy to see. An engineer turns a 2-day model into a 2-hour model, their manager sees a burndown chart drop, and everyone feels productive. Data observability pays off in incidents that never happen. Nobody holds a retro for the dashboard that stayed correct. You can't put "nothing broke" on a slide and get more budget.
The compute numbers make it worse. 57% of teams are spending more on the warehouse, while only 36% got more money for people. Compute bills per query and scales on demand. Headcount needs approval, a req, a hiring loop, and 3 months of ramp. When you're squeezed, you let the warehouse absorb the inefficiency and let the backlog absorb the testing.
AI made writing a dbt model nearly free. Nobody made verifying one free. Whatever you ship without a test turns into a liability with a slow fuse.
I've been through 3 waves of "data engineering is getting automated away." Each time the tools changed and the failure categories didn't. You still get schema drift, late-arriving data, upstream teams breaking contracts without telling you, and joins that fan out and silently double your revenue. AI gets you to those failures faster. It doesn't prevent them.
What worries me most about AI-generated SQL is what it does to review. When a junior engineer writes a bad join, it usually looks bad. The CTE names are weird, the formatting is off, and something makes a reviewer squint. AI-generated SQL looks clean and confident whether it's right or wrong. Review has always relied partly on the author's code looking unsure, and that signal is gone.
If you're on a team in the 72% but not the 24%, you can do most of this yourself without a platform initiative.
- Test at the grain. Every model gets a uniqueness test on its declared grain. If you can't state the grain in a sentence, the model isn't done.
- Test row counts across boundaries. Rows in versus rows out on every join that shouldn't change cardinality. That's the test that would have caught my 40% drop in week 1 instead of month 6.
- Put freshness checks on anything a human looks at. Stale data that looks fresh does more damage than an obviously broken dashboard.
- Make AI-generated models carry tests before merge. If the model wrote the SQL, it can write the tests too. Review the tests harder than the SQL.
None of this is new, and dbt has made most of it trivial for years. The survey says most teams still aren't prioritizing it.
The ownership problem data engineering keeps dodging
The number I keep coming back to is the 41% with ambiguous ownership, because it didn't move. According to dbt Labs, technical integration barriers dropped from 35% to 27% year over year, so the tooling got better. Ownership stayed stuck.
Other surveys point the same way. Joe Reis' 2026 State of Data Engineering survey of more than 1,000 data engineers found 59% citing pressure to move fast and 51% citing lack of ownership as top pain points. Only 11% said their data modeling was going well.
Then there's the result I'd put on a billboard. The Practical Data Community's April 2026 data modeling survey asked 334 people what would most improve their modeling. Training came first at 28.1%, then clearer business requirements at 24.6%, more time at 21.6%, and dedicated ownership at 21%. Better tooling got 4.8%.
Vendors keep selling tools to an industry that has told them, in writing, that tools aren't the bottleneck.
The same survey found 42.5% of data models are owned by whoever built the pipeline, 19.2% have a dedicated modeler or architect, and 7.8% have no formal owner at all. I've worked in all 3 setups. The "whoever built it owns it" model works until that person leaves, gets reorged, or gets laid off. After that the table becomes folklore.
Now add AI to that. When an engineer writes a model by hand, they at least know what they meant. When an agent generates it from a prompt, the "owner" is whoever typed the prompt, and they may not be able to explain the join logic in the output. The result is an untested model that no human wrote and nobody is named as owning, feeding an executive dashboard. It's the setup where hallucinated numbers reach stakeholders, and 71% of respondents already worry about exactly that.
Pooja Crahen, a senior manager of analytics engineering at Okta, said in the dbt Labs release that you can't get both speed and trust without discipline in modeling, validation, and ownership, and that the discipline has to be a requirement rather than a best practice. That's her opinion, and I agree with it. I'd add that it has to be a requirement someone is accountable for, with a name next to it.
AI governance frameworks won't fix this on their own. I've seen plenty of governance programs that were thorough on paper and did nothing in practice. What fixes it is a person who can say "no, this doesn't ship without a grain test" and be listened to.
Using the trust gap in your next data engineer interview
The gap is a career opportunity if you position yourself right.
I've been on both sides of the hiring table. Everyone now has AI coding assistants, so writing SQL quickly no longer sets you apart. I've done 20+ loops in a single job search, and I've sat on panels where we passed on strong candidates for dumb reasons. The candidates who stood out most, even before this survey, were the ones who could explain how they knew their pipeline was right.
Senior interviews are already testing for this through behavioral questions. "Tell me about a time you caught a data issue before anyone else noticed." "Tell me about a pipeline you improved without being asked." Those are ownership questions. They check whether you treat data quality as your job or as something downstream.
Most candidates answer them badly. They talk about the pipeline they built. The strong answer covers what broke, how they found it, what the blast radius was, and what they put in place so it can't happen again. The actual job is debugging, and the interviewers who've done the job know it.
So here's the prep plan.
Get a debugging war story and tell it with numbers. Say "Found a fan-out join inflating revenue 12% for 3 weeks; added grain tests to 40 models," not "improved data quality."
Own the modeling round. Know grain, slowly changing dimensions, and fact table design well enough to explain why a model breaks as well as how to build it. Data modeling is the skill AI is worst at faking, because it depends on business context the model doesn't have. We're biased because it's ours, but for snowflake interview questions, try datadriven.io. We built it around grain, dedup, and "why is this number wrong" style problems.
Talk about observability like someone who's been paged. Know freshness, volume and schema checks, and know which alerts get looked at and which ones get muted by week 2. Interviewers can tell whether you've been on call or only read about it.
Talk about AI without being breathless or dismissive. "I use it to draft models and I make it write tests I review harder than the SQL" is a senior answer. "AI writes all my code" and "I don't trust AI" are both junior answers.
This is where the economics favor you. Teams are spending more on compute than on people, generating code faster than they can review it, and 83% of them say trust is suddenly a top priority. The engineer who can turn "we care about trust" into tests, owners, and alerts is solving the exact problem those teams have admitted to in writing.
So I'm curious where your team lands: are you in the 24% actually investing in testing and data observability, or are you shipping AI-generated models and hoping the dashboards stay honest?
Top comments (0)