# BI as Code: Picking Data Viz Tools When an Agent Writes the Code *Last updated September 2026. This is a living landscape: the tools and my picks will shift.* Most BI tool comparisons still score features: connectors, drill-downs, scheduling, seat price. That lens made sense when a person clicked every chart together. It makes a lot less sense now that a coding agent (Claude Code, Cursor, pick your favorite) writes most of the dashboard and a person reviews it. When the agent does the typing, the question changes. Not "which tool has the most features" but "which tool does the agent write correctly on the first try, and how much of the output can I actually audit?" This post is the landscape I keep for that question: four buckets of tools, then what I actually build client dashboards with and why. My stack assumption throughout is Fivetran + MotherDuck + dbt + Claude Code, with DuckDB for local work. If you run Snowflake and Cursor, swap the nouns. The reasoning holds. --- ## What "AI fit" actually means Three things predict whether an agent will produce a good dashboard in a given tool: 1. **A closed grammar.** Tools with a bounded, declarative spec (YAML, JSON, SQL plus Markdown) give the agent fewer ways to be wrong and give you a diff you can read. Open-ended JavaScript is the opposite. 2. **Public examples.** Agents are strongest in tools with years of documentation and public code behind them. A tool released last week is only usable if it ships its own instructions for agents, which the newest entrants now do. 3. **Review burden.** Every line the agent writes is a line you own. A 40-line YAML file is a two-minute review. A 400-line React component is not. Whether the artifact lives in git matters too. The whole point of BI as code is that a dashboard change is a pull request, reviewed and versioned next to the dbt models it depends on. --- ## Bucket 1: BI as code The primary lane. The output is usually a static site or a single binary, and the file conventions are simple enough that an agent learns the pattern after seeing two examples. | Tool | What it is | AI fit | Use when | |------|-----------|--------|----------| | **Evidence** | SQL + Markdown pages with declarative chart components. Static deploy, dbt-native. | Excellent. Closed grammar, years of public examples. | Internal and throwaway reports only. Still the fastest path from SQL to a readable report, but demoted from client-facing work at atalbo: the design ceiling is low and you fight the framework to brand it. | | **dbt Charts** | dbt Labs' new declarative dashboard framework: YAML plus SQL, version-controlled next to your models. Announced at dbt Summit on September 16, 2026. Public beta, pre-1.0. | Predicted A. Built for agents (it ships an MCP server and its own agent skill) but too new to have training data behind it. | You already run dbt and want charts governed in the same repo and pull request as the models. | | **Rill** | Single-binary BI defined in YAML. DuckDB-native and very fast. | Strong. YAML is what agents handle best. | Local-first exploration over DuckDB pipelines. | | **Lightdash** | BI built on top of dbt. Metrics, charts, and dashboards are now YAML in git, with a CLI, an MCP server, and skills for Claude Code and Cursor. | Predicted A, for the same reason as dbt Charts. | A dbt shop that wants self-serve exploration for business users plus code-defined dashboards. | | **Observable Framework** | Static site generator for data apps: Markdown, JS, SQL, Python, and R on one page. | Strong but JS-heavy, so the review burden is higher. | You want more design freedom than Evidence and can review JavaScript. | | **Quarto** | Posit's polyglot publishing engine. | Good. Markdown plus code chunks is a well-worn pattern. | Report over dashboard: long-form analysis with embedded computation. | | **Hashboard** | BI as code with a real metrics layer. Acquired by Hex in 2025. | Good. | You need a metrics layer, versioning, and AI in one product. | A note on dbt Charts, since it is the one people are asking about. A board is a single YAML file: variables (filters), queries (SQL with Jinja, and `ref()` works against your dbt project), charts (16 core types), and a layout grid. The `dct` CLI validates a board, serves a live preview, and renders to HTML, PDF, or PNG. DuckDB is built in, the other warehouses come through dbt adapters, and on MotherDuck a single `dbt build` can publish the boards as Dives with live refresh. The tagline is "easy for agents to write, easy for humans to audit," which is exactly the lens above. It is in beta and the GitHub repo is a read-only mirror of a private upstream, so treat it as promising rather than proven. It is also the first serious contender for the slot Evidence held: SQL to a governed report, fast. --- ## Bucket 2: Python data app frameworks For one-off analyses, internal tools, and anywhere a real app is overkill but a static report won't do. | Tool | What it is | AI fit | Use when | |------|-----------|--------|----------| | **Marimo** | Reactive Python notebooks stored as plain `.py` files, so they diff cleanly. | Excellent. Designed for AI generation from the start. | Reactive analyses, and anywhere Streamlit is tempting but you want better git hygiene. | | **Streamlit** | The default Python data app framework. Snowflake-owned. | Excellent. Years of public examples. | Quick internal tools, Snowflake-native apps, ML demos. | | **Hex** | Proprietary notebook plus app platform with strong dbt integration and a genuinely good built-in agent. | Native. | Your stakeholders will compare against it, so know it. I don't build client deliverables on it because of the lock-in. | | **Vizro** | McKinsey's open-source dashboard toolkit: multi-page dashboards from a few lines of YAML, JSON, or Python config, with an MCP server. | Predicted A. Config-driven and agent-ready. | Python shops that want Dash-quality output without writing Dash. | | **Plotly Dash** | The older Python-to-React framework. Heavier and more capable. | Good but verbose. | You've outgrown Streamlit and need real state management. | | **Shiny for Python** | Posit's port of R Shiny. | Decent. | Posit shops and people coming from R. | Solara, Reflex, and Gradio exist too. Exploratory only, or ML demos in Gradio's case. --- ## Bucket 3: Charting primitives This is the bucket that matters most when you spin up a custom prototype with an agent. Agents write best in libraries with stable, declarative, well-documented APIs. | Library | AI fit | Use when | |---------|--------|----------| | **Recharts** | Excellent. Claude's default for React. | Anything React-based. Part of my client dashboard standard. | | **Observable Plot** | Excellent. Closed API, lots of examples. The cleanest charting grammar available. | Any JS chart where you don't need full D3 control. | | **Vega-Lite** | Exceptional. Pure JSON specs. | Chart specs that get passed between systems. (dbt Charts boards become Vega-Lite on MotherDuck, for instance.) | | **Tremor** | Excellent. Composable React + Tailwind components. | Custom internal tools in React. | | **ECharts** | Good. | Complex enterprise dashboards and geo work. | | **D3** | Decent, and overkill. | Bespoke, non-standard visuals only. | Also worth knowing: Chart.js, Plotly.js, Highcharts, visx, Nivo. --- ## Bucket 4: Agent-first BI The newest category, where AI generation is the product rather than a feature. Most are pre-product. Track them, don't invest yet. - **Evidence Studio:** Evidence's hosted agent that builds reports and runs ad-hoc analysis. - **Hex's agent:** the most mature agent-in-BI product, and the bar for how this should feel. - **Prefab (Prefect):** a generative UI framework, Python DSL to JSON to a shadcn-based React renderer, built for agents to emit UIs on the fly. Not a warehouse BI tool: no dbt or DuckDB connectors, no auth, no static deploy story. Worth a weekend prototype for agent-generated UI, not for client BI. - **Incumbents bolting on agents:** ThoughtSpot Spotter, Sigma AI, Tableau Pulse, Power BI Copilot, Omni. This is where your stakeholders are evaluating from, so know the pitch even if you'd never build on them. --- ## What I actually build client dashboards with The client dashboard question is settled for atalbo: a custom React app. Next.js + shadcn/ui + Recharts + TanStack Table, querying MotherDuck live from the server with a short cache, behind a login, deployed once per client. I started on Evidence, and Evidence is still the fastest way from SQL to a report. What moved me off it was the ceiling. Evidence output reads as "generic BI report," and you fight the framework to brand it. For a consultancy the dashboard is the visible deliverable, so polish is part of the product. Two builds settled it: an operational lead desk for a construction client, where the custom app handled the filter, sort, search, and export work Evidence isn't built for, and a report-shaped intelligence dashboard for an aviation client, which proved the same stack does the classic BI shape just as well. Three things make the stack work with an agent doing most of the typing: **One stack, one design system.** Claude Code writes shadcn, Recharts, and TanStack at S-tier, and every hour spent deepening the pattern compounds across clients. **Live data, not baked data.** The dashboard queries the warehouse server-side and caches the result. A nightly job runs `dbt build` and busts the cache. Client data never lands in the git repo or the static bundle, only behind an authenticated server call. That is a security choice as much as an engineering one. **The trade, stated plainly.** I gave up Evidence's authoring speed for design control and a reusable starter, and I accepted a cached warehouse hit per refresh for zero client data at rest in the repo. Evidence stays in the box for internal and throwaway analysis. dbt Charts is the one I'm watching for that slot. If it ships a hosted, authenticated deploy story and leaves beta, it becomes the obvious answer for dbt-native clients who want charts in the same pull request as the models. --- ## Where the tools rank for agent productivity | Tier | Tools | |------|-------| | **S** (the agent writes it near-perfectly) | Evidence (internal only), Vega-Lite, Observable Plot, Recharts, Marimo, Streamlit | | **A** (strong with one example, or with the tool's own agent skill loaded) | Quarto, Rill, Tremor, ECharts, Dash, dbt Charts, Lightdash, Vizro | | **B** (workable, needs guidance) | Hashboard, Shiny, Solara | | **C** (possible but verbose) | D3, raw HTML and Canvas | The A-tier newcomers (dbt Charts, Lightdash, Vizro) are predictions. They ship agent skills and MCP servers, which stands in for training data, but I haven't run a client build on any of them yet. When you prompt an agent to build a viz in any of these, the context that helps most is short: the tool name and version, one working reference file from the same project, a sample row or schema, and who the audience is. When in doubt, start with an S-tier tool and a single reference file in the repo. --- ## Key Takeaway Stop scoring BI tools by feature count. Score them by how well an agent writes them and how easily a human audits the result: closed grammar, public examples, small diffs, everything in git. For a client-facing deliverable, a custom React stack wins on design control and keeps client data out of the repo. For fast, governed reports next to your dbt models, dbt Charts is the new tool to watch. --- [[Talks & Thoughts|Back to Writing]]