Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This is cool, but I think too late.

    People are already used to getting *exactly* what they want from an agent. e.g. in our agent (https://www.definite.app/) we often see people take pictures of a sketch on a piece of paper or a screenshot from a few other tools (Stripe + Excel).

    Our agent has templates to start from, but ultimately writes a react app to give the user what they want. It'd be hard to get that experience in a framework like this.

    by mritchie712
  • Neat, but… I’ve built up skills for my agents to just generate SVG charts and embed them in the chat timelines. A library helps, sure, but you can get surprisingly good results that cover 80% of the timeline and bar chart visualizations without any libraries, and that goes for diagrams as well (mine generate .drawio XML)
    by rcarmo
  • 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.
    by zahlman
  • 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.

    by bryanrasmussen
  • Say you have an inventory - list of cloud database instances from all engineering teams in the org.

    Is this list growing over time or shrinking or remains the mostly the same?

    If the list is growing, is it growing evenly across all teams , or some teams stand out? Can I narrow down to a few teams and compare?

    What about overall health of the inventory - how many instances list security or billing optimization findings, how many instances are on the version that would be out of support soon and would need to be upgraded?

    A dashboard can answer all those questions immediately and make issues visible, as opposed to a long list in a form of a spreadsheet.

    by kantselovich
  • 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.
    by dinkleberg
  • This looks good... probably nice to have integrated with dbt like this.

    I have to dig in a bit more to what is possible in https://docs.dbtcharts.com/charts/extensibility/ and https://docs.dbtcharts.com/charts/interactions/ so far, and how feasible it is to actually use the end result in a customised website.

    Also similar: https://github.com/microsoft/flint-chart

    This is also likely to compete with features already provided by the warehouse such as https://docs.databricks.com/aws/en/dashboards/manage/visuali...

    by anentropic
  • 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
    by engrav3er40
  • 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

    by mollifier14
  • Hi there, Burak here, creator of DaC and Bruin: https://github.com/bruin-data/dac

    This is obviously a space we are very much interested in, so it is definitely nice to see approaches that attack the same problem. I haven't played with dbtcharts in depth yet but it looks very similar to DaC in principle, and also in the actual spec. I believe the industry definitely needs solutions like this to help get out of the legacy BI tools as Bİ is one of the biggest bottlenecks for AI adoption in large orgs.

    Excited to see further competition in the space, nice launch!

    by karakanb
  • 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.

    by dgudkov
  • 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.
    by mollifier14
  • 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.

    [I work at dbt/Fivetran]

    by oconnore
  • 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.

    [0]: https://vega.github.io/vega-lite/

    [1]: https://setoku.com

    by rgbrgb
  • 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
    by bbkane
  • I like the observable framework too - very flexible, you can nail very specific visualization details by dropping down to JS/html.

    Maybe this is targeted to pure SQL folks that can get lost in UI details.

    PS: one issue that I have with observable framework is authentication and authorization , it requires some system to be built on top of it to handle authn.

    by kantselovich
  • 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.

    by jerdthenerd
  • 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.

    by thingsilearned
  • Thank looks cool. Do you guys have plan to add interactivity to these charts? Will it be possible to inject JS in these charts?
    by iamcreasy
  • Congrats on the launch Dave! I was wondering who was going to launch an attempt at industry standard here. Hope it gains widespread adoption.
    by mceoin
  • 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/

    by nzoschke
  • 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.

    by pizzafeelsright
  • >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

    by stackghost
  • 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.

    by nzoschke
  • Malloy is an alternative to dbt, they have a similar product called Malloyyo [1], and Publisher [3], you can also the chat with HN data demo they have [4].

    DBTCharts says you can serve charts locally, but it seems they want you to use their hosting service in production. Whereas, Malloyyo / Publisher are free to use anywhere. If you like college football checkout how I visualize drive data in [2], made with Malloyyo.

    [1] - https://github.com/malloydata/malloyyo [2] - https://mrtimo.github.io/cfb-games/games-2026.html?%24SEASON... [3] - https://github.com/malloydata/publisher [4] - https://community.credibledata.com/hackernews

    by mrtimo
  • Worth separating the layers though, because "alternative to dbt" undersells what Malloy is for. dbt transforms and materializes tables. Malloy describes what the tables mean -- dimensions, measures, join paths, who's allowed to see what -- and compiles that down to SQL. It sits on top of dbt models fine, and plenty of people run it exactly that way.

    Publisher runs the model: you define the what, the engine figures out how. You write down what counts as a sale, how revenue is calculated, who sees which rows. Reshaping the data out of the form your systems store it in, deciding what to precompute, serving whichever agent or dashboard or API is asking -- that's the Publisher's job.

    A chart spec has to get its numbers from somewhere. If "revenue" is defined inline in the chart's SQL, the definition problem moved, it didn't get solved. Define it once in a model and the chart just renders it.

    Engineering detail if anyone wants it: https://www.credibledata.com/blog/posts/inside-the-ai-analyt...

    by kjnesbit