AI omnipotence and the end of traditional BI

Last month I tried to make what should have been a simple change to the Fabi website. We were rebranding a feature, which meant updating the name and surrounding copy across a bunch of pages. Our website lives on a popular website builder and hosting platform: drag-and-drop editor, nice templates, some code access if you want it. It works fine for building pages. But for a coordinated edit across an entire site? I couldn't find a way to pull the code down locally, make the changes, and push it back. I searched for an embedded AI that could help. After a lot of Googling, asking ChatGPT and Claude, and digging through Reddit: nothing. The platform's AI features existed, but they could do a handful of specific things, none of which were what I needed.

I spent hours manually combing through the website and CMS, page by page, making edits by hand.

The frustrating part is that I'd already done this exact task, on our documentation, in about 30 minutes.

Our docs are hosted on Mintlify, a code-first documentation platform. It's just JSON and markdown files that I edit locally. When the same feature rebrand came up, I pointed Claude Code at the docs repo. It found every mention of the feature and replaced it. It made subtle but important modifications to surrounding copy, even in places where the feature name wasn't used explicitly but the context needed updating. It understood the intent, not just the string match. And while I was at it, I took the opportunity to make some broader styling and branding updates I'd been putting off. Changes that would have taken forever manually but were trivial with AI operating on the actual source files.

Then I tried to do the same on the website, and hit a wall.

For a moment, I'd imagined AI could do more than just the rename: adjust styling, tweak layouts, update components. But the website builder's AI couldn't even make a bulk copy change, let alone touch design. And I realized: this is exactly how it feels to work with old-school BI.

The divide is no longer subtle

The important thing about Claude Code is not that it edits code, or that it runs locally. It's that it can make any change. It's omnipotent within the codebase. It can rename a variable across 50 files, refactor a component, rewrite copy, change a color scheme, restructure navigation. Whatever you need. The scope of what it can do is limited only by what's possible in the code itself.

A drag-and-drop platform with an AI assistant can't do that. The AI is constrained to operate within the platform's framework. It can help you pick a font, maybe suggest a layout, generate some copy for a text block. But it can't make arbitrary changes. It can't understand your full site and make coordinated edits across it. It's AI operating within a box.

The difference between these two approaches used to feel minor. Before AI, the gap between a code editor and a visual builder was mostly about control vs. convenience. Power users preferred code. Everyone else preferred drag-and-drop. Both could get the job done.

AI has blown that gap wide open. When you pair AI with a code-first environment, you get something approaching omnipotence. Fast, accurate, unbounded. When you pair AI with a constrained visual environment, you get a slightly smarter version of the same constraints. The ceiling hasn't moved.

What does this have to do with AI and BI?

Everything.

When I talk to people who are fans of legacy BI platforms (Looker, Tableau, Power BI, Sigma, ThoughtSpot, Omni) I hear variations of the same arguments: "We need the semantic layer so we can manage all our metric definitions in one place." "It has hundreds of powerful custom visualizations." "The drag-and-drop query builder lets business users explore data without writing code."

These are real features that solved real problems. But they were built to solve problems that existed in a pre-AI world. And if you take a step back, you start to see that the assumptions behind them are eroding fast.

Semantic layers exist because changing a metric definition used to mean finding and updating every query, dashboard, and report that referenced it. That's a legitimate nightmare in a world where humans manage all that manually. Looker's entire value proposition was built around this: define your metrics once in LookML, and every report stays consistent. But AI can rewrite hundreds of queries in seconds if you change a table name or metric definition, and it's really great at using context now! I'm not saying that's necessarily the right approach for every situation, but the point is that massive coordinated changes that used to be impossible are now routine. The same problem LookML was designed to solve is now solvable in a fundamentally different, more flexible way with significantly lower overhead.

Custom visualization libraries exist because building a chart from scratch used to require a developer. So BI platforms pre-built hundreds of chart types with dropdown configurations: pick your chart, select your axes, choose your colors. Tableau built an empire on this: an enormous library of visualizations that you configure through a visual interface. It works, but it's bounded by what the platform anticipated you'd need. AI generates fully custom charts, on brand, styled however you want, faster than you can drag fields into a config panel. And unlike a pre-built library, it's not limited to what someone designed in advance.

Drag-and-drop query builders exist because SQL was a barrier. If your marketing lead couldn't write SQL, they needed a visual interface to explore data. Power BI, Sigma, ThoughtSpot: all built around the idea that the right abstraction layer can make data accessible to non-technical users. But AI eliminates that barrier more completely than any query builder ever could. You describe what you want in plain English. The AI writes the SQL, runs it, and shows you the results. No fields to drag. No joins to configure. No learning curve.

Each of these features was a valid solution to a real constraint. But the constraint has changed. And when the underlying constraint disappears, the solution built around it becomes overhead, not value.

A concrete example of where AI Business Intelligence outshines legacy BI

