Vibecoding Analytics: Three Observations on Agentic Analytics

Over the past year, agentic coding went from weird demos to something people actually use to get real work done.

Analytics is starting to go through the same transition.

A few weeks ago, Vincent, our CEO, posted this in our company Slack:

Some context: since we launched our local agentic development tooling, Vincent installed our CLI and started learning his way around the terminal with Claude Code.

Then he shared the consolidated P&L from our accounting software, and asked it to reconcile with the entries we independently pulled into our warehouse.

A few iterations later, the numbers started lining up.

He shared that in the old days, this would have taken a team of at least 3 experts (an analytics engineer, a financial controller, and a bookkeeper) months of back-and-forth.

This time, it took six hours of work.

The hours saved are the obvious part of the story, but not the part I find most interesting.

Here are three things I've been thinking about since. They don't add up to some grand framework, and I don't think they need to. Make of them what you will.

1/ You can't explain agentic analytics to people, they need to actually experience it

No amount of verbal selling beats a real-world session with a well-equipped analytics agent.

We had explained agentic analytics to Vincent before. He understood the idea. But it only really clicked after we released our agentic BI tooling and he tried it himself.

If you struggle to get business users to adopt AI analytics, don't spend too much time explaining it. Give them an agent connected to real data, and a real problem they actually care about.

Don't try to set up perfect governance and context upfront. Give them a reasonably safe environment. Let them try it out, and watch the agent struggle in front of them.

In fact, the struggling is part of the magic.

Ask: "Why did our revenue drop last month?"

Let the agent query something → get an odd result → investigate further → revise its hypothesis → try a different angle → eventually arrive at something useful.

What converts people isn't the final answer. It's watching that back-and-forth loop happen, and realizing: this is more or less how an experienced data analyst would work through the problem too.

Except this time, the loop happens at a much faster pace.

2/ The hidden productivity gain: less coordination overhead

Vincent wrote in his Slack post:

I suspect it would have taken a team of at least 3 experts (AE, Financial Controller, Bookkeeper) months to figure out the logic and reconcile the numbers.

What stood out to me wasn't the three experts. It was the coordination between them.

A discrepancy in the P&L might start as an accounting question.

Then you realize you need to understand how the transaction is represented in the backend. Then you need to inspect the ETL logic. Then perhaps change a data model.

And after all that, you still need to go back and ask: does this number make sense from an accounting perspective?

In a normal organization, every time the problem crosses one of those boundaries, coordination work is required:

Vincent asks finance → finance explains the accounting nuance → someone translates it into a data requirement → an analytics engineer investigates → comes back with questions → finance checks again → repeat.

None of these steps are particularly ridiculous on their own. It's the coordination between them that makes the whole thing slow.

With an agent, many of those boundaries become much cheaper to cross, because the problem doesn't have to be handed off to a new person each time.

Vincent can say: "This number doesn't match Zoho. Figure out why."

The agent can inspect the data, read the existing logic, form a hypothesis, change something, run it again, compare the result, and keep going. When it encounters something it doesn't understand, Vincent supplies a little domain context and the loop continues.

This doesn't mean Vincent suddenly became a financial controller, bookkeeper, and analytics engineer. Those still matter.

He just needs enough judgment to know when something looks wrong, what context the agent is missing, and when to call in an actual expert.

He no longer needs to organize a mini cross-functional project with multiple experts.

The productivity gain isn't only in automating the work. It's in removing much of the coordination needed to move that work across different domains.

3/ When you unlock agentic analytics for business executives, analytics engineering demand will increase (not decrease)

This can be counter-intuitive, but it makes perfect sense.

If executives can increasingly analyze data themselves, shouldn't they need the data team less? From what I'm seeing, the opposite happens: they become much more demanding.

Before, a dashboard effectively capped curiosity: you see revenue = $4.3m, maybe you click a filter, or perhaps break it down by a few dimensions. But eventually, you hit the limits of the tool, or of your own patience.

With an agent, that isn't the same.

"Why did revenue drop?" becomes "which customers drove that?" becomes "was that churn or contraction?" becomes "why are these contracts classified this way?" becomes "wait, are we actually modeling this correctly?"

Every answer generates another question.

And eventually, those questions start hitting the limits of the underlying data: a dataset with something missing, a definition that doesn't quite make sense, or a HubSpot field that hasn't been warehoused.

And suddenly those data foundation problems become painfully concrete.

Previously, requests to fix these things were often backlogged or delayed, hidden underneath a stack of analytics requests. And from the business side, it wasn't always obvious why they mattered.

But when you're personally exploring the data, that same infrastructure problem is no longer an abstract request for the data team. It's the thing standing between you and the next question you want answered.

The easier you make analytics, the more analytics people do. The more analytics they do, the more they demand a better data foundation.

Closing off

This was supposed to be a lightweight welcome-back post, but I've already stretched that.

If there's any conclusion I can leave you with, it's this: the second-order effects of AI are probably much more interesting than the obvious ones.

We tend to imagine AI analytics as a swap: same workflow, same org chart, same requests, just an AI-shaped version of each step. But that isn't what happens at all once business users actually get their hands on an agent.

They'd ask more questions. They'd cross domain boundaries themselves instead of filing a ticket. They'd run into problems in the underlying data; and unlike before, those problems are now their problem, blocking their next question. So they show up at the data team's door genuinely wanting them fixed.

And I suspect this pulls the data team upstream, away from answering questions, toward making the environment reliable and legible enough for both humans and agents to explore.

But that's probably for another post.