Power BI, PBIP, and Agentic Development: A New Way of Working

Power BI has changed a lot over the years.

What started for many people as a fairly visual reporting tool has steadily become a much more complete development platform. It is no longer just about dragging fields onto a canvas, building a few measures, and publishing a dashboard. The modern Power BI workflow now sits much closer to software engineering, data modelling, source control, automation, and structured deployment.

Recently, I’ve been spending more time exploring that shift properly.

Not just using Power BI Desktop in the traditional way, but looking at how Power BI development can work when you combine PBIP files, version control, structured model design, AI-assisted coding, and agentic development tools like Codex.

The result is a very different way of working.

It feels less like building a one-off report and more like developing a proper data product.

Power BI has grown up

For a long time, Power BI development was mostly centred around Power BI Desktop. You opened a PBIX file, made your changes, tested the report, and published it.

That workflow still works, and for many scenarios it is perfectly fine.

But as reporting environments become more complex, the traditional PBIX-only workflow starts to show its limits. It can be harder to manage changes, compare versions, collaborate with others, reuse patterns, or automate parts of the development process.

The introduction of Power BI Project files, or PBIP, has been a major step forward.

PBIP changes the way you can think about Power BI development. Instead of one single packaged file, the report and semantic model are broken out into a project structure that can be opened, inspected, edited, and tracked more like code.

That might not sound exciting to everyone, but from a development point of view, it is a big deal.

It means Power BI work can start to follow more mature practices:

• source control

• code review

• reusable templates

• structured refactoring

• repeatable deployment patterns

• better separation between model, report, and data logic
  

For anyone building Power BI solutions regularly, this opens the door to a much more scalable way of working.

Agentic development changes the workflow

The most interesting part for me has been combining PBIP with agentic development.

By agentic development, I mean using AI tools not just to answer questions, but to actively help with development tasks. That could include reviewing project files, suggesting changes, generating documentation, refactoring model logic, creating repeatable patterns, or helping reason through how a report should be rebuilt.

This is different from simply asking an AI tool to write a DAX measure.

The real value is in giving the agent enough context to understand the structure of the project, the goal of the report, the shape of the data model, and the development standards you want to follow.

Then it can help with the work in a more practical way.

For example, instead of manually working through every part of a Power BI model, you can start to use an agent to help:

• inspect the project structure

• identify report dependencies

• review measures and model objects

• suggest cleaner naming conventions

• document the semantic model

• generate SQL view requirements

• propose a cleaner star schema

• support migration from one datasource to another

• create repeatable development checklists
  

This does not remove the need for Power BI knowledge. If anything, it makes that knowledge more important.

You still need to understand data modelling, DAX, relationships, performance, report design, and business context. The agent can help accelerate the work, but it needs direction. It needs judgement. It needs someone who knows what “good” looks like.

That is where the BI developer’s role starts to shift.

Less manual clicking. More architecture, review, orchestration, and quality control.

The Power BI Desktop Bridge is another important piece

One of the more recent things I’ve been working through is the Power BI Desktop Bridge approach.

This is another example of how the Power BI development workflow is evolving.

The idea is that you can still use Power BI Desktop where it makes sense, but you are no longer limited to only working manually inside the Desktop interface. You can bridge the gap between the familiar visual development experience and a more code-driven, project-based workflow.

That matters because most Power BI developers still need Desktop.

It is still the best place to visually check the report, validate interactions, inspect the model, test measures, and make sure the user experience actually works.

But when you combine Desktop with PBIP, source control, external editing, and AI-assisted development, the workflow becomes much more powerful.

You can move between:

• visual report development in Power BI Desktop

• project-level inspection through PBIP

• code-assisted changes in an editor

• AI-assisted refactoring and documentation

• structured deployment and version control
  

That bridge is important because it means this way of working does not require throwing away the Power BI Desktop experience. It enhances it.

For me, that is the key point.

The future Power BI workflow is not necessarily “Desktop versus code”. It is both.

Desktop gives you the visual design and validation experience. PBIP and agentic development give you structure, repeatability, and scale.

From report building to data product development

The biggest mindset shift is moving away from thinking about Power BI as just report building.

A report is only the final layer.

