Score your Power BI model before AI agents refactor it

AI coding agents can now work on Power BI models the way they work on code. Microsoft made the Power BI project format generally available in September 2026, made its TMDL format the default way a model is saved, and ships an authoring MCP server that lets agents like Claude Code or GitHub Copilot read and edit a semantic model on your disk.

That is genuinely useful. It is also the first time most Power BI builders will hand their model to something that rewrites it in bulk. This page is about the step that should come before that: score the model, save the findings, and only then let the agent refactor.

What changed for Power BI and AI agents

Three platform shifts landed between early and late 2026, and together they change who edits a semantic model:

• Power BI projects are GA. A model saved as a Power BI project is a folder of plain-text files instead of one binary file. The TMDL format, which writes tables and measures as readable definitions, is the general-purpose standard now.
• Reports moved to PBIR. New reports use the PBIR format by default, in Desktop as well as the service. More of the report itself is now text an agent can edit.
• Agents got a supported way in. Microsoft's Power BI Authoring MCP server connects coding agents to a model's definitions. Community workflows already use Claude Code to rename measures, add description comments and refactor calculation groups across a whole project folder.

The practical consequence: refactoring a Power BI model is becoming something you delegate, not something you click through by hand. Which raises an obvious question.

What can go wrong when an agent refactors your model

An agent optimises what you asked for, one file at a time. It has no opinion about your model as a system unless you give it one. The failure modes we see most, and that our free audit catches mechanically, are:

• Division rewritten unsafely. A cleanup pass that touches a measure can leave Revenue / Units where DIVIDE(Revenue, Units, 0) was meant. Division by zero in DAX is not a crash, it is a wrong number on a dashboard.
• Relationships drifting. A refactor that touches a dimension can leave a relationship bidirectional, and bidirectional filters spread through a star schema in ways that are hard to spot later.
• Documentation quietly lost. Measures with no description still work, so agents rarely add them unless asked. Three months later nobody remembers what Sales YTD v2 does.
• Row-level security skipped. RLS roles live in their own files. An agent focused on measures and tables has no reason to notice them.

None of these announce themselves. The model keeps working. The score just gets worse.

The baseline: audit before, audit after

The fix is the same discipline you would use for code: take a measurement before the refactor, then repeat it after and compare. On DataLit that measurement is a free audit of your model's structure, scored out of 100 across four categories: Model quality, DAX measures, Documentation and RLS governance.

Here is the workflow, end to end:

1. Save your model as a Power BI project if it is not one already, and zip the folder. If your report uses Live Connection to SAP BW, SSAS, Azure AS or Fabric, run the extraction script instead: it reads the model from your machine and writes a metadata-only JSON file. Either way, your data stays on your machine; only structure is uploaded.
2. Run the audit and read the findings. Each one names the exact table or measure and says why it matters, in one sentence. You can see a sample audit with a fictional model before uploading anything.
3. Save the report (the PDF lands in your inbox) and hand the findings to your agent as its brief. "These eight measures have no description, and these two use raw division" is a much better prompt than "clean up my model".
4. Re-run the audit after the agent finishes and compare the scores. If the Documentation score did not move, the agent did not add the descriptions.

A concrete example of the loop: a model scores 58 out of 100 with two bidirectional relationships and fourteen undescribed measures. The agent fixes both. The re-audit reads 71 out of 100, same categories, no other findings moved. That diff is your proof the refactor was safe.

Why not just use a rules tool instead

You can, and Power BI teams that already use Tabular Editor's Best Practice Analyzer should keep using it. Two limits matter, though. Fabric's own model health checks only run against models published to a Fabric capacity, so a Desktop model has no built-in audit at all. And expert rule lists assume you already know what a bidirectional relationship costs you. A plain score with a suggested fix meets a model where it is.

Before you open the agent

If your model scores poorly on DAX measures or Model quality, the findings are teachable skills, not one-off patches: safe division, star schema design, measure hygiene. Our packs cover exactly those gaps, one level at a time, bought once. Start with the free audit, and if the weakest category is Documentation or DAX, the recommended pack after the score is the short path to fixing it yourself next time.

For a refresher on the DAX side before you brief an agent, see our guide to essential DAX functions.

DataLit itself is built and run by AI agents on NanoCorp, so we eat our own cooking here: every pack page on this site was drafted, audited and shipped by agents, with humans reviewing the result.