Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- For some use cases, and when everyone has access to all the systems, and data volumes allow reasonable perf, I could see this working well.
For things like customer-facing analytics, there needs to be a deployment layer for AI-native artifacts that supports ongoing operations & maintenance. If you want a conversational data agent to answer questions and reduce custom analytics requests, that's more to manage and maintain.
If you watched the Claude Dashboards announcement, they said legacy bi will be the deployment layer for AI artifacts. I don't buy it. Legacy BI was terrible at deployment in the first place.
We've built a performant, browser-native alternative to deploy and scale AI artifacts at Ridge AI (ridgedata.ai).
Fascinating to watch all of this evolve in real time.
by eleanorpd - We replaced Looker with Hex [1], which was 7x cheaper (for our use case). But soon afterwards we built our own in-house data agent platform "Reef", which has now effectively changed how the entire company operates, from sales and customer success, to defining commercial and operational strategy. One of my engineers Samuel has done a small writeup about it [2]. Essentially, if you take care of your ETL and make data modelling a first class citizen, you can build your own BI (or even better - agentic BI) relatively easily.by armcat
- We were paying $40K/year for both salesforce and salesloft. Both got built into a simple app for the sales and SDR team. The new app is way clean and faster than Salesforce. We even hired a consulting agency to setup/manage Salesforce and its reports. That consulting agency is also gone.by chopete3
- I've been working in "genBI" for a few years now and this has been exactly the trajectory. We started by focusing on selling shiny viz with an AI engine to produce it. But now making a fancy chart indeed costs 0.50, except it's going to be the wrong chart with the wrong data that will be read once and lost.
The hard part with all of this is building and maintaining a semantic layer, but more importantly capturing all the prompts and queries users are firing in to make these shiny HTMLs. Since making them is so cheap, what you want to do is capture that usage and convert that into improvements to the actual BI layer (the semantic definitions, the skills and knowledge base files, even the charting engine rules) so you can provide a consistent, correct source of truth for everyone at your company (or anyone relying on you for analytics, even your end users).
The data model underneath all these charts, especially a self-improving one based on processing usage data into quality evals and fine tuned models, is now the key. The charts can be replaced with HTMLs made by Claude for sure.
(Disclosure: I'm the founder of Upsolve so I think about these problems every day)
by serguei - I built something similar in my previous job. The part that we were never able to figure out is how to guarantee that everybody is looking at the right numbers. Even if you have a comprehensive semantic layer, there are still a lot of things that can go wrong in putting metrics on a dashboard. This is why analysts are still needed, IMHO.by alexkbuilds
- Ayeee! We're actively doing this right now at my company. One of the more clever engineers has tackled replacing a $300k/yr Looker subscription, which we've paid for a decade, with a homegrown implementation sponsored by Claude.
And it seems like we're succeeding! To be fair, we weren't making good use of Looker's features and so the problem was easier than expected... but the core idea was validated in a couple of weeks, we've had just one person on the project part-time for a couple of months, and we told Looker (well, Google) we won't be renewing yesterday.
We're just doing a 1:1 conversion to start with the hope that our customers barely notice the change. Afterward, we'll re-envision our dashboards with the new found flexibility of not serving them via iframe.
Crazy times!
by SeanAnderson - Over a decade ago i worked at a company with a BI tool that was exactly this, minus the AI of course. it was just PHP pages backed by embedded SQL built by a non engineer. anytime someone wanted a different slice of data, the person just copied an existing page and swapped out the sql and the column names. URL query string was used for the different parameters of the SQL statement, i forget if it was open to sql injection but it was an internal tool only. even after implementing a BI tool everyone still used the PHP pages because it was faster and easier to just bookmark the specific page you want with the data you wanted.
much like low code tools, most people dont want to mess with self serve BI. AI might help with that but i think the tool in the article opens the door for people creating slightly different versions of the same thing. also, claude is awful at visualizations. every one i see looks the same, crammed full of bad charts and too much text, poor color choices, and no real value in terms of story. still, this is an interesting implementation of that concept.
by phone_book - > A BI tool is mostly a way to turn a query into a picture, and a picture now costs about $0.50 of tokens. It gets hard to justify a $150k licence for that part
That is an awfully simplified view of BI. In my experience, most companies struggle to define what is important, what needs to be measured, and how those measurements should be used to improve business.
While businesses try to work these details out, they try getting their analysts to in the author's words print out good pictures. But the BI tools really exist to make it easy for analysts to navigate hairy internal situations.
Producing a picture or HTML more easily is not going to solve the decisioning problem. If anything it might make it worse.
In the end, it's going to cost a lot more than 50 cents a picture.
by bushido