PBIR: Power BI Just Became a Code-First Tool — Is This the Future?

Every visual in a Power BI report is now a separate JSON file. Every page. Every chart. Every KPI card. With a published schema. This isn’t a rumor or a beta experiment — Microsoft is rolling it out as the default. And I think most people in the Power BI community haven’t realized yet what this actually means.

The format is called PBIR — the Power BI Enhanced Report Format. It sits inside PBIP (Power BI Project) files, and as of early 2026, it’s becoming the default for all new reports. Microsoft has been rolling this out quietly — they posted the announcement back in December 2025 — but I don’t think the implications have sunk in for most people yet.

Power BI is no longer a GUI-only tool. And that changes everything.

I’ve been spending the past few weeks playing around with this — building Claude skills that understand the PBIR JSON structure inside PBIP projects, generating report pages from prompts, and seeing how far this can actually go. I want to share what I’ve found so far, what works, what’s still rough, and why I think this might fundamentally change how we develop Power BI reports.

What Changed: From One Massive File to a Folder of Small Ones

Here’s the core shift. Under the legacy format, an entire Power BI report lived in a single report.json file. If you’ve ever opened one, you know the pain — thousands of lines, deeply nested, impossible to diff meaningfully in Git. Editing by hand was risky. Collaboration meant merge conflicts. It was a format designed for machines, not developers.

PBIR takes a fundamentally different approach. Inside a PBIP project, it splits the report into a structured folder hierarchy where every component gets its own file:

MyReport.Report/
  definition/
    report.json              ← Report-level settings
    pages/
      pg01SalesDashboard/
        page.json            ← Page layout and settings
        visuals/
          v01KpiRevenue/
            visual.json      ← Individual visual definition
          v02BarChart/
            visual.json
          v03LineChart/
            visual.json

Each visual in the PBIR format gets its own folder and JSON file. Each file conforms to a published JSON schema on Microsoft’s GitHub, which means editors like VS Code can validate the structure in real time. You can even use the Power BI Developer Mode alongside your PBIP projects for a proper development workflow.

This is the kind of developer experience Power BI never had before. And honestly? It caught me off guard how well it works.

How to Enable PBIR: Service vs. Desktop

A few people have asked me what “PBIR default” actually means in practice — and how you enable it. So let me break it down clearly, because the Service and Desktop work differently here.

Power BI Service (January 2026)

Starting late January 2026 (fully rolled out by end of February), all new reports created in the Power BI Service automatically use PBIR. There’s an admin tenant setting that controls this: “Automatically convert and store reports in the Power BI enhanced metadata format (PBIR)”. If your admin hasn’t disabled it, it’s already on.

Power BI Desktop (March 2026)

Desktop follows with the March 2026 release. Until then, you can already opt in manually: go to File → Options and settings → Options → Preview features and check “Store reports using enhanced metadata format (PBIR)”. Once the March release ships, this becomes the default for all new PBIP projects.

What About Existing Reports?

Existing reports get automatically converted to PBIR when you edit and save them. You don’t need to do anything — the conversion happens on save. One important detail: PBIR lives inside PBIP project files, not regular .pbix files. You need Developer Mode enabled in Desktop, or work through Fabric Git integration, to see and work with the PBIR folder structure directly.

Why This Matters: Power BI as a Code-First Tool

The moment PBIR report definitions inside PBIP projects become structured text files with schemas, everything shifts. Practices that software developers take for granted — version control, code review, automated testing, CI/CD pipelines — suddenly apply to Power BI reports. This isn’t an afterthought. It’s how the format is designed to work.

Here’s what becomes possible with PBIR and PBIP:

• Git-based version control. Every change to every visual is a meaningful diff. Pull requests for report changes become practical. Microsoft has official documentation on Git integration with PBIP.
• Batch operations. Need to update conditional formatting across 200 visuals? Write a script that edits the PBIR JSON files directly. No more clicking through the Power BI UI one visual at a time.
• Template systems. Define a standard page layout once, generate it repeatedly with different data bindings. I’ve been doing exactly this with Claude skills — and it works.
• Automated quality checks. Lint PBIR report definitions for consistency, missing alt text, non-standard formatting, or unused visuals.
• CI/CD deployment. Microsoft’s fabric-cicd Python library already supports deploying PBIP files to Fabric workspaces programmatically.
• AI-powered generation with Claude skills. Because the PBIR schema is public, Claude skills can write valid visual definitions from natural language prompts. More on this below — it’s what I’m most excited about.

These aren’t theoretical capabilities. They work today. I’ve tested most of them.

Claude Skills + PBIR: Generating Entire Report Pages from a Prompt

This is where it gets really interesting — and where I’ve been spending most of my time experimenting.

Because PBIR follows a documented schema, AI tools can generate valid Power BI report definitions from natural language descriptions. I’ve been working with Claude Code and building custom Claude skills to work with PBIR files directly.

A Claude skill is a reusable instruction set that gives Claude deep expertise in a specific domain. Think of it as a playbook. I built one — the PBIR Report Builder skill — that understands the PBIP folder structure, the PBIR schema versions, the naming conventions, and the visual container format. When I describe a dashboard — say, four KPI cards at the top, a clustered bar chart below, a line chart for trends — the Claude skill generates all the JSON files needed for that page inside the PBIP project.

No Power BI Desktop involved. Claude writes the PBIR JSON. Power BI renders it.

I want to be honest: none of this is finished. It’s all work in progress. The Claude skill I built generates valid PBIR JSON maybe 85–90% of the time on the first try. Edge cases exist — particularly around interaction configurations, mobile layouts, and some of the more obscure visual properties. But the 85% that works? It saves hours.

Real Example: IBCS Visuals in Power BI Without Paid Add-Ons