Underneath that, there is a lot that determines whether the solution will be reliable, scalable, and easy to maintain:

• the data source strategy

• the staging layer

• the semantic model

• the measure design

• the naming conventions

• the relationships

• the security model

• the deployment process

• the documentation

• the ability to change the solution later
  

Agentic development works best when those layers are clearly defined.

If the model is messy, the agent can help you identify issues, but it cannot magically create a good architecture without proper direction. If the business process is unclear, the report will still be unclear. If the measures are inconsistent, the outputs will still need careful review.

But when you combine strong BI fundamentals with AI-assisted development, the productivity gains can be significant.

You can start to build in a more repeatable way.

Instead of treating every report as a blank canvas, you can define patterns:

• common data model structures

• reusable report layouts

• standard naming conventions

• standard date tables

• standard measure folders

• standard documentation outputs

• standard SQL view patterns

• standard deployment checklists
  

That is where agentic development becomes especially useful.

It helps turn good patterns into repeatable delivery.

Why this matters for SMEs

This way of working is especially relevant for small and medium-sized businesses.

Many SMEs do not need overly complex enterprise BI platforms. But they do need better reporting than spreadsheets, manual exports, and disconnected dashboards.

The challenge is that custom BI can be expensive and time-consuming if every solution is built from scratch.

A more agentic, template-driven Power BI workflow can help close that gap.

The goal is not to give every business a generic dashboard. The goal is to create a repeatable foundation that can be adapted quickly to each business.

For example, many businesses have similar reporting patterns:

• sales pipeline

• quotes

• jobs

• invoices

• payments

• customers

• products or services

• profitability

• operational performance
  

The source systems might differ, but the reporting concepts are often similar.

If you can build a reusable model approach around those concepts, then use agents to help with mapping, documentation, model review, and report adaptation, the delivery process becomes much faster.

That is where I think Power BI, PBIP, and agentic development become really powerful together.

Not as a shortcut around proper BI design, but as a way to deliver proper BI design more efficiently.

AI does not replace the BI developer

There is a lot of noise at the moment about whether AI will replace reporting tools or BI developers.

I do not see it that way.

If anything, working this way has reinforced how important the BI developer role still is.

The tools can help write, review, refactor, and document. But they do not automatically understand the business. They do not know which KPI actually matters. They do not know whether a number “feels wrong” because of a business process issue. They do not know the politics behind a metric definition. They do not know whether a report page is useful for the person who has to use it every Monday morning.

That still requires experience.

What AI changes is the amount of manual effort required to get from idea to working solution.

It gives BI developers more leverage.

A good developer can use these tools to move faster, create cleaner outputs, test ideas more quickly, and spend more time on the parts of the work that actually need human judgement.

In that sense, the role becomes less about manually building every object and more about designing the system, guiding the agent, validating the output, and making sure the solution is genuinely useful.

Where I think Power BI development is heading

Power BI has already moved a long way from where it started.

The direction feels clear.

Power BI development is becoming more:

• project-based

• source-controlled

• model-driven

• automated

• integrated with development tools

• supported by AI and agents

• focused on reusable patterns
  

That is a positive shift.

It means Power BI solutions can be built with more discipline. It means reports can be easier to maintain. It means development can become faster without becoming messier. And it means BI professionals can start applying more software development thinking to reporting and analytics.

For me, the most exciting part is not one specific tool or feature.

It is the change in workflow.

Power BI Desktop is still important. The report canvas is still important. The semantic model is still central. But now those pieces can sit inside a broader development process that is more structured, more repeatable, and more scalable.

That is a big step forward.

Final thoughts

I am still experimenting with this way of working, but the direction feels obvious.

Power BI is no longer just a reporting tool. It is becoming a proper development environment for data products.

PBIP opens up the project structure. Desktop Bridge helps connect visual development with code-driven workflows. Agentic development adds another layer of speed, review, and repeatability.

The combination is powerful.

The key is not to use AI for the sake of using AI. The key is to use it where it genuinely improves the development process.

For Power BI, that means using agents to help with structure, documentation, refactoring, modelling, migration, and repeatable delivery — while still relying on human judgement for architecture, business logic, user experience, and quality.

That is the way of working I am most interested in.

Not replacing Power BI development.

Evolving it.