Do You Still Need to Learn Power BI Fundamentals Now AI Can Build the Model?

I offered some time to an organisation recently, something I love doing with many, because whether we end up working together or not, I get to meet some great people and see how different organisations operate. I was genuinely excited about this one, as I knew in advance the team was using AI tools to build their Power BI reports and dashboards.

The conversations were good and when they walked me through the semantic model it looked the part. Facts, dimensions, a proper date table, some role playing dimensions, measures organised into folders, different tabs in model view all purposely built. On the surface, one of the better models I have looked at in the last few months.

Then I started asking questions and the gaps started to appear.

AI can build a Power BI model faster than any of us - no doubt. It cannot tell you whether that model is right. That still needs a person who knows the fundamentals.

Summary

Using AI to build Power BI solutions is a good thing and I do not want anyone to read this as an argument against it. Really, it's NOT! However, the problem is using it blindly and worse, deciding you no longer need to learn data modelling, DAX, SQL or data warehouse concepts "because AI can do it".

A model that looks right and a model that is right can be identical on screen. The fundamentals are how you tell them apart.

Key takeaways:

• A star schema that looks correct is not evidence that it is correct. Grain, filter behaviour and history are where models break and none of them are visible from the model view.
• Checking a measure against a known grand total is not enough. A measure can hit the company total and still be wrong for every customer, product and month underneath it.
• AI does not remove the need for understanding Kimball, DAX or SQL fundamentals. It raises the cost of not having them or knowing them, because there is more output to check.
• The value of an experienced developer is shifting from writing to reviewing. You cannot review what you do not understand.

The AI-built model that looked right

So, three questions were enough. I have changed the details here to keep the organisation private, but the pattern is exactly what I found.

First, I asked what the grain of the sales fact was. The answer was "one row per row in the extract". Fair enough, so I asked what a row in the extract was. It turned out the source extract mixed line-level transactions with daily totals for some product groups and the fact table had inherited that mix. Nobody had asked the question, so nobody had noticed.

Second, I picked one of the revenue measures and asked why it removed the filter on the customer table. The answer, and I am paraphrasing only slightly, was "the AI wrote it, the total matched the finance report, so we kept it". The total matched because the customer slicer did nothing. Every customer showed the same revenue... the company total. That measure had been sitting in the model for months.

Third, I asked what happens to last year's sales when a customer moves region. Silence!! The customer dimension was a straight overwrite, so history quietly moved with the customer every time a region changed. Not wrong, exactly, but never decided or thought about either.

Here's the thing. Nobody in that team was lazy. They had built something that looked right and they had no way of telling whether it was right or aligned to the correct principles. That second part is what stayed with me.

The belief that AI can build it all

The second experience is the one that explains the first.

Over the last year I also have had a few conversations with other BI developers and analysts and to be fair to them, the ones I spoke to have fewer years in the field than me. More than one of them was adamant that you no longer need to know your Kimball or the fundamentals of DAX or SQL or how a data warehouse hangs together, Power Query or even Git and Azure DevOps for version control. The reasoning was always the same. AI can do it... it can architect it, design it and engineer it.

I get why it is tempting, but to me... this is shocking! Ask an LLM to design a star schema from a set of source tables and it will give you one in seconds and it will look real good. Ask it for a DAX formula and it will write one that returns a number. If you have never had to work out a grain by hand, derive a business event from stakeholders and help them flesh the details out or debug a measure's filter context at midnight, that output that's provided looks like the finished product.

But that belief is exactly how you end up as the team in the assessment. Not because AI wrote bad DAX (some of it was fine), but because nobody in the room could ask the next question and promote the best practices it should have been following.

Fundamentals matter more with AI, not less

So, this part really answers the title of the blog. I have also written before about why the semantic model matters more in the age of AI, and this is the human side of the same argument.

