Claude Dashboards vs. BI-as-Code: The New Code vs. No-Code War Nobody Asked For
The launch of Claude Dashboards has reignited the oldest fight in the data world, but this time, it’s not just about drag-and-drop versus SQL. It’s about whether the future of analytics belongs to a proprietary, model-integrated interface or to open-source, code-first platforms that you actually own.
On one side, you have Anthropic’s new feature: type a question in plain English, get a live dashboard connected to your warehouse, with the SQL query exposed on every chart. On the other side, you have the rise of BI-as-Code, tools like Evidence, Rill, and dbt Charts that treat analytics as a software engineering problem, versioned in Git and deployed like code.
The spicy take circulating in data circles? Claude Dashboards is the Jupyter Notebooks of the agent age. Great for a quick exploration, impossible to maintain in the long run. Let’s dig into whether that’s fair, or whether the critics are just defending their turf.
What Claude Dashboards Actually Does
Before we get into the war, let’s get the facts straight. Claude Dashboards launched on October 8, 2026, in beta on paid plans. You connect a data platform like BigQuery, Databricks, or Snowflake (or a CRM like Salesforce), ask a question in plain language, and Claude builds a dashboard that stays current as your data changes.
Here’s the design that’s winning over even the skeptics: Claude writes one SQL query per chart, runs it against your warehouse, and shows you that query plus the last refresh time on every chart.
That transparency is a genuine step forward. The hard part of AI-written analytics was never drawing the chart, it was knowing whether “active customers” meant what you think it meant. Putting the SQL on every chart makes each number auditable by anyone who can read a WHERE clause.
Claude Dashboards also plays nice with the existing ecosystem. When a question needs deeper analysis, you can send the dashboard straight to Amplitude, Grafana, Hex, Mixpanel, Omni, Perplexity, PostHog, or Sigma, with Looker, monday.com, and Tableau coming soon.
The Case for the Defense: Why BI-as-Code Wins
Here’s where the controversy starts. The core argument from BI-as-Code advocates isn’t that Claude Dashboards is bad, it’s that it’s another Jupyter Notebook moment.
Jupyter Notebooks are incredible for exploration. They’re terrible for production systems. The same applies here: Claude Dashboards uploads all its code and artifacts to Claude’s servers, including your data. You can’t version it in Git. You can’t deploy it through CI/CD. You can’t review changes in a pull request. You’re locked into the Claude ecosystem with no real path to migrate.
Let’s look at the actual project structure from a hands-on comparison between Rill, Evidence, and Claude:
Rill gives you this:
tree -L 2
.
├── connectors
│ └── duckdb.yaml
├── dashboards
│ ├── campaign_analytics.yaml
│ ├── campaign_impact.yaml
│ ├── list_overlap.yaml
│ ├── lists_subscribers.yaml
│ ├── newsletter_health.yaml
...
├── metrics
│ ├── bounce_events.yaml
│ ├── campaign_impact.yaml
│ ├── campaign_summary.yaml
...
├── models
│ ├── api_campaigns.yaml
│ ├── api_daily_activity.yaml
│ ├── bounce_events.yaml
│ ├── campaign_impact.yaml
...
Evidence gives you this:
├── evidence
│ ├── access.yaml
│ ├── AGENTS.md
│ ├── CLAUDE.md
│ ├── connection.yaml
│ ├── evidence.config.yaml
│ ├── pages
│ ├── queries
│ └── theme.yaml
Claude Dashboards gives you this:
├── dashboard
│ ├── charts.js
│ ├── index.html
│ ├── pages.js
│ └── styles.css
├── export_data.sh
├── README.md
See the difference? The first two are declarative configurations that live in your repository, under your control. The third is HTML and JavaScript living on Anthropic’s servers. And the kicker? The artifacts can’t even be copied locally, they require Claude’s runtime to function.
As one commenter on the r/dataengineering thread put it: “Claude dashboards should be viewed as an agent-driven presentation layer. No business logic or governance should be managed by them.” It’s the perfect summary: great for presenting, terrible for governing.
The developer sentiment is even blunter. A common refrain among those testing it: “Fun on day one, unmaintainable by month two.” When your dashboard is a bunch of HTML that only runs inside Claude, you don’t have a BI platform, you have a fancy screenshot generator.
The Sharing Model: Where It Falls Apart
The part most launch coverage skips is the sharing model. Claude Dashboards has a critical limitation that breaks the “replace-your-BI-tool” narrative:
- Each viewer sees data through their own access. If a viewer doesn’t have warehouse permissions, they get error tiles, not your numbers.
- No public links for connected dashboards. “Anyone with the link” is not allowed for artifacts that connect to your apps. Good for security, but you can’t post a company-wide KPI page.
- Outside collaborators lose connected features entirely. You can invite up to 50 outside people per artifact, but the parts that use Claude or your connectors don’t work for them.
The result? Claude Dashboards is a personal analysis tool that happens to be shareable, not a broadcast reporting system. The people who benefit most are the product manager who would otherwise file a ticket with the data team and wait three days, or the founder who can read SQL but doesn’t want to write it at 11pm.
But if you need a dashboard that a whole company opens from a link, a metric definition that can’t drift, or a scheduled refresh you can promise to leadership, that’s still your BI tool’s job.
The Semantic Layer Gap
Here’s the criticism that’s hardest to dismiss: Claude Dashboards has no semantic layer. Every number comes from SQL Claude wrote for that chart, fresh each time. Two people asking about “churn” can get two different definitions.
Looker exists precisely so “revenue” means one thing everywhere. Claude Dashboards shows its working instead of enforcing a definition, which is fine for one person exploring and riskier for a number a whole company acts on.
This is where the data modeling and documentation gap hurts most. When your metrics live as ephemeral SQL instead of versioned model definitions, you’re building a house of cards.
The powerful counter-argument is that Claude Dashboards will support semantic layers if they’re exposed through a connector. But that’s a “coming soon” promise, not a shipped feature. And in the meantime, the agent is writing fresh SQL every time, which means every “quick question” is a potential definition drift.
The Bigger Trend: Everyone’s Building This
What’s easy to miss in the noise is that Claude Dashboards isn’t an outlier, it’s part of a wave.
OpenAI launched its own Data agent for ChatGPT Work about a month earlier, with similar dashboard-building capabilities. Snowflake has Snowflake Intelligence. Databricks has Genie. All of them are doing the same dance: connecting to your enterprise data, letting you ask natural-language questions, and generating charts with purported “transparency.”
And at the same time, the rise of Power BI Projects (PBIP) shows that even the proprietary giants are moving toward code-first workflows. PBIP stores report and semantic model definitions as human-readable text files, turning a Power BI solution into a codebase that developers can search, version, and review in pull requests. Microsoft isn’t missing the memo, they’re doubling down on “BI-as-Code” as the path forward.
Meanwhile, open-source options from Apache Superset to Metabase to Lightdash (which turns dbt models directly into charts) are proving you can have self-serve analytics without surrendering control.
So Who Wins? It’s Complicated
Here’s the uncomfortable truth: both sides are right, and both sides are missing the point.
Claude Dashboards is genuinely great for the Top of Funnel (TOFU) use case. The person who needs a quick answer, who doesn’t want to file a ticket, who just wants to see this week’s signups compared to last month’s, for them, this is a massive upgrade. Anthropic isn’t pretending this replaces BI. The launch post explicitly says “Dashboards work alongside your BI and analytics tools.”
But the “Jupyter Notebook” comparison sticks because it’s accurate. Jupyter notebooks were never bad, they’re just not production infrastructure. Claude Dashboards will likely follow the same path: an essential tool for exploration and insight, not a replacement for governed, versioned, maintainable BI.
As one of the more cynical observers noted: “I really don’t understand, this is already just a prompt way using python within Claude, why the fuss?” That’s reductive, but it captures the sentiment, for anyone who was already charting CSVs in chat, the difference is the live warehouse connection and the visible SQL, not the charts themselves.
What Should You Do?
If you’re building your data infrastructure today, here’s my field guide:
Use Claude Dashboards for:
- Quick, exploratory questions about your data
- Personalized analysis for non-technical domain experts
- First drafts and PoCs that you’ll throw away
- When you need an answer now and can verify the SQL yourself
Keep your BI tool for:
- Company-wide, governed reporting
- Metrics that need consistent definitions across teams
- Scheduled refreshes and alerts you can promise to leadership
- Anything that outlives the conversation that created it
And if you care about long-term maintainability, invest in open-source BI-as-Code tools that give you the best of both worlds: files you can version, dashboards you can deploy, and semantic layers that keep your metrics honest. Or consider how tools like dbt and modern semantic layers are reshaping data team roles.
The Bottom Line
The war between “let the model do it all” and “write it in code” isn’t going to have a single winner. Claude Dashboards will eat the top of the BI market, the people who never wanted a BI tool in the first place. But the people who’ve been building BI-as-Code platforms didn’t build them because they hate dashboards, they built them because they hate not being able to maintain things.
A decade ago, we argued about no-code versus code. Now it’s proprietary Frontier models versus open-source, code-first tools. The lesson from the last decade? Code-first won. And the tools that survived were the ones that let you own your work.
Claude Dashboards will be a fantastic way to answer a quick question. But if your insights matter enough to act on them, you need to own the thing that produced them.
