The State of Analytics Engineering survey is live.
Share your voice on how data teams are navigating the agentic era. Take the survey and you’ll get early access to the 2027 State of Analytics Engineering Report.
What should a dashboard be when AI is the one building it? Dave Fowler’s answer is a spec: dashboards as code that an agent can write and a person can still read, audit, and test.
Dave Fowler is the founder of Chartio, the cloud business intelligence company he started in 2010 and later sold to Atlassian, where it lives on as Atlassian Analytics. Chartio began as a tool called SQL Charts and went through Y Combinator in 2010. After the sale, Dave built a woodworking shop in San Francisco and spent time in AI safety circles. He is now the creator of dbt Charts, an open source language (Apache 2.0, like dbt Core) for defining charts and dashboards that AI can write and people can review. He calls dbt Charts “the Markdown of dashboards.” He is also the author of the book The Informed Company: How to Build Modern Agile Data Stacks That Drive Winning Insights.
He joins Tristan Handy for a conversation about what a dashboard should look like in the age of AI. Dave traces the path from SQL Charts and Chartio to dbt Charts, including the email to George Fraser that started. They get into why a spec that is agent-writable and human-reviewable sits between a BI tool’s output and a pile of generated JavaScript, why dbt Charts is built language-first, and how custom chart types, themes, and variables work inside the rails. They also discuss what Dave calls the BI bottleneck: his argument that BI tools are a main reason we still do dimensional modeling, and that AI may make that layer less necessary.
Check out dbt Charts, now in beta.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
Three ideas from the episode
1. A dashboard spec has to be agent-writable and human-reviewable. Dave says AI has had two paths for making a chart so far: ask a BI tool, or generate a pile of JavaScript and Python nobody can read. He argues for a middle ground, a spec that is still dashboards-as-code but that people can read, audit, test, and validate. Tristan adds that some data teams have gone so far down the road of agent-written code that they have lost the ability to review it. Dave’s shorthand is that dbt Charts aims to be “the Markdown of dashboards”: the minimum spec that defines an interactive dashboard, uses fewer tokens, and still leaves room to be flexible.
2. BI tools may be a main reason we still do dimensional modeling. Dave’s “BI bottleneck” is that BI tools can’t really work with relational data, so analytics engineers pre-join everything into datasets the tool can handle. If the tool could do joins, he argues, teams could work at a relational layer that is easier to build. He points to an Anthropic blog post that found AI worked better with a relational layer than with dimensional models, an approach that should be tested more. Tristan’s version is a clean gold layer with a clearly defined semantic model of how it joins together.
3. The competition for dashboards is now AI-made artifacts. Dave says the biggest threat to SaaS companies is the artifact space: once people can ask AI for exactly the dashboard they want, they stop going back to the one an analyst built. He says several members of dbt Labs’ customer advisory board told him they had already told their BI vendors they were leaving. His bet is that data artifacts deserve their own interface, where you can save, edit, and govern what AI makes. Tristan raises a world where agents monitor the business and spin dashboards up on demand, and Dave says a spec works for ephemeral artifacts the same way Markdown does.
Key takeaways
Lightly edited for clarity and length.
How did Chartio start?
Dave Fowler: I started Chartio in 2010, and we did Y Combinator that year. I’d done Y Combinator in 2008 with a different startup in the social space, and I saw all my friends making their own dashboards. I was making my own dashboards to see what was going on, coding them ourselves, and they were all really atrocious. My roommates at the time were on the Facebook data team, building the Facebook dashboards internally. Everybody I knew was spending 30 to 100% of their time coding dashboards and making tools for that, and there needed to be something in the cloud for it. So I made a little tool called SQL Charts, where you type SQL and get charts. Then I got more obsessed with making it so anyone could work with data, and I started Chartio, focused on a drag-and-drop and SQL combination.
What did the market look like when Chartio launched?
Dave Fowler: When I launched in the summer of 2010, there was really only RJ Metrics in the cloud space, plus Birst and GoodData, who were full-stack and super enterprise-focused. They were some of the first people going after cloud BI. About a year later Looker started, and we went head to head with them. Four or five years after that, the Mode and Periscope generation came out. Chartio was profitable, and we had great customers like DoorDash, Postmates, and the New York Times. Eventually I sold it to Atlassian, and it’s called Atlassian Analytics now.
Why design for the cloud before there was a cloud warehouse?
Dave Fowler: I think I had a really nice view of the future, because I was designing for my friends. Everybody was using the cloud, and they were all startups that didn’t have huge data yet. This was pre-Redshift, so people were just connecting directly to a read replica or a read-only user on their Postgres database. I thought there would eventually be some kind of cloud warehouse, but that was just a hunch. We eventually called what we built Visual SQL: a drag-and-drop interface that wrote SQL for you in any of these dialects, and then you could go into SQL mode and edit that SQL all you wanted.
What did you do after selling Chartio?
Dave Fowler: I was really nervous. I have a number of friends here in Silicon Valley who retired early and got really depressed, and that was one of the reasons I took a long time to sell Chartio. What would I do with myself? So I made a workshop here in San Francisco, with woodworking equipment, CNC machines, and 3D printers. People in the neighborhood and friends come by, I teach some workshops, and we build stuff together. Then I also got really worried about AI safety right when ChatGPT came out, and I spent quite a bit of time as kind of an AI doomer, frankly.
How did dbt Charts come about?
Dave Fowler: It was when I saw the announcement of you guys merging. Way back, when we were 20 people and Fivetran was five, I went to you and George and said, why don’t we join together? I really wanted to deliver a full-stack experience, where you log in with Salesforce and your modern data stack just gets set up for you. But it was really clunky to assemble while the tools were still at different companies. So when you merged, I sent an email saying congrats, and if you ever want to go up the stack, hit me up, I’ll come out of retirement and put a dream team together. George responded right away and said that’s exactly what he wanted to do. I wasn’t quite serious. But I started thinking about what was needed in the data space, I built a few prototypes, and George got excited about them.
Tristan Handy: There was a hold put on executing our merger, which I think ended up lasting about six months. During that period we were not allowed to do a bunch of stuff together, and that included comparing notes on new products.
Dave Fowler: I couldn’t talk to you until the DOJ said we could. It was exciting to show it to you for the first time, and you seemed to get it right away. You said, this isn’t BI, this is exactly what we need. It was something you were vibe coding on the side.
Tristan Handy: If you’re going to create high-quality data visualizations that are checked into Git, you want to think about it as a spec and a renderer, with a lot of intelligence put into the renderer. I had been playing around with early versions of “hey Claude, make this dashboard for me.” The code that came out the other side worked, but it was slow, it was different every time, and it was very expensive from a token perspective. I was able to build an absolute garbage version of this in, I think, two days, which was enough to make me think the ergonomics are really good, but there’s going to be real work involved in making it useful.
Why a spec, instead of AI-generated code or a BI tool?
Dave Fowler: So far there have been two main paths. One is you tell a BI tool to make something, and you get the traditional BI chart. The other is the AI makes a bunch of JavaScript and Python that you can’t really read. I think the right seam is the middle ground, where it’s a spec. It’s still dashboards as code, but it’s a spec you can audit, read easily, run tests against, and validate. Data teams can give that to their users and say, instead of having Claude make random messes of code and then coming to us to check it and trace the query through three layers, keep these traceable artifacts, and let us audit, test, and validate them.
Tristan Handy: Having something that is agent-writable and human-reviewable is not a super easy design constraint to satisfy, but it’s so important. I’ve spoken to folks on data teams who have gone so far down the rabbit hole of having agents write all of their code that they’ve lost the ability to review it. I’m not saying humans need to review all code forever, but it’s important for it to be reviewable if you want to review it. Otherwise the conversation is, are you sure this is correct? And I can’t tell you on my own authority that it’s correct. I’m going to turn around and ask my agent, and then rely on its answer.
What does “the Markdown of dashboards” mean?
Dave Fowler: Markdown is inherently valuable to AI. It’s abbreviated, it uses fewer tokens, it’s a better storage format, and it’s more parsable. If the AI were instead working in raw text or raw HTML, it would be a mess and confuse the AI more. So Markdown is a really nice abstraction, and with dbt Charts we’re basically trying to be the Markdown of dashboards: what’s the minimum spec to define a dashboard that’s interactive, can have all these settings, and is still very free and flexible? We also build in a lot of smart checks and give errors and warnings back to the AI very quickly. For example, if you only gave a chart this much width but put 100 bars in the data set, it’s going to overlap and stuff will get cut out. The AI doesn’t take eight iterations or look at PNGs. It gets to the end result for much less tokens.
Do you still need a spec if agents build dashboards on demand?
Tristan Handy: Imagine that agents are the ones monitoring our businesses. They use a semantic layer, watch the whole system of metrics, tell you here are the six things to look at today, and build a dashboard from scratch to interact with. Do we need this kind of thing in a world where dashboards are ephemeral artifacts that get spun up and down as needed?
Dave Fowler: A lot of it is ephemeral, but you might want to save these at some point. What we’ve built is very much like Markdown, and a lot of Markdown is ephemeral. The AI is just showing you Markdown. Sometimes you save it, most of the time you don’t. You can think of it like Mermaid charts inside Markdown: we have a fenced block for putting regular charts in. AI can pull a charting library off the shelf, but it makes a bit of a mess if you ever do want to save it. This should save you tokens, and it should be something you can save.
How do custom chart types work inside the rails?
Dave Fowler: We’re about to release custom chart types. We had them built before and took them back because the older AI models were abusing them, wanting to reinvent every chart type. The new models don’t do that nearly as much. A custom chart is made with SVG and Jinja, and AI can quickly make a template. We have Sankey diagrams and old-school information graphics, and we’ve recreated some from RJ’s old historic books, using people as the bars. It’s still within the rails, but at the right seams, so your custom charts inherit your theme, your colors, and your styles. You get 95% of the freedom with all the benefits of the rails.
Tristan Handy: Tell me that you can take the custom chart types you’ve designed and distribute them as dbt packages.
Dave Fowler: Totally. Already done. Well, not released yet, but already done.
Why do you think dimensional modeling may be less necessary?
Dave Fowler: I’ve had something for years that I call the BI bottleneck. I think, more than we like to admit, one of the main reasons we still do dimensional modeling is because BI tools really require it. They can’t really work with relational data, so you have to make some sort of pivot table, whether you call it a data set or an explore. The BI tools kind of blame this on business users not getting joins, so you have to come to us with everything pre-joined. That makes a huge bottleneck. It’s a lot of work for analytics engineers to prepare these data sets, and it makes all these copies of the data. If the BI tool could do joins, you could work at a relational, normalized or slightly denormalized layer, which is much easier to make. Anthropic’s latest blog post about how they enable self-serve analytics found that dimensional models confused the AI, because a user’s data was in five different tables. A relational layer keeps it to one entity. AI doesn’t make fan-out mistakes, and it does the joins. That’s a spicy take, but I think it’s the future, and it’s something we should test more.
Tristan Handy: A clean gold layer and a clearly defined semantic model of how the gold layer joins together. I totally agree.
How should humans and AI edit dashboards together?
Tristan Handy: I love the idea of anchor points inside a dashboard where you could create a comment and start an AI conversation, which maybe leads to changing the dashboard, or maybe just helps you interpret it.
Dave Fowler: We go a step further in dbt Charts. When you visit a dashboard there’s a chat thread, just like Claude or ChatGPT. When you go into editing mode, you can change the text directly on the page, change colors and backgrounds, with a whole GUI like Figma, or you can tell the chat. You can also select charts to give the chat context. So many things are just easier to do yourself than to ask the AI. I also added suggestion mode to ProseMirror, the text editor that both ChatGPT and Claude are built on. It lets you redline and green-line documents, so the AI works with you instead of redoing your work and leaving you with no say.
Where does the competition for dashboards come from now?
Dave Fowler: At dbt Summit, a big takeaway from our customer advisory board was that a bunch of them said they had already told their BI products they were leaving after a year. Nobody even uses those tools anymore. As soon as you give people the ability for AI to make their dashboards, that’s all they use. If you can get exactly the dashboard you want and ask for tweaks, you don’t go back to the Tableau dashboard some analyst made for you. I think the biggest threat for SaaS companies is this artifact space, where AI makes custom interfaces and custom reports. Do you go into Salesforce anymore? You just ask what the top five people are that you should call this week, and the AI tells you. The artifacts are a way to save and collaborate on those decisions and documents.
How do you get started with dbt Charts?
Dave Fowler: You go to dbtcharts.com, copy a message, and paste it into Claude, then basically say start using dbt Charts. Your token costs go down, and the artifacts that get created are prettier, readable, and governable. If you choose our hosting too, it’s more interactive. Humans can edit, share, and collaborate with their team much more easily than with something that was just vibe coded for you.
We user tested the install by launching a hundred different instances and scenarios: a CSV file, Postgres plus dbt, Redshift but no dbt setup. Each agent tried installing, and then we interviewed each AI about what was frustrating. We did that dozens of times to get a streamlined experience. While it’s in beta, the CLI is called DCT, and it works very much like dbt. We’d love to bring it together with dbt eventually, but that still has to be decided, and the beta has to go well.
Chapters
00:00 – Welcome
00:21 – The note for AI agents on Shreya’s website
01:29 – Where the note came from, and what it did to her inbox
04:19 – “Just don’t use AI to write emails”
04:34 – Stanford, Google Brain, and a data analytics startup
06:31 – Why data engineering problems led to a database PhD
07:15 – Why databases and AI sit in different departments
09:08 – The Berkeley PhD, ChatGPT, and DocETL
11:01 – Should agents interact with data differently than humans?
12:58 – The inner loop, the outer loop, and pre-attentive processing
14:33 – Designing tools and MCP servers for agents
16:11 – Why SQL sticks around
17:05 – What is a data agent?
19:06 – Why existing benchmarks fall short
20:50 – Can an LLM do relational algebra in context?
23:06 – Building a realistic benchmark: four properties
26:40 – Results: 61% pass@1, and why leaderboards mislead
28:44 – Analytics engineering meets data agents
30:14 – The semantic layer variant, and why humans must understand it
31:35 – Raw data versus gold tables
32:33 – “Who Validates the Validators?”
35:11 – How to build an LLM judge that works
37:38 – Meta, advertising, and closed-loop evals
39:18 – “In Defense of AI Evals”
41:31 – Model versus harness
42:56 – How practitioners should start with evals
46:08 – Headed to CMU
47:26 – AI SQL and why it costs too much
49:05 – A custom inference engine for AI SQL
50:21 – Wrap-up
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.