Stop Dooming the BI Developer

Read enough of the current commentary and you'd think the BI developer is already standing on the gallows. Cloudflare cut over a thousand roles and its CEO went to the Wall Street Journal to say AI made them obsolete. Vin Vashishta traced a three-phase pattern where the people who produce measurement get cut first. Starburst published a piece titled, more or less, dashboards are the first to go. Databricks has a guide to agentic BI. There's a steady drumbeat of "BI is dead," "BI-ready isn't AI-ready," "the dashboard era is over," each arriving from a different direction and landing on the same anxious note.

When this many independent writers circle the same discomfort at the same time, they're usually right that something is shifting. What almost none of them do is say what to actually do about it. They name the issue and stop. Everyone diagnoses; nobody prescribes. Imagine going to the doctor and a doctor says "yep, looks like you broke your leg." and then leaves. Nothing actually changes and not helpful. My perhaps unpopular opinion: the diagnosis, read correctly, isn't doom at all.

The BI developer role isn't disappearing. It's being pulled closer to the business's actual operational decisions, and that's a good thing. I have been in the data business for 20 years, and I remember being the only person who focused on analytics in an industry full of DBAs and database developers. I have been fortunate in my career to work with several managers who, when providing them with insights or "data driven decisions," the first question they ask is "so what?" This has had a profound impact on me because it forced me to consider something: perhaps the value of a company's data isn't just in showing the dashboard, it is telling people what to do about it. Looking at a dashboard alone means nothing, the value is in taking the story that the data is telling you and then implementing something real and tangible to improve the business operations. The people reading this moment as an execution notice are the ones still measuring their value by dashboards produced and rows landed in a data lake. Measure it by decisions enabled instead, and the picture inverts. The skill that took years to build doesn't become worthless. It becomes load-bearing in a place it wasn't before. Personally, I think this is a great thing. It empowers the BI developer to become impactful in new, tangible ways.

Enterprises have spent a decade collecting everything on the theory that storage is cheap and someday it'll be useful. Much of it has never been used for anything. If data is sitting in a lake serving no decision and no action, the honest question isn't how to govern it better. It's why it's there at all. Collection was never the point. Reports were never the point. They were proxies for the actual goal, which was helping the business decide and act. We built elaborate machinery for the proxy and quietly lost track of the target.

Reports are very good at one thing, and it pays to be precise about what that thing is. They look backward. They tell you what inventory was, what revenue did, how churn trended. For historical understanding, for pattern-finding, for the quarterly narrative, a well-built report is still the right tool and will be for a long time. The problem is not that reports are bad. The problem is that a genuinely AI-driven business doesn't primarily run on what happened last week. It runs on what's happening right now. And that single shift, from backward-looking to up-to-the-minute, is what reorganizes the entire role.

As organizations have been optimizing for historical reporting, the evolution can unfold into a four-phase arc, and most organizations are still only even focused on the first one.

The first phase is conversational AI. Someone connects a language model to the existing semantic layer, and suddenly people can ask questions in plain English instead of opening a dashboard. This feels like magic for a few weeks. It's also the easiest phase, because it sits directly on top of the BI work already done. The definitions, the governed metrics, the modeling discipline, all of it carries straight over. This is where ontologies and a well-formed semantic layer earn their keep, because they're what give the model the context to answer correctly instead of merely plausibly. There's a wave of writing right now about how AI needs "context" to be trustworthy. Saurabh Gupta at The Modern Data Company put it well: available isn't the same as understandable, and context can no longer live in documentation or in someone's head, it has to be embedded with the data itself, because a model gets none of the tribal knowledge an analyst walks in with. He's right. What tends to get lost in these pieces, though, is that this is not a new discipline. It is exactly what semantic modeling has always been.

When I used to teach data classes, I'd write a single number on the whiteboard. 79. No label, no nothing. I'd ask the room what it meant, and of course nobody could say, because it meant nothing. Then I'd add one word: date. Then another: product category. By the time a couple of dimensions were up there, that lonely 79 had become 79 units of a product category sold on a given day, and suddenly it meant something. That is context, applied to a raw fact. It's the work BI developers have been doing for as long as the role has existed. The tools have new names and the consumer is a model now instead of a person, but the discipline is the one you already own. If you built the semantic layer, you built the foundation this phase stands on.

