Show HN: DAC – open-source dashboard as code tool for agents and humans (github.com)

119 points by karakanb ↗ HN
Hi all, this is Burak.

When agents became a reality one of the first things I wanted to do was to automate building dashboards. The first, and the most obvious, wall that I ran into was that a lot of the tools were just driven by UI. This meant that without the agents handling browser UIs and whatnot, it wasn't possible to have the agents do that. In addition, it would be impossible to review any of the changes the agent would make.

The first instinct there is to get your agent to build a React app for the dashboard. This works beautifully for the happy path, but I quickly ran into other issues there: - every dashboard turns out to be different - have to implement a backend to centralize the query execution - there is no centralized mechanism to control the rules and standards around visualizations - there is no way to get a semantic layer working with the dashboards easily

In the end, agents ended up reinventing the wheel for every new dashboard, even under the same project. Building a standardized, local project for these turned out to be building a BI tool from scratch.

After trying these out, I asked myself: what if the dashboards were built for agents as the primary user?

A product like that would need to have a couple of features: - First of all, everything needs to be driven by version-controllable text. YAML is fine. - Changes to the dashboards should be easy to review and understand by humans. - Agents are great at writing code, it'd be great if this were driven by code to have dynamic stuff: JSX would be great. - Static analysis being a first-class citizen: validate dashboards before deploying. Agents can check their work too. - A standardized way of deploying these based on a couple of files in a folder: operationally very simple. - Built-in semantic layer to standardize metrics.

That's what I ended up building: dac (Dashboard-As-Code) is an open-source tool and a spec to define dashboards, well, as code. It contains an implementation in Go that can be deployed as a single binary anywhere. The dashboards are defined in YAML and JSX, YAML for static stuff, JSX for dynamic dashboards. You can run queries at load time to define conditional charts, generate tabs on the fly per customer, or list charts for each A/B test you are running.

I built it in Go because I do love Go, and I think it is the greatest language at the moment to work with AI agents.

dac runs as a single binary, you can get started with a `dac init` command and it'll automatically create some sample dashboards for you based on duckdb. It supports 10+ SQL backends, with more to come. It supports validation, custom themes and whatnot.

You can see it here: https://github.com/bruin-data/dac

I would love to hear what can be improved here, please let me know your thoughts.

25 comments

[ 2.1 ms ] story [ 57.0 ms ] thread
Consider adding that snazzy gif in the README to the docs landing page. I went straight to the docs and then hunted for a screenshot to no avail.
DaC might be more distinguishable from DAC, although the context obviously also helps readers telling them apart.

Yours sincerely, came here for another DAC

The blurb about this is repeated several times but it is unclear to me what it actually does.
Semantic layer + validation is the interesting part imo, everything else is table stakes. would lead with that
[flagged]
Why do ppl think building something through yaml is ever a good idea??

(I know why: for a platform it’s simpler to parse a yaml than to run code, but it’s almost never a good idea for anything that needs to scale in complexity)

I would really hesitate to use a 1000 lines of yaml and modify them. I never found YAML easy to modify after a certain size.
Have you thought about how these dashboards could be built for an eink screen?

For a while, I was thinking about starting a side project of selling E-ink screens with easily configured dashboards. The project would support hobbies who want to build dashboards powered by a raspberry pi or something. I never pursued it, but it seems like you are now halfway there.

The "agents as primary user" framing is what makes this stand out from other dashboard-as-code tools. Having agents generate dashboards is one thing, but making those dashboards reviewable and standardized is the actual hard part. Curious about the semantic layer — when an agent modifies a metric definition in semantic/, how does validation work? Does DAC flag downstream widgets that would break, or is it more of a "trust but verify" model where you catch issues at render time?
Is this an AI generated comment? The format follows almost exactly the format of your other comments, down to the location of the em-dash.
Yet another "Show HN" that has existed for less than a week. I wish the rules against AI generated content were applied to all these too.
Well done on the launch! We’ve doubled down on the apps as YAML paradigm a few years ago and its pay great dividends on all fronts, esp now with code gen spinning out apps faster than ever for us (generated yaml). Our largest app is well over 500k lines of yaml - for those complaining about 1000 lines lol. With the right tool stack and conventions its so much easier to read, write. review and maintain. Shameless plug, we’ve built Lowdefy (open source) and 100s of dashboards using it. Have a look and keen to unpack if you’re interested in sharing experiences. Specially have a look at what we did with operators for dynamic needs. https://github.com/lowdefy/lowdefy
What I’ve heard often is that the customer might want to build a dashboard using AI on the fly.

Like imagine you have a site and there’s blank canvas. It has access to some data in the background. The user might be like “build a dashboard showing YoY performance of X and break down the shipments in a table by Y and Z”. Then the agent builds it and persists it such that when they log out and log back in they can see their custom dashboard they assembled themselves.

Love the idea. The ability to PR a dashboard would've helped us in multiple companies.

The two big areas that could use some docs/work: - Auth (one company was healthtech, so we needed auth even on VPN. The other didn't have a VPN so we needed auth) - Hosting: If it just needs to be run in a container and it doesn't need to be restarted that's fine. Though if there isn't a hosting document it's often a sign of a service that will need someone to keep it running all the time

(comment deleted)