In terms of validation it will validate queries, metric definitions, chart definitions and all ahead of time, before render. That way agents tend to validate their work much quicker.

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.

Comments URL: https://news.ycombinator.com/item?id=47949066

Points: 115

# Comments: 35

Comments URL: https://news.ycombinator.com/item?id=47518452

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47222270

Points: 203

# Comments: 293

A bit of a back story: we started Bruin as an open-source CLI tool that brings together data ingestion, transformation, quality and governance. You can build data pipelines using SQL and Python, ingest data from many sources, run data quality checks and some more stuff, open-source. The goal has been to build a CLI experience that would make humans productive.

After some time, agents popped up, and when we started using them heavily for our own development stuff, it became quite apparent that we might be able to offer similar capabilities for data engineering tasks. Agents can already use CLI tools, and they have the ability to run shell commands, which meant that they could technically use Bruin CLI as well.

Our initial attempts were around building a simple `AGENTS.md` file with a set of instructions on how to use Bruin. It worked fine to a certain extent; however, it came with its own set of problems, primarily around maintenance. Every new feature/flag meant more docs to sync. It also meant the file needed to be distributed somehow to all the users, which would be a manual process.

We then started looking into MCP servers: while they are great to expose remote capabilities, for a CLI tool, it meant that we would have to expose pretty much every command and subcommand we had as new tools. This meant a lot of maintenance work, a lot of duplication, and a large number of tools which bloat the context.

Eventually, we landed on a middle-ground: expose only documentation navigation, not the commands themselves. In that spirit, we ended up with just 3 tools: - `bruin_get_overview` - `bruin_get_docs_tree` - `bruin_get_doc_content`

The agent uses MCP to fetch docs, understand capabilities, and figure out the correct CLI invocation. Then it just runs the actual Bruin CLI in the shell. This means less manual work for us, and making the new features in the CLI automatically available to everyone else.

You can now use Bruin CLI to connect your AI agents, such as Cursor, Claude Code, Codex, or any other agent that supports MCP servers, into your DWH. Given that all of your DWH metadata is in Bruin, your agent will automatically know about all the business metadata necessary.

Here's a quick video of me demoing the tool: https://www.youtube.com/watch?v=604wuKeTP6U

All of this is fully open-source, and you can run it anywhere.

Bruin MCP works out of the box with: - BigQuery - Snowflake - Databricks - Athena - Clickhouse - Synapse - Redshift - Postgres - DuckDB - MySQL

I would love to hear your thoughts and feedback on it, thanks!

https://github.com/bruin-data/bruin

Comments URL: https://news.ycombinator.com/item?id=46060191

Points: 1

# Comments: 1

It seems like such a crowded space and there are many tools doing document extraction, I wonder if there's anything particular pulling more attention into the space?

I would not underestimate any of these players in the space.

On the other hand, I do agree with you that it is quite a big challenge for Fivetran to try and become Snowflake.

I think consolidation in the space has been coming for quite some time now and this merger only confirms what us, along with many others, have been saying: the data tooling is in a miserable state and we had to glue together a bunch of different tools that don't work with each other.

At this point, I think it is quite obvious that Fivetran is going for Snowflake/Databricks's market share. They own the ingestion for many companies already, and they will offer a managed data lake product in order to compete with the data giants. By owning the means of bringing the data in (Fivetran) as well as the transformation layer (dbt/sqlmesh) they will aim to get ahead of Snowflakes of the world.

I think it'll be a win for the data community if they maintain and continue investing into the existing tooling, as they are running in quite a few places already, especially dbt core running in a self-managed way. I certainly hope they won't try to squeeze revenue for the sake of it from their combined users.

It's an interesting time to be in the space, and it feels great to be one of the few independent players in the market.

Comments URL: https://news.ycombinator.com/item?id=45531860

Points: 1

# Comments: 0