It's also where the first uncomfortable question surfaces. Every vendor and every framework claims to have solved trustworthy answers, but the benchmarks for what "trustworthy" even means are informal at best, closer to anecdote than measurement. Which leaves the practitioner holding the only question that matters: can you actually trust what the system just told you? That question never fully goes away. The later phases only make it harder.

Dylan Anderson in his recent article "The Context Moat AI needs" flags the risk himself: context goes stale, and a context layer is only useful if it stays true to how the business operates. He's right, but I'd argue there are two ways for context to stop being true. The first is the one he means, a definition quietly drifting from what the business actually does, which you fix with governance and version control. The second is quieter and harder to catch. The definition is perfectly correct, the meaning is exactly right, and the number is still wrong, because it reflects last night's reality instead of this morning's.

That second kind of staleness is phase two, when someone asks the model a question about right now and gets an answer that's stale. Someone asks the model about right now and gets an answer that's precise, confident, and out of date. Why does it say we have four hundred units when the floor says we're nearly out? The honest answer is that the model is reading a semantic layer fed by a pipeline that refreshes overnight. The conversational interface didn't create a freshness problem. It exposed one that was always there, hidden by the fact that nobody expected a dashboard to be current to the minute. The moment you put a conversation in front of the data, the latency you'd tolerated for years becomes the whole conversation.

The third phase is realizing that the freshness problem is really a state problem, and that it's an engineering problem, not a settings toggle. Getting a system to know what's true right now, rather than what was true at the last refresh, means modeling the business as a stream of events instead of a nightly snapshot. An order placed, a threshold crossed, a customer churning as it happens. As we all know, this isn't a simple swap. You are talking about re-architecting entire portions of the business to be event-driven and be notified in real-time when things change, however historically this required an entirely different type of developer. Kafka, AMQP, MQTT, Event Hubs, etc.

The fourth phase is the one everyone is racing toward and almost nobody is ready for. We can barely surface phase one, and phase four without phases two or three is like having someone hand you a scoop of ice cream with no cup or cone. It just melts into a sticky mess. It's agentic action, an agent that doesn't just answer but does something: reorders the stock, adjusts the price, flags the account, opens the case. And here is the part the hype skips and is really getting under my skin right now: an agent cannot responsibly act on state it can't see. Before an agent handles anything, it has to know what's happening in the moment, not as of last night's dashboard refresh. The heavy engineering that phase three demanded isn't a detour on the way to agents, it's a prerequisite. Skip it and you get an agent acting confidently on yesterday's reality, which is worse than no agent at all. That's the same effect as an agent hallucinating. Imagine the fallout when an agent re-orders product because the system that was updated last night said we were out, missing the fact that someone already placed a reorder this morning and we now have double the inventory.

So the question that replaces "should I learn AI" is more useful and more concrete: which operational decisions in your business actually matter enough to wire up? Not all of them do. The art is picking the ones where acting in the moment changes the outcome and acting a day late doesn't. Which reports are fine the way they are?

Take unmanaged inventory. A report tells you on Monday that a SKU ran out on Saturday, by which point the sales are already lost. The operational version knows the stock is crossing its reorder point right now and triggers the reorder before the shelf empties. Same underlying data, same person who understands it, aimed one layer earlier. Sounds an awful lot like the "shift left" leaders are always talking about. Take churn: a dashboard flags an at-risk cohort at month end. The operational version catches the account whose usage just fell off a cliff this week, while intervention still means something. The judgment about what "at risk" means is identical. Only the timing changed, and the timing is the entire value. These aren't exotic examples. They're the ordinary work of the business, moved from hindsight to the present tense.

To a good analyst, none of these are huge leaps. You already know what "active customer" means and why the APAC definition differs. You already know which threshold matters and what should happen when it's crossed. You already do root-cause analysis when a number looks wrong. You are, in other words, already doing this work. You're just doing it informally, in your head, after the fact, one investigation at a time. The shift being asked of you is to make it systemic, to encode the judgment you already exercise into systems that can see the current state and act on it. That's an extension of what you know, not a replacement for it. Decisions that you make, might I add, in real time.

I'm not going to pretend the how is trivial, or that one essay resolves it. Over the coming months this publication will dig into exactly that, not just why the role is changing but how to elevate yourself inside the change: what event-driven modeling actually asks of a BI person, how to ground a semantic layer for action rather than interpretation, how to instrument a decision so you can see why an agent did what it did. For now, the reframe is enough to change what you do Monday morning. Stop asking whether you should learn AI. Start asking which decision in your business is still being made a day late, and what it would take to make it in the present.