Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

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

Points: 3

# Comments: 0

I really like that you did this in Go, and I'll definitely dig a bit more into the source code to see how you tackled the CDC stuff, given that there is not many reliable CDC libraries in Go, and there are quite a few gotchas when it comes to doing CDC right. We also hand-rolled ours in ingestr, or I must say clanker-rolled, and we got quite a few things wrong in the first place.

Curious about the postgres-compatible query option: what's the usecase you have in mind there? My perception is that any org that would use Iceberg also has one or a few query engines in place, is this more for debugging stuff?

Quite cool stuff, keep it up!

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: 119

# 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