Let me give you a concrete example of what Claude skills and PBIR look like in practice, because I think it demonstrates the potential better than any abstract description.

The International Business Communication Standards (IBCS) define specific visual patterns for showing actual vs. plan comparisons — integrated variance bars, percentage deviations, specific color coding (black for actual, gray for plan, green/red for variances). These are widely used in European financial reporting, especially in Germany and Austria.

Normally, you’d need commercial add-on visuals for IBCS in Power BI — paid per-user licenses that aren’t cheap at scale.

With PBIR and a dedicated Claude skill, I’ve been generating IBCS-compliant variance charts using only native Power BI visuals — combo charts with calculated columns, SVG-based conditional formatting, and specific DAX measures that the skill generates automatically. The Claude skill takes your actual measure, your comparison measure, and your category column, then produces all the helper DAX and the complete PBIR visual JSON configuration inside your PBIP project.

To give you a sense of the complexity: a single IBCS column variance chart requires 15 helper DAX measures — things like reference line positions for relative variance percentages, error bar bounds, data label positioning, axis calculations. If you try to build this manually for the first time, you’re easily looking at 30 minutes or more just for one visual — and that’s if you already know which settings to look for. Finding the right properties in Power BI’s formatting pane is not easy. The Claude skill generates all of it in seconds.

No paid licenses. No third-party dependencies. Just native visuals configured in a way that would take half an hour to set up manually — generated in seconds by a Claude skill. That’s the kind of time saving that adds up fast when you’re building reports for clients.

I’m sharing this Claude skill for free. It’s still evolving, but it works. The skill is open source on GitHub — and I’ve written a detailed walkthrough of the PBIR Report Builder skill if you want to see exactly how it works.

Two Layers of AI in Power BI — And They Don’t Depend on Each Other

One thing that confused me initially — and I think confuses a lot of people — is how the different AI tools for Power BI relate to each other. So let me clarify something important about working with PBIR and PBIP.

Power BI AI automation has two distinct layers, and they work independently:

They complement each other beautifully. Use the MCP Server to create measures and optimize the data model. Use Claude skills with PBIR to build the report visuals inside your PBIP project. But each stands completely on its own. I use them together, but you don’t have to.

What I Built: The PBIR Report Builder Claude Skill

I’ve built a Claude skill called the PBIR Report Builder. It’s a detailed instruction set that teaches Claude how to work with the PBIP folder structure and generate valid PBIR JSON files.

Here’s what’s inside the skill:

• 5 reference documents covering the PBIR format, PBIP folder structure, and naming conventions
• 12 JSON templates for different PBIR visual types (KPI cards, bar charts, line charts, tables, and more)
• 7 JSON schemas for validation (visualContainer v2.0.0, page v2.0.0, report v1.3.0)
• Naming conventions: pg##ShortName for pages, v##TypeDesc for visuals (max 50 chars, must match folder name in the PBIP project)

When you use the Claude skill, you describe what you want in natural language — “create a sales dashboard with 4 KPI cards showing revenue, margin, units, and returns, then a bar chart by region and a trend line by month” — and it generates the complete PBIP folder structure with all the PBIR JSON files.

I’m sharing this Claude skill for free — grab it on GitHub. It’s still a work in progress, but it gives you a clear picture of how to work with PBIR inside PBIP projects and what this AI-powered workflow actually looks like. I’ve also written a step-by-step walkthrough showing how the skill generates IBCS visuals from just three inputs.

Limitations and What’s Still Rough

I want to be upfront about what doesn’t work yet. This is an honest assessment, not a sales pitch.

• PBIR is still in preview. Microsoft plans General Availability for Q3 2026. Schema versions may evolve, and I’ve already hit cases where certain PBIR schema versions return 404 errors (v4.0.0 and v1.5.0, specifically).
• Not everything is documented. Some PBIR visual properties I’ve discovered through experimentation, not through official docs. The published schemas are good, but they don’t cover every edge case.
• Claude skills need iteration. The Claude skill generates valid PBIR JSON most of the time, but edge cases exist — particularly around interaction configurations, mobile layouts, and some matrix visual settings. Expect to iterate.
• The workflow is developer-oriented. Business users who never touch files or code won’t interact with PBIR or PBIP directly. This is a tool for Power BI developers, consultants, and anyone comfortable with JSON.
• File paths with spaces cause issues. If your PBIP project folders contain spaces (common on Windows), some tools choke on them. I’ve had to write helper scripts as workarounds.

None of this is finished. I’m learning as I go, and I’ll keep sharing what I find — including the things that break.

Are Claude Skills and PBIR the Future of Power BI Development?

I think a significant part of Power BI development is going to shift toward code-first workflows using PBIR and PBIP. Not because the GUI is going away — it isn’t. But because the tasks that take the most time in Power BI development aren’t the creative decisions. They’re the repetitive implementation: applying the same formatting to dozens of visuals, ensuring consistency across pages, maintaining standards across reports, setting up yet another KPI card with the exact same conditional formatting.

That’s exactly what code-first approaches — and AI-assisted generation through Claude skills — are good at.

The combination of PBIR, PBIP project files, the Power BI MCP Server, and AI tools like Claude Code with custom Claude skills creates a development environment that simply didn’t exist a year ago. Reports as code. Models as code. Full version control. AI-assisted generation from Claude skills.

It’s the kind of shift that changes how jobs are done. Not overnight, but steadily.

I’m not claiming to have all the answers here. I’m a Power BI consultant who’s been playing around with Claude skills and PBIR, finding that the possibilities are hard to ignore. Some of this might not pan out. Some of it already works better than I expected. The only way to find out is to keep experimenting — and keep sharing what I learn along the way.

Frequently Asked Questions