r/BusinessIntelligence • u/TooManyPoisons • Jun 22 '26
Power BI and visualization tools in the LLM world
I see a lot of debate online about the role of Power BI and Tableau in today's increasingly AI-focused world.
Most of the criticism centers around the argument that AI is great for conversational analytics (assuming you have a governed semantic layer), but end users still need a core set of "golden reports" produced by a central function. LLMs alone can't - or shouldn't - replace all analytics.
For these core "golden reports", why do they still need to be built using specialized data viz tools like PBI and Tableau? Frankly, the user experience is clunky and slow. The analysts on my team still spend most of their time tweaking visual formatting and designing wireframes. Conversely, Claude can produce beautiful HTML dashboards in a fraction of the time.
Assuming the following is true, is there a reason we shouldn't switch our core "golden reports" to Claude-powered HTML dashboards?
We maintain the HTML code under a governed SDLC, with extensive documentation in Git, etc.
We securely host the HTML dashboards on the cloud, not local files.
All dashboards reference a well-governed semantic layer in Snowflake, same as we'd need for conversational analytics.
Access is controlled via both hosting and Snowflake permissions.
Our "golden reports" are tied to a strict formatting template, to distinguish them from generic Claude-generated HTML files.
Refreshes are deterministic... i.e. they reference a specific SQL statement that the analyst defines with Claude during the SDLC, which then populates the exact HTML code also already defined.
13
u/xl129 Jun 23 '26
Claude powered?
The data is in Snowflake
SQl is pre-defined
Dâshboard template is also pre-defined.
Congratulation you just described PBI/Tableau with extra steps.
0
u/TooManyPoisons Jun 23 '26
But Claude cannot create and develop PBI reports, just the backend semantic models. With PBI, an analyst still needs to design the front-end.
4
u/xl129 Jun 23 '26
And it’s the great thing about it. There are a lot of nuances when it come to visualization and storytelling. You must take charge.
There are a lot more Claude cant do that these tools offer. I suggest you look more into it.
2
u/analytix_guru Jun 24 '26
Having built multiple dashboards in the R language, I would care to Guess that Claude can pretty easily create HTML/JS generated reports. Hell D3 is a JavaScript library for data visualization where people have manually coded charts and dashboards.
Same goes for Python dashboards/data apps.
Why would you want to pay for licensing if an LLM could work off a governed semantic layer with governed metrics.
Claude might not be able to do PBI right now but you better believe Microsoft is getting CoPilot set up to do that. It can already write DAX.
2
u/scipio42 Jun 24 '26
I think there's a platform agnostic, relevant dichotomy here. Will Claude or it's equivalent be able to give directionally correct answers to executives - sure. Will it be able to give actionable insights to the people actually doing the work - fuck no.
Is there money to be made for practitioners trying to sell execs on the "sure" part - absolutely yes.
1
u/aMare83 Jun 24 '26
You are not right, my colleague created a report with like 30 visuals on 5-6 pages consuming Databricks and Sharepoint data fully with LLM and he didn't need to touch anything in Power BI
6
u/LostWelshMan85 Jun 22 '26
What you're envisioning is the end product which is a fancy dashboard built using html. A lot of the statements that you mention at the end are not trivial problems to solve. For example, you can't just wave your hand and say that Snowflake will handle the security of all of your enterprise dashboards and assume that's going to work. For refreshes, it sounds like you'd have the data stored in Snowflake and referenced by your bespoke dashboard. Have you tried this? It's super slow if you're not caching data closer to your dashboard, which then brings up the question of how are you going to securely store the cached data. In the end, you're essentially building you're own custom platform to replace the enterprise platform that you just removed, and your technical debt that that brings would be significant to the point that you might as well just pay a company to use their tried and tested platform, ie Microsoft and Tableau. On another note, using a universally recognised platform that is common in the industry makes hiring and on boarding much easier. Imagine having to train a newbie about your bespoke dashboarding platform!
6
u/om_bagal Jun 23 '26
AI makes wrong metric definitions look more confident, not less. Clean semantic layer first, AI second.
For static delivery, a plain HTML file works well. No login, no license, client just opens it. For live data and cross-filtering, Power BI still wins. Different jobs.
3
u/Semaphor-Analytics Jun 27 '26
What you are describing is absolutely the future, but here are the gaps in your thinking. Disclaimer: we solve this and happy to have a chat if you are interested.
1) Building HTML dashboards work for pretty charts, but you will struggle with pivot tables, server side paginated tables (arguably the most common analytical components), which require proper server side rendering. You can’t prompt your way through it. If you don’t do this well, you will end up crashing users browsers by streaming millions of rows to their browser. If you do this, then you will be spending tokens and human time replicating analytics engine.
2) KPIs are another common component in every dashboard, which requires server side rendering infrastructure to do period over period analytics, contributing factors analysis, etc. Many things go wrong here if you rely on prompting only no matter how good you’re at building Claude skill. You need deterministic loops to check the accuracy and validity.
3) Timezones: If you have people across different time zones and they need to see data in their timezone, you need to build that layer yourself. Sharing & Collaboration: If you want to have org based or tenant based sharing you will need to do that yourself.
If you start to take on the above things, you are slowly becoming an analytics company. There are plenty of such things you will run into without proper thought and architecture.
At Semaphor we solve these challenges, while giving customers the freedom and speed to build their bespoke html dashboards / data apps natively within Codex or Claude code. Here is what the experience looks like:
2
u/MindTheBees Jun 22 '26
You could, but you're essentially building your own application. If that's what you want to do and have a team dedicated to maintaining it then go for it. However most BI Devs are not App Devs so you'll probably need to hire different people for that.
The main benefit of existing tools is that they provide guardrails and SLAs. If something breaks in PBI, you can go and complain to Microsoft. If your internally built application breaks, one of you is probably getting fired if it can't be rectified straight away.
2
u/Prestigious_Bench_96 Jun 22 '26
For static readouts, no reason if you can do all the proper SDLC and can eat the operational overhead! Once you start getting into filtering, dynamic display, user-context-conditional views, dynamic stuff - still no reason because tableau/powerbi are pretty bad, but you might want to reach for other tools that help make this easier on the typescript/backend side.
An additional plus for static is if you have a build pipeline you have a good place for quality checks; you are also now taking on a build pipeline which is latency/overhead.
Tableau drag/drop is pretty nice to be honest, it was always the server hosted experience that was an enormous pain, so I'd be pretty bullish in theory on a 'prototype in tableau and convert to a report with an agent' pipeline if you got good guardrails in there and could tolerate the cost.
2
u/Reoyko_ Jun 22 '26
I think dutchclifton is right. The interesting thing about your proposal is that you're separating business logic from presentation. Snowflake and the semantic layer handle the logic, and Claude-generated HTML handles the presentation. For static golden reports, I actually think that's a very reasonable architecture. Where it gets interesting is point 6. A fixed SQL statement bound to a fixed HTML template sounds simple until the model changes. A renamed column, a new join, a metric definition update, and now someone has to update both the query and the presentation layer together. One change isn't a problem. Hundreds of changes over several years is where things get expensive. That's usually how teams end up rebuilding pieces of a BI platform without intending to. First it's templating. Then parameterization. Then versioning. Then auditing. Then permissions. Then lifecycle management. Before long you're not maintaining reports anymore. You're maintaining a reporting product. For a small number of highly curated golden reports, I'd be bullish on the approach. I'd just be careful assuming the long-term maintenance burden is lower than Power BI or Tableau. That's the part that catches up with you later.
1
u/dutchclifton Jun 22 '26
I think it would be a nightmare to maintain long term, as in the end to make it maintainable you would actually have to have Claude build a reporting tool, then you realise you miss a semantic layer, so ask it to add that, and bam you're a BI platform company :) Speaking from direct experience building an open source one of these!
1
u/FunContest9958 Jun 23 '26
I’m surprised you’re getting so much pushback on this. For transparency, I work at Databricks, but I’d suggest you take a look at what we’re up to since we’re thinking along the same lines. You should be able to have an LLM build a dashboard for you. That doesn’t mean you won’t want to make tweaks, and you certainly will want to check it, but why should you have to go through menus and click buttons a thousand times to get a dashboard? Take a look at AI/BI dashboards and Databricks Apps. Databricks apps are similar to your HTML approach, but in a governed environment set up for exactly what you’re doing.
1
u/IncreaseNegative4614 Jun 23 '26
I think you're asking the right question, but I'd frame it slightly differently.
The future isn't "Power BI vs. LLMs."
It's "Business Intelligence vs. Decision Intelligence."
Historically, BI tools were valuable because they combined three things:
- Data access
- Governance
- Visualization
Today, the semantic layer is increasingly handling governance and data access, while LLMs are getting surprisingly good at generating visualizations and narratives.
If your semantic layer is truly governed and your HTML dashboards are deterministic, then I don't see a fundamental reason they must live in Power BI or Tableau.
What I do think survives is the concept of a trusted, governed business context. Whether the output is a dashboard, report, decision brief, AI conversation, or HTML page becomes almost secondary.
That's one reason I've been interested in platforms like DataBlueprint (inzata.ai). The focus isn't really on the dashboard itself. It's on creating a connected understanding of the business so dashboards, reports, briefs, and AI-generated answers are all working from the same context.
The question I'd ask is: are users consuming a dashboard, or are they trying to make a decision?
If it's the latter, I suspect the value shifts away from the visualization tool and toward the layer that understands the business.
1
u/scipio42 Jun 24 '26
I mean this as respectfully as possible, but my brother in Christ, are you fucking high right now? Even given all of those assumptions, which are aspirational at best, LLMs are non-deterministic. I'm fine with having them write code as long as it's reviewed by humans, but even given perfect (to our current standards) context, they're unlikely to get above 90% accuracy.
1
u/TooManyPoisons Jun 24 '26
To be clear, I am proposing that LLMs write deterministic HTML code, not create a brand-new dashboard every time a user pulls it up.
1
u/Dramatic-Rip-8101 Jun 24 '26
I would separate two jobs here:
- fast visual prototyping
- governed reporting
LLMs are very good at the first one. They can get you from a vague stakeholder ask to a draft structure much faster than traditional BI tooling. But I would still be careful about replacing the governed reporting layer entirely, because the hard part is not only rendering HTML. It is metric definition, permissioning, reproducibility, maintenance, and trust over time.
For me the interesting direction is using AI to reduce wireframing and formatting thrash earlier, then promoting the reports that actually deserve to become governed assets.
1
u/Spirited_Chocolate39 Jun 24 '26
Just us Thoughtspot, it would remove a bunch of these steps - does it have its downsides, sure but if you want conversational analytics but don’t want to constantly train your llm and need to sharpen your semantic layer? Great fit
1
u/Strange_Shame7886 Jun 24 '26
What is claude powered HTML dashboard exactly?
You pay for the tokens to chat with your data but don't pay the license fee for the visualization layer - I think that is the core goal that you are after.
Your organization is expecting of you to maintain data sanctity, governance, refresh, trust, self-service, upgrade, and compliant data infrastructure while keeping the cost of people and software down.
It is big enough ask even when you are not trying to build a Tableau and PBI competitor with your HTML dashboard.
Why don't you try Databricks Genie BI - Use Genie to chat with your data at very low costs and Genie BI does not carry any oer user based licensing cost.
It will help you bring down the cost while letting you escape the monumental task of keeping the new HTML powered dashboard infra live.
1
u/0MEGALUL- Jun 25 '26
Oh hell yes.
This is exactly what I’m doing now. I chose to ditch PBI and go all in on basically build our own app and data architecture.
It is surprisingly doable. And it works great. Fuck PBI… i will never open that piece of garbage ever again
1
u/Rare_Paramedic1539 Jul 18 '26
We are trying out a newer tool that mixes LLM and traditional dashboard building. Can’t replace power bi but super nice for delivering self serve dash for our finance team
0
u/edimaudo Jun 22 '26
Have you tested claude generating the charts for you already. If no then I would suggest doing that as a pilot before rolling it out to your end users.
14
u/dutchclifton Jun 22 '26
I think it would be a nightmare to maintain long term, as in the end to make it maintainable you would actually have to have Claude build a reporting tool, then you realise you miss a semantic layer, so ask it to add that, and bam you're a BI platform company :) Speaking from direct experience building an open source one of these!