When AI Builds the Data Models, What Happens to Analytics Engineering? - Issue 326
dbt founder Tristan Handy on how AI changes the work of analytics engineers
Welcome to the Data Analysis Journal - a weekly newsletter on data science and analytics.
If you missed the July posts, here’s the roundup:
How Much Is an A/B Test Worth? - A new framework for deciding when to test, estimating how much each experiment is worth, and optimizing A/B tests for business value rather than sample size and statistics.
Should You Discount to Save the Customer? - Not always. Napkin math for estimating whether to offer a renewal discount and how low to go.
The Guardrails AI Needs for SaaS and Subscription Reporting - How to build a subscription waterfall that gives AI the guardrails it needs to keep churn, revenue, and subscriber metrics aligned and accurate.
I’m so excited to feature Tristan Handy today, founder of dbt Labs and now President of the combined Fivetran + dbt Labs, which serves more than 100,000 data teams worldwide.
We met at the Databricks Data + AI Summit in San Francisco, where I (finally!) had the chance to interview him. We talked about how AI is transforming analytics engineering, what data teams need to do to adapt, how Fusion and the agentic development loop fit into dbt’s vision for the future, and more.
I assume everyone reading my newsletter knows dbt well, but if you don’t - dbt is a data transformation platform that helps data teams turn raw warehouse data into reliable, documented, and reusable datasets using SQL and software engineering practices (version control, testing, and automated deployment).
For analytics, dbt was (and still is) transformational. It helped establish an entirely new role - analytics engineering (read more - Introduction To Analytics Engineering)
Read below Tristan’s take on why analytics engineering may matter even more in the AI era, and why the future of the role depends less on writing SQL and more on building the context, structure, and trust that AI needs to work reliably.
For years, analytics engineers created value by writing SQL, building reliable data models, and bringing software engineering practices into analytics. But now that AI can write SQL, does that make the discipline less relevant?
Tristan’s answer is counterintuitive: analytics engineering is becoming both less relevant and more relevant at the same time.
The code itself is becoming less visible. An analyst may ask an agent to build a model without ever touching the SQL underneath it. But the principles behind analytics engineering, like defining business logic, testing it, documenting it, and keeping it under version control, are becoming more important because AI agents need those structures too.
AI may reduce the value of writing complex SQL by hand, but it does not reduce the value of understanding how a company’s data fits together, and that understanding defines the next era of analytics engineering.
dbt was a workflow breakthrough
I have followed dbt since its early days. What it eventually became is difficult to overstate. I don’t know of a data team today that does not use it. Everyone does. It is now so embedded in analytics work that I truly have no idea how we did it all before.
To me, analytics engineering exists as a distinct discipline largely because of dbt. However, when Tristan and his co-founders started building dbt, they were not trying to invent a new profession.
They put into practice the idea that analytics should be treated like software, where SQL models were modular, changes were reviewed in git, logic was tested and documented, and analysts could work with data using practices already common in software engineering.
The approach made their consulting team more effective, but it took 3 or 4 years before the rest of the ecosystem began to pay attention. According to Tristan, the shift happened around 2019 and 2020, when dbt went from “a couple of people in a little Slack community” to becoming “part of the canon.”
For me, the reason why dbt received such massive adoption was by turning a good way of working into a system that people could adopt. As Tristan put it: “dbt is a product that encodes a set of best practices. It is not a technology breakthrough. It is a workflow and best-practice breakthrough.”
Making analyst-written code safe
I was initially skeptical of encouraging analysts to write production code. Analysts come from very different backgrounds: product, finance, marketing, operations, economics, and many others. Giving everyone unrestricted access to write transformations without shared standards can create a spectacular mess.
However, dbt made that work safer and more structured. It gave analysts conventions, testing, documentation, lineage, a framework for collaboration, and most importantly - the operating system around the SQL.
AI changes who writes the code, but not why it matters
This brings us back to AI.
Tristan agreed that one part of the original analytics engineering role is losing value: the ability to write complicated SQL manually.
“The analytics engineering skill of understanding data systemically is still important, but specifically being able to write complex SQL is less valuable than it used to be.”
dbt itself initially required users to know SQL, Git, the command line, data warehouses, and enough query optimization to understand why a model was slow. But those barriers are getting lower now. An agent can write a model, explain an error, generate a test, and refactor downstream references. The person directing it may never need to write the final SQL.
But the code still has to exist.
An agent can work with a dbt project because the project’s logic is represented in files it can read and modify. Definitions, tests, dependencies, and documentation are available as structured context. Business logic trapped in a spreadsheet, a sequence of clicks, or someone’s memory is much harder for an agent to use reliably.
“Agentic development has made it even more obvious that everything needs to be defined in code.”
In a way, this is the paradox - AI makes code less important as a user interface, while making code-based systems more important underneath.
The analyst may stop typing SQL, but the organization cannot stop defining what its data means.
The next data problem is context
Every major data and AI company is now talking about context. This is partly because models have improved faster than the information companies can provide to them.
The model can generate a valid query, but it still does not know:
which revenue field finance trusts
whether a cancelled annual subscription remains active until the end of its term
which test accounts must be excluded
why 2 dashboards use different definitions of an active customer
whether a table is current, deprecated, or safe for executive reporting.
These are organizational knowledge problems, not SQL-related.
Tristan believes the next challenge is to create a shared context layer for structured data and make it available to everyone asking business questions through tools such as ChatGPT or Claude.
The goal sounds straightforward:
A person asks a question about a business metric, the request passes through a governed context layer, a query runs against the company’s data platform, and the person receives a trustworthy answer.
Technically, most of the pieces already exist, but in practice, very few companies have assembled them well.
Version control, testing, and modular SQL all existed before dbt. dbt’s contribution was turning those pieces into a workflow that data teams could actually use. Tristan sees the context layer at a similar stage: the components are available, but the operating model is not yet settled.
The Fivetran–dbt Labs merger makes this direction clear: the companies completed their merger in June 2026, bringing data movement and transformation closer together. They also announced Agents Schema, an open-source proposal for storing metric definitions, semantic models, lineage, and business documentation in SQL tables that agents can query.
Instead of being a feature hidden inside one BI or AI tool, this is a bet that the semantic and context layer will become infrastructure.
Context is also a cost problem
Giving an agent access to more information does not automatically make the system better. In fact, it can make the system slow, expensive, and noisy.
Tristan used customer-call data as an example. A company could connect an agent directly to a system such as Gong and ask for feedback about a product. The agent may pull many full transcripts into its context window, consuming thousands of tokens for each call. Or the company could load the call data into its warehouse, use dbt to clean and summarize it, and give the agent a smaller, structured dataset.
Tristan estimated that this kind of preprocessing could significantly reduce token use for the query. The exact savings would depend on the transcripts, models, prompts, and summary design, but the underlying point is that raw access is not the same as efficient context.
We already learned this lesson with analytics. Giving everyone access to raw production tables - nothing good came from it and it did not create self-service analytics. Teams needed cleaned models, shared definitions, and governed access.
AI is repeating the same cycle at a much higher speed and cost.
Agents should not search every system of record from scratch for every question. Some context needs to be ingested, modeled, summarized, tested, and reused. Companies will also need to decide which tasks justify expensive reasoning models and which can run on smaller, cheaper ones.
So the context layer is doing 2 jobs:
Improving accuracy by giving the agent trusted definitions and data
Controlling cost by reducing how much irrelevant raw information the agent processes.
The goal is not to give agents as much context as possible. It is to give them the smallest amount of trusted context needed to answer the question reliably.
Core, Fusion, and the agentic development loop
dbt’s recent product changes show how the company is adapting its original idea for this new workflow.
dbt Core v2 is the 2nd major version of Core and is currently in alpha. It replaces the Python foundation with a much faster Rust-based runtime and remains open source under the Apache 2.0 license. Core and the Fusion engine now share that foundation.
Fusion adds richer SQL comprehension and development features on top. Instead of treating a SQL file largely as text, it can understand columns, types, and downstream dependencies. That allows the development environment to catch syntax and type errors earlier, support more precise column-level lineage, and help refactor references when a field changes.
These features improve the human developer experience, but they may matter even more for agents, because an agent is more useful when it can see the impact of a change, validate its work, and receive a precise error before it sends an expensive or incorrect query to the warehouse.
The current rollout still has caveats. Support varies by adapter and environment, and dbt’s documentation still lists some adapters and capabilities as preview or beta. Teams should evaluate actual compatibility rather than assuming every Core project can migrate without testing.
Will chat replace notebooks and BI tools?
When I asked Tristan about analytical notebooks such as Hex and Deepnote, he gave a more provocative answer.
“I think that notebooks are great, but I think that entire experience may just get sucked up into ChatGPT and Claude.”
His argument is that a chat transcript already resembles a notebook. In a traditional notebook, the analyst writes code and the kernel returns an output. In a chat interface, the analyst writes in English and the model produces the code, analysis, or chart.
I personally disagree - there is still a lot that needs to happen before we get there.
AI can create a chart, but in 90% of cases it creates one that I would not show to an executive - labels are poorly placed, categories are sorted incorrectly, colors do not communicate meaning, axes are confusing, and so on. The chart may be technically valid and still fail as communication. It takes me too many iterations with AI to plot something usable before I give up and do it myself.
Tristan acknowledged that BI is “incredibly hard and competitive and thankless.” A polished dashboard requires control over every small detail (which may help explain why dbt historically stayed away from competing directly with Tableau or Power BI).
Interestingly, during our conversation, he mentioned an experimental dbt Charts prototype: dashboards defined in YAML, rendered as HTML, and authored with the help of an agent. It’s not another drag-and-drop BI tool, but rather storing dashboards beside the dbt project so that the definitions, models, and presentation layer can be changed through the same development workflow.
Good visualization remains hard. With AI, the interface may move from SQL editors and notebook cells into chat, but the durable assets underneath - models, definitions, tests, and even dashboard specifications, still need structure.
What becomes more valuable for analysts
If AI can write SQL, analysts should be moving one level up:
Understanding how the business operates
Translating ambiguous concepts into precise definitions
Designing data models that can answer more than one question
Identifying which source should be trusted and where it breaks
Building tests and reconciliation rules around important metrics
Evaluating whether an agent’s answer is plausible
Communicating the result in a form someone can use to make a decision.
SQL still matters. You need enough fluency to inspect generated logic, recognize a bad join, notice double counting, and understand why a query produces the wrong grain. But writing every line manually is no longer the scarce part.
The scarce part is knowing what the query should mean.
This also changes how I think about the future of analytics engineering. The role expands from organizing transformation code to organizing business context for both humans and agents.
Analytics engineers helped companies move logic out of scattered dashboards and into tested, reusable data models. Their next job may be to move organizational knowledge out of scattered documents, meetings, SaaS tools, and people’s heads into a governed context layer. That is much harder than generating SQL, but also much more valuable.
AI agents need the guardrails dbt was built to provide
The original dbt idea that analytics should be modular, tested, documented, and version-controlled, becomes even more important with AI.
When humans wrote every transformation, weak documentation and inconsistent conventions produced slow, fragile analytics. When agents generate transformations at machine speed, those same weaknesses can produce bad logic faster and at a much larger scale.
Agents need constraints, definitions, lineage, and tests. They need to understand what a change will break downstream. In other words, they need the principles analytics engineering introduced all along.
AI may write more of the code, but someone still has to define what the data means, decide which logic to trust, and build the system that keeps it reliable. That is why analytics engineering is expanding beyond code and into the context that both people and AI need to make trustworthy decisions.
Thank you, Tristan!
You can find Tristan at:
You can learn more here:
 | A guest post by
|
It was right around 2017 when after spending a decade working with SQL Server I had a moment of panic thinking my career was heading for a dead end. In a way dbt revived my career.
Thanks for this, Olga. Handy's context-layer argument is one of the more directly tested claims in this space right now: four independent measurements in the past two weeks converged on the same split, with an AI agent answering business questions correctly around 70 percent of the time pointed at a raw database, and around 95 percent when pointed at a governed set of definitions for something like "revenue" or "active customer." The organizations already living in that 95 percent (banks, regulated drug companies, telecoms) mostly built those definitions for compliance reasons that predate the AI question by years. That splits the shift Handy describes into two very different jobs: for an org with that discipline already in place, "translating ambiguous concepts into precise definitions" is a small last step; for one still running on spreadsheets and tribal knowledge, it's a multi-year build.