Here's a scenario that makes the difference tangible. Imagine your company renames a product line. "Enterprise" is now "Business." In a legacy BI platform like Looker, that's a project. Someone needs to go through the LookML model and update dimension labels, measure descriptions, and dashboard titles. Then check every saved Look and dashboard that references the old name: titles, filter values, descriptions, text tiles. Then update any scheduled reports that mention it. Then check Explores for hardcoded references. Depending on how deeply the old name is embedded, this could easily be a week of careful, tedious work.

In a code-first, AI-native platform, you describe the change: "We've renamed our Enterprise plan to Business. Update all references: queries, chart titles, filter labels, report descriptions. Flag anything ambiguous for my review." The AI scans the full codebase, makes the coordinated changes, and surfaces edge cases for you to confirm. Not a week. Not a day. A conversation.

This isn't a hypothetical. This is the same thing I experienced with our docs vs. our website. The task was identical. The tools determined whether it took 30 minutes or an entire day. And in BI, where the codebase is larger and the interconnections are denser, the delta is even bigger.

Why legacy BI can't just "add AI"

This is the part that's easy to underestimate. Every legacy BI vendor is shipping AI features. Looker has Gemini integration. Tableau has Einstein Copilot. Power BI has Copilot. ThoughtSpot has Sage. They're all adding natural language interfaces, AI assistants, automated summaries. On the surface, it looks like the gap is closing.

It's not.

It's exactly the website builder problem. The AI can help you within the boundaries of what the platform allows. It can suggest a chart type from the pre-built library. It can auto-fill a query builder. It can summarize a dashboard. But it can't break out of the framework. It can't generate a visualization type that doesn't exist in the library. It can't restructure how your metrics are defined if the semantic layer's architecture doesn't support it. It can't do something the platform wasn't designed to do.

Code-first platforms don't have this constraint. When AI operates on code (SQL, Python, configuration files) the scope of what it can do is limited only by what code can express. Which is to say, it's not really limited at all.

This is why legacy BI can't just catch up by adding AI features. The issue isn't that they lack AI. The issue is that their architecture constrains what AI can do. That's not a feature gap you close with a product update. It's a fundamental design difference.

And here's what makes this urgent: AI capabilities are improving on a steep curve. Every new model release, every capability improvement, disproportionately benefits the unconstrained approach. If the gap feels meaningful now, think about where it'll be in 12 months. In 24. The platforms with architectural ceilings aren't just behind. They're falling further behind with every advance, because the advances can't fully reach their users.

The governance question

The strongest argument for legacy BI is governance. Looker's LookML, Tableau's data policies, Power BI's row-level security. These platforms have years of enterprise trust built around controlled access, consistent metrics, and audit trails. That's real, and it matters.

But governance is a solvable problem. It's a set of features (access controls, audit logs, metric validation, approval workflows) that can be built into any platform. Architecture is not. You can add governance to a code-first platform. You can't add architectural freedom to a constrained one.

The teams I talk to who resist AI-native platforms usually aren't arguing that the AI isn't better. They're arguing that they can't give up governance. That's a false tradeoff, and it's going to become increasingly obvious as AI-native platforms, like Fabi, mature their governance layers while legacy platforms continue to struggle with their AI ceilings.

What this means if you're choosing a BI tool today

If you're on a legacy BI platform, this doesn't mean you need to rip it out tomorrow. Dashboards still load. Reports still run. But the gap between what's possible on a constrained platform and what's possible on a code-first, AI-native platform is widening every month. And it's accelerating, because every improvement to foundation models benefits one side far more than the other.

If you're buying BI for the first time, maybe you're an early-stage company or a team that's been getting by with spreadsheets, you have an enormous advantage right now. You're starting with a clean slate. You don't have years of dashboards built on Looker or Tableau that you'd need to migrate. You can go straight to the paradigm that's winning. Or perhaps you're a larger enterprise that's been using legacy BI for years, and you're looking to modernize your analytics stack. There's no better time to do it than now. You simply have to start with one use case and one team at a time.

And if you're evaluating platforms, the question to ask isn't "does this tool have AI?" They all have AI now. The question is: what can the AI actually do? Can it make any change you'd want to make? Or can it only operate within a predefined set of actions that the platform anticipated?

The thesis behind Fabi is that the future of BI looks a lot more like Mintlify plus Claude Code than it looks like a website builder. A code-first foundation where AI understands the full context and can make any change, not a constrained platform where AI is limited to doing pre-approved things slightly faster.

We're not rebuilding everything legacy BI has. We're not building hundreds of pre-configured chart types you select from a dropdown. We're not rebuilding semantic layers based on YAML files that make you want to pull your hair out. We're building a platform where AI is omnipotent within your data. Where changing your brand colors across every chart is a single prompt. Where fixing queries to use a new table you hadn't anticipated is a few prompts and some supervision.

The teams adopting this approach are pulling ahead. And the distance between the two paradigms is going to keep growing, because the technology driving the change is still accelerating.

This is the most exciting time for Business Intelligence in the past 20 years. The technology is finally catching up to the vision.