"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.
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
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 :)
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.
>"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.
repeat after me: yaml is not 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.
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.
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.
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.
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
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.
This looks great.
"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/
Why visualize data? Graphs and charts always felt like the "show your work" in math class. It is forced synesthesia.
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.
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
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 :)
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.
Wow https://github.com/dbt-labs/dbt-charts has a great chat user / agent coding experience:
> 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.
>This looks great.
>"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
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.
https://github.com/nzoschke/gistdeck
For my personal dashboard, I store JSON and plotly charts as strings and render them with “new Function”. Seems to work well enough
repeat after me: yaml is not 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.
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.
Congrats on the launch Dave! I was wondering who was going to launch an attempt at industry standard here. Hope it gains widespread adoption.
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.
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.
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
Nice to see something built for AI that's supporting both openness and interpretablilty.
Is this associated with dbtlabs?
Yes this is a dbt product - will be in the dbt cli soon, we shipped it initially as a separate tool while it’s in preview.
This looks great can’t wait to try it out
how does this compare w/ evidence (https://evidence.dev/)?
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.
Yup, that's exactly the idea.
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.
thats intresting