"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work.
I'm seeing this all up and down knowledge work tools. I've started treating email as a BI problem -- ETL it from Gmail and and create many different views into it and reports from it.
I've worked in data for 15 years and I've never heard this argument. I love it :)!
Who knows, with AI this may be the future. Visualizations were created to help us understand data. Florence Nightingale published them "to affect thro' the Eyes what we fail to convey to the public through their word-proof ears."
Often a formula better represents a situation. But I'm not sure how much impact they'd have in spreading that understanding outside of a formula-minded audience.
I worked deep in big data briefly. Billions is too big for humans so we got creative how we visualized and filtered.
AI slop has a "smell" meaning there's an abstracted data filter that results in rose or poop output. Shakespeare variable says the name doesn't matter.
Sure, machines don't need visualization (although it seems that images are a surprisingly good medium to get context into agents), but humans still do. Mathematicians have plotted functions for a long time now. While the pure truth lies in the definition of f(x), the visualization helps the mind to grasp what it actually is. Humans will run companies for the foreseeable future, and so we will need visualization for the foreseeable future
Actually I think they do. Visualizations are a form of compression and focus.
All of my ai-driven plans use a tool I built to rasterize all text based visualizations. And I make the model present the rendered version to a clean room agent for brief-back. They go in circles until the diagram is good. Then, I instruct planning tools to always look at both the text and rendered version of all diagrams. I have found it to be surprisingly powerful.
Without guidance my agents tend to make me read CSVs.
Sure the data is correct, but it's obviously way easier for me to read it as a properly rendered table. Then you want to sort, group, aggregate the data. Visualize it many different ways if you will :)
>"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work.
Agreed. Coupled with bento[0] for slide decks, I think this type of project is a very welcome development, helping us move away from walled gardens and proprietary software suites.
Thanks for sharing this too. It reminds me of GistDeck a super old project that turned a gist into slides. Infinitely better than powerpoint or GSlides.
Hi HN, I'm Dave the founder of Chartio (YC'10 now Atlassian Analytics), announcing today dbt Charts, an open source YAML dialect and tool for declaring and rendering dashboards.
When making dashboards with claude or other agents, a lot of free-form artifacts are created that makes it hard to audit and scale. dbt Charts is a simple YAML dialect that declares and renders a chart (think markdown but for dashboards). Along with dbt its Apache 2.0 and launched today.
We hope this language + AI help make the BI space more open with dashboards as concise auditable code. Would love any thoughts and feedback.
Interesting, but I'm not sure how it's different from Observable Framework ( https://observablehq.github.io/framework/ ) for dashboards as code. I like that one because it's Markdown and JS instead of a language defined in YAML + templates
The use case that immediately came to mind for me was to use dbt charts as a rendering method for an MCP App.
You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source.
So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
It's neat but pretends to be more innovative than it actually is. BI has already been decoupled from everything else. People use AI to generate Excel and Power BI reports. YAML/XML/JSON - that doesn't matter. AI can generate whatever you instruct it to do.
So yes, a nice and logical development of dbt, but hardly as innovative as the blog post wants to sound. Nevertheless, I think it's a good idea that will be popular in certain circles. Hiring a professional data designer is a good idea - data visualization is very easy to get wrong.
I think I agree, but I'm not sure where Dave is claiming this is a paradigm shift in data visualization?
One of the key claims is actually that it's based on _old_ established visualization patterns from before BI tools were popular, and therefore results in consistently nice charts. The other key claim is just that it's simple and maintainable.
Sometimes tools & products can be useful as just well executed points in the known design space. You can already do all this with AI, but it's perhaps a little bit less nice and less maintainable.
AI can definitely generate whatever you tell it to do, but what to do with that artifact afterwards? If you want it to be reusable it needs to be a well-defined structured protocol/language. What good is a YAML describing a chart if all I can do is to give it back to the agent and say "read this and create a chart from it", the result will be vastly different from the chart you got the first time.
> the result will be vastly different from the chart you got the first time.
AI can generate reusable artifacts including definitions of the data sources, why not? Most BI dashboards are just XML or JSON (or YAML) files and include definitions of data sources (directly or via semantic models). I struggle to see how dbtCharts is different. Yes, your YAML schema is clean and nice, but that's because you're in the early stages :) Once you go through feature bloat, your YAML format will become much more complex.
AI can generate an XML/JSON/YAML definition of a BI report according to a spec and link the data source in whatever form it should be referenced in the file. For instance, here is a skills file for defining data sources (semantic models) in AI-generated Power BI dashboards: https://github.com/microsoft/skills-for-fabric/blob/main/plu...
Let's say (because it's true) I've been programming for close to 40 years but in completely different domains, such that the concept of "dashboard" means almost nothing to me. Could someone explain what this project actually is, or what "BI" is or why I would want it? I mean, I assume that "BI" is the thing that "PowerBI" implements, but other than that I couldn't tell you anything.
I'm not going to pretend to be an expert at it, but BI tools let you interrogate your data. This can be used for endless use cases for basically any department in an organization. But for instance, if you're a sales leader you might have some questions about all of the sales and marketing data in your company to focus your team's efforts for the next quarter. When you figure out which questions are actually returning useful findings, you then can take a set of these and build a dashboard which lets you easily re-examine those particular questions and their results with always up-to-date (or up-to-date-ish) data and can easily share it with the team.
well BI is I believe business intelligence, which is sort of like military intelligence, the set of practices and tools that have evolved around the need to present data to business people in such a way that they can make sensible decisions regarding their business.
on edit: So a dashboard is just one of those things were you see all the things you can do or interact with assembled together and from which you can navigate into any particular tool or view of data. Probably there would be meaningful data views on top. Like Number of Purchases versus people who started a purchase. And you could then drill down into the data that this chart represented to see how long purchases took, repeat customers, when people leave process or purchase etc. etc.
The dashboard is the entry point for how you will navigate your business data.
This looks really slick! I was building something similar, so visuals are re-useable artifacts that external services know how to render, where we ask agents in whatever the interface is, slack, team's other agentic harnesses etc. and the agents receive the spec from the service, in this case dbt charts. if there was a unified spec that was agreed upon these third-party harnesses and apps would all speak the same charting language which would be super cool. I haven't read through it in detail but how does this differ from something like https://github.com/vega/vega-lite
We actually use vega-lite under the hood. vega-lite is vast tool set to build charts with static data. dbt Charts adds a whole layer on top of that, which is dashboards with repeatable SQL queries. Also dbt Charts comes with a lot of opinionated chart style ideas. So vega-lite is a toolbox for chart assembly, and we use that toolbox to build dashboards.
On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though
https://openai.com/index/put-data-to-work/ was a compelling demo for me, being able to interact with a artifact and contextually EDA on a series or outliers is lowering the barrier to entry for BI exploration. I think meeting engineers where they work and being flexible and open sourcing these capabilities is really great to see
very cool! i'd been thinking about this idea and found vega-lite to be an interesting take as well [0].
i'll compare and look at folding this into setoku for app generation [1]. right now apps are just html blobs your claude authors + a mechanism for populating them with live data. definitely hard to audit but very flexible for operators to claude together internal apps. anyway, the charts look decent but really depend on the model that's making them and don't really follow any sort of style guide (example: https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc). Your lib could bring some consistency and make global styling possible.
repeat after me: yaml is not a programming language. (boo, hn strips emojis, i should know that)
very disappointed that their domain specific language is just yaml. conditionals and variable binding become insane war crimes when yaml comes to town. you have a friggin llm, do better
and when we computer folks see the word language its implied that its a computing on computers language not a friggin data format.
edit: the yaml to avoid complexity that should live in the sql side can back fire, some folks I was working with last fall were evaluating if a yaml based OLAP tool would work for them, and there were some pretty gnarly gotchas from a yaml based approach. Secondarily, theres a real case to be made that having the data linkages not visible in the charting layer means that groups of related plots with different axes wont have the right data linkage without forcing a lot more ETL for what should be a quick plot if the data already fits in memory.
theres actually a very important reason you want it to be an actual embedded dsl or tiny programming language!
The reason why llms can code at all is the hugeeeee amount of RL based on the loop of 1 "write code", 2 get compile time or runtime errors,3 fix it and iterate. Data file formats dont have that feedback loop so models will fall off the rails faster. Writing code that fits a latent adhoc schema just wont work as well, or will require burning a lot more context.
from that perspective, it could just be an EDSL little library in the host language, or it could be a friggin little custom language with an interpreter and good error messages.
A beacon of hope between all the vibe coded JS slop charts and dashboards! I love that this creates artifacts that are readable, maintainable and reproduce the same dashboard consistently (deterministically!), just with fresh data.
Everyone wants to come up with a clever One Spec to Rule Them All for generative UI. My bet is that the bitter lesson still bites. Models will continue getting faster and more error free at single-shot writing things from scratch with primitive libraries, and the flexibility that allows will make all of this for naught.
So this is a fairly domain specific (dashboards) spec and we intentionally avoid getting too generic.
The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from.
I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens.
But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.
I think we're still ways out until companies will blindly trust AI that the data they pulled is correct. If a data team member sees a dashboard or chart, their first questions is "Is the SQL below this chart correct?". The easier it is to see the SQL that pulled the data, the better.
"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work.
I'm seeing this all up and down knowledge work tools. I've started treating email as a BI problem -- ETL it from Gmail and and create many different views into it and reports from it.
I just wrote up some thoughts on that here: https://housecat.com/blog/making-gmail-data-fast-for-humans-...
A natural followup is how to better visualize this data in chat. The DBT table component looks like it could help https://docs.dbtcharts.com/charts/tables/
> Make charts of this with dbt Charts. Start with: uv tool install dbt-charts && dct skills intro
>
> build a dashboard of my hiring inboxes: list of candidate name / email / locale, application quality, response age
The one-shot dashboard is surprisingly good.
The rocket either lands or doesn't, safely, as expected. Green and Red lights are abstracted data plots.
The context should be the focus.
"Rocket must land at less than 0.2/mps" and pump the data into that context filter, more - reduce velocity, less - green light.
Who knows, with AI this may be the future. Visualizations were created to help us understand data. Florence Nightingale published them "to affect thro' the Eyes what we fail to convey to the public through their word-proof ears."
Often a formula better represents a situation. But I'm not sure how much impact they'd have in spreading that understanding outside of a formula-minded audience.
AI slop has a "smell" meaning there's an abstracted data filter that results in rose or poop output. Shakespeare variable says the name doesn't matter.
All of my ai-driven plans use a tool I built to rasterize all text based visualizations. And I make the model present the rendered version to a clean room agent for brief-back. They go in circles until the diagram is good. Then, I instruct planning tools to always look at both the text and rendered version of all diagrams. I have found it to be surprisingly powerful.
Sure the data is correct, but it's obviously way easier for me to read it as a properly rendered table. Then you want to sort, group, aggregate the data. Visualize it many different ways if you will :)
>"Unbundling BI" is absolutely where things are headed now that more people have agents, coding agents, agent computers to help with work.
Agreed. Coupled with bento[0] for slide decks, I think this type of project is a very welcome development, helping us move away from walled gardens and proprietary software suites.
[0] https://github.com/nyblnet/bento
https://github.com/nzoschke/gistdeck
When making dashboards with claude or other agents, a lot of free-form artifacts are created that makes it hard to audit and scale. dbt Charts is a simple YAML dialect that declares and renders a chart (think markdown but for dashboards). Along with dbt its Apache 2.0 and launched today.
We hope this language + AI help make the BI space more open with dashboards as concise auditable code. Would love any thoughts and feedback.
You don't really want to give a LLM client code execution environment like Observable Framework does. dbt charts appear to validate the entire yaml input including the SQL being sent to the data source.
So I'm getting: a data vis layer that can be dynamically defined and rendered via LLM/MCP client without the headache of sandboxing a JS Runtime environment.
So yes, a nice and logical development of dbt, but hardly as innovative as the blog post wants to sound. Nevertheless, I think it's a good idea that will be popular in certain circles. Hiring a professional data designer is a good idea - data visualization is very easy to get wrong.
One of the key claims is actually that it's based on _old_ established visualization patterns from before BI tools were popular, and therefore results in consistently nice charts. The other key claim is just that it's simple and maintainable.
Sometimes tools & products can be useful as just well executed points in the known design space. You can already do all this with AI, but it's perhaps a little bit less nice and less maintainable.
[I work at dbt/Fivetran]
AI can generate reusable artifacts including definitions of the data sources, why not? Most BI dashboards are just XML or JSON (or YAML) files and include definitions of data sources (directly or via semantic models). I struggle to see how dbtCharts is different. Yes, your YAML schema is clean and nice, but that's because you're in the early stages :) Once you go through feature bloat, your YAML format will become much more complex.
AI can generate an XML/JSON/YAML definition of a BI report according to a spec and link the data source in whatever form it should be referenced in the file. For instance, here is a skills file for defining data sources (semantic models) in AI-generated Power BI dashboards: https://github.com/microsoft/skills-for-fabric/blob/main/plu...
on edit: So a dashboard is just one of those things were you see all the things you can do or interact with assembled together and from which you can navigate into any particular tool or view of data. Probably there would be meaningful data views on top. Like Number of Purchases versus people who started a purchase. And you could then drill down into the data that this chart represented to see how long purchases took, repeat customers, when people leave process or purchase etc. etc.
The dashboard is the entry point for how you will navigate your business data.
On the standardized charting language, that would be the dream. All agents giving the same spec when they want to build a chart or dashboard, and then having different renderers of that. That is a steep goal. Such a language would need to be simple but still extremely versatile. I'm not sure that combination exists yet. Our language is simple and fairly versatile, but not as versatile as vega-lite itself, or JavaScript code even. Maybe we can evolve in that direction though
https://ggsql.org/
i'll compare and look at folding this into setoku for app generation [1]. right now apps are just html blobs your claude authors + a mechanism for populating them with live data. definitely hard to audit but very flexible for operators to claude together internal apps. anyway, the charts look decent but really depend on the model that's making them and don't really follow any sort of style guide (example: https://demo.setoku.com/apps/a7a1240ae0bc202c5eefa1cc). Your lib could bring some consistency and make global styling possible.
[0]: https://vega.github.io/vega-lite/
[1]: https://setoku.com
very disappointed that their domain specific language is just yaml. conditionals and variable binding become insane war crimes when yaml comes to town. you have a friggin llm, do better
and when we computer folks see the word language its implied that its a computing on computers language not a friggin data format.
edit: the yaml to avoid complexity that should live in the sql side can back fire, some folks I was working with last fall were evaluating if a yaml based OLAP tool would work for them, and there were some pretty gnarly gotchas from a yaml based approach. Secondarily, theres a real case to be made that having the data linkages not visible in the charting layer means that groups of related plots with different axes wont have the right data linkage without forcing a lot more ETL for what should be a quick plot if the data already fits in memory.
theres actually a very important reason you want it to be an actual embedded dsl or tiny programming language!
The reason why llms can code at all is the hugeeeee amount of RL based on the loop of 1 "write code", 2 get compile time or runtime errors,3 fix it and iterate. Data file formats dont have that feedback loop so models will fall off the rails faster. Writing code that fits a latent adhoc schema just wont work as well, or will require burning a lot more context.
from that perspective, it could just be an EDSL little library in the host language, or it could be a friggin little custom language with an interpreter and good error messages.
The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from.
I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens.
But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.