Between Fabcon announcements, continued improvement in AI, and Kurt Buhler's video of what's possible today, I've been seeing a lot of anxiety and concern on here. So, I wanted to write a blog post about exactly how "dead" I think Power BI is and what we can do about it.

https://www.sqlgene.com/2026/10/04/mourning-the-alleged-death-of-the-power-bi-developer-and-thriving-in-uncertain-times/

Summary

I think that the Power BI report layer is becoming "dead" in the same way that SSRS "died". Over time there was slowly a decrease in community resources and Microsoft investments as newer and shinier things came along. On the other hand, there was a huge, huge backlog of existing reports that will take a very long time to migrate, if ever.

I think the Power BI modeling layer is strong and vibrant. FabCon announcements showed growing investment in semantic models in how they relate to ontologies and eventually semantic views, etc. DAX and semantic models are not going away any time soon.

Right now is a time of high volatility, similar to when Azure was new, and you should become a generalist instead of putting all of your eggs in one basket. Power BI alone is no longer a career.

Where to invest your time

1. Invest in accountability. Low-stakes reporting will likely be supplemented, supported, and replaced with AI. Aim for regulated or sensitive reporting where people get pissed if you are off by a penny.
2. Invest in gut, instinct, and self-expression. Right now, today, if you see a model with a bunch of many-to-many relationships and bi-directional filtering, little alarm bells go off. Focus on continuing to grow and develop those instincts. Learn how to put those things into words. Get better at judging and explaining, so you can steer and monitor AI better.
3. Practice weekly with AI, especially where it sucks. My personal experience with AI, especially in the past 6 months, is that there is a jagged frontier of capabilities and that frontier shifts day by day. Every week you should be asking AI for the impossible because sometimes frontier models have huge jumps in capability.
4. Invest in Vega-lite, Vega and possibly D3.js. Vega-lite is supported in Power BI Deneb visuals today, Fabric Apps today, and a native Vega visual is coming to PBI in 2027 Q1.
5. Invest in data modeling, data engineering, and requirements gathering. Spend your time getting better at areas where the business is unique and that you have to talk to humans to define how the business works and how to model it.

Again, same logic as I used in Flappy Bird, Custom Visuals + PBIP+ Claude code, This is just V1.0, so many things to improve,

Issue I am facing

1- Cannot look and fire both using the mouse we can use either of them. The mouse is only used for looking and aiming, shooting and scoping use other keyboard hotkeys

AI Summarization of what i did -

I built a playable CS-style FPS inside Power BI as a custom visual (three.js + PBIP). Here's what the visual sandbox does and doesn't allow

I wanted to embed a browser Counter-Strike trainer in a report. That's a dead end: the site sends X-Frame-Options: DENY / frame-ancestors 'none', so no HTML or web-content visual can show it. So I rebuilt it as a custom visual.

Stack

• .pbiviz in TypeScript + three.js (WebGL), about 650 KB, embedded in the PBIP under CustomVisuals/ with a resourcePackages entry, so the report opens with nothing to import
• Everything is procedural (canvas textures, WebAudio gunshots), so the visual needs no network access (privileges: [])
• Aim range, a spray lab that scores recoil control in cm, and a bot duel where bots peek and shoot back. WASD movement with CS-style moving inaccuracy

The data part

• Weapons are rows in the model. Damage, RPM, magazine and armour pen are bound measures that drive the gameplay (e.g. whether an AK headshot one-taps a helmet)
• A slicer on weapon class changes your loadout. Equipping a weapon cross-filters the native cards and charts through selectionManager
• Best scores persist into visual.json via persistProperties

What the sandbox won't let you do
Third-party visuals get sandbox="allow-scripts" and nothing else. I checked Desktop's own JS: pointer lock isn't even among the permissions it can grant. So real mouse-look is impossible. Workaround: drag to look (pointer capture keeps turning past the visual's edge), F to fire, and a tap to fire as a fallback.

Gotchas

• The pbiviz linter rejects Math.random and innerHTML, so I used a seeded PRNG and DOM APIs
• Desktop caches bundles by GUID + version. Bump the version and reopen; a reload isn't enough
• A custom theme's name must include .json and match its resource item, or validation fails

I tested everything in headless Chrome, with a stub host inside an allow-scripts-only iframe, before opening Desktop.

Again, if you want tutorial, let me know. not getting time and motivation to edit video, if this became #1 post today, i will make it

Disclosure first: I build Power BI custom visuals, and this is about one I made (Zentrix Network Graph). No link in the post. Happy to share it in the comments if anyone wants it.

A question I kept running into while researching relationship data in Power BI: what do you do when a hierarchy isn't really a tree? A company owned by two parent companies, shareholdings split across owners, someone with a dotted-line manager. Hierarchy visuals assume one parent per node, so the second link has nowhere to go.

The underlying problem is that this data is a graph that's mostly a tree. If you're stuck with a one-parent visual, one workaround is to pick a primary parent per row in Power Query and put the second relationship in a tooltip. That works, but the second link is invisible unless you hover.

What I did in the network graph:

- Force layout draws every relationship from just a source and a target column, so you see the network as it actually is.

- Tree layout picks one structural parent per node, so it still reads top-down. Every extra parent is still drawn, as a lighter curved dashed line.

- If you have a parent column you can bind it. If not, it works the hierarchy out from the links: the most connected node becomes the root, then breadth-first from there. Same data gives the same layout every refresh.

- Hovering a node lights up all of its links and lists them in the hover card.

Where it's not a great fit: if most nodes have several parents, it isn't really a hierarchy any more, and the force layout will read better than forcing a tree.

Curious how others model this. Do you keep a "primary parent" column, or a separate bridge table for the extra relationships?