Let me be clear about something first. AI cannot do this on its own, no matter how good the prompt is. Data modelling is a business exercise before it is a technical one. You sit with the people who run the process, you understand it in detail, you understand the business, what happens, when, at what level and which stakeholders care about it, technical and non-technical, and the model comes out of that understanding. Kimball (and others) built entire methodologies around this. AI can turn that understanding into tables and measures very quickly, but it was never in the room, and it does not know what the business actually does. Somebody still has to. I made a similar point a while back when I wrote about whether AI will replace report developers, that getting closer to the business and working with them more directly is how you stay relevant. I believe that even more now than I did then.

When a BI developer writes a measure, the review happens while they write it. They think about grain, about filter context, about what the visual is going to do with the result - they even drag it on to the canvas to see what it actually evaluates which prompts them to think harder. When AI writes it, that thinking has to happen afterwards, in the review. So the job of the experienced developer is moving from writing code to checking it, and more so in bulk, which is more difficult I am finding the more I use AI. Power BI reports are turning into code now (TMDL, PBIP files in Git) and that only makes the review bigger.

You cannot review a fact table if you cannot say what its grain should be. You cannot review a measure if you do not understand what CALCULATE does to the filter context. You cannot review a dimension if you have never thought about what should happen to history when an attribute changes. The data modelling fundamentals are not the bit AI replaces... they are the bit that lets you use AI safely.

In addition, I always tell my clients the same thing about governance, that AI amplifies whatever is already there. The same is true of skills. Give AI to a developer who knows the fundamentals and they get faster and more valuable to the business. I have written about how we do this ourselves, ten years of report patterns written down once as AI skills, and the point is in the title. The patterns came first, the AI applies them. Give it to a developer who does not know the fundamentals and they get confident, which is far more dangerous.

Some questions I ask first when reviewing an AI-built Power BI model

If you are reviewing a model, AI-built or not, these are some practical questions I start with. None of them need a tool.

• What is the grain of each fact table, in one plain sentence and which business process does it represent? Why I ask: grain is the one decision everything else depends on. If the answer starts with "one row per row in the source" it means nobody decided, the source did. A fact table that cannot be described as a business event (a sale, an order line, a stock count) is a copy of an extract, not a model.
• For the most used measures, why is each CALCULATE there? Why I ask: every ALL, REMOVEFILTERS and KEEPFILTERS changes what a slicer does to the number. Remove each one and watch what moves. If nobody can say why it is there, it is there because something looked wrong once and this made it look right.
• Filter the report down to one customer and one month (or whatever is relevant in your model). Does every measure change and do the parts add up to the total you trust? Why I ask: matching the grand total proves very little. A measure can hit the company total and be wrong for every customer underneath it, which is exactly what I found. The levels below the total are where the mistakes hide.
• What happens to history when a customer, product or employee changes an attribute? Why I ask: this is the slowly changing dimension question and it is almost never asked because the model works either way. It just silently rewrites last year. I want to know whether the behaviour was decided or whether it just happened.
• Why does a relationship exist and what breaks if you change its direction or cardinality? Why I ask: bi-directional relationships and many-to-many are where AI-generated models quietly go wrong, because they make a visual work without anyone understanding the cost. If the team cannot explain a relationship, they cannot defend the numbers that flow through it.

If the team cannot answer these, the problem is not the AI. The problem is that nobody can check the AI.

That is a training problem and an honest one. Most of the developers I meet who lean on AI too hard were never given the chance to learn the foundations properly in the first place. At Metis BI we run Power BI training courses built around exactly this, modelling, DAX and the questions above, for teams who want to use AI with confidence rather than on faith. Learn more about our training services.

Summary

I am not asking anyone to stop using AI to build Power BI solutions. I use it, and I would be daft not to. I have written about Power BI MCP and Power BI agent skills because I think they genuinely change how we work. What I am asking is that you do not let it replace the learning. If you are trying to decide whether the fundamentals are still worth your time, my honest advice is yes, more than ever. A model that looks right and a model that is right can be identical on screen, and the only way to tell them apart is to know what to ask.

AI can write the model. Knowing the fundamentals is how you check it.