AI-ready data platforms need developer workflows, not just admin portals
A lot of enterprise data platforms still expect modern engineering teams to work like button-clicking operators.
That is a problem.
If Microsoft Fabric wants to become the real operating environment for enterprise analytics and AI, it has to fit how developers, data engineers, and platform teams actually work: in code, in version control, and increasingly with AI tooling inside the editor.
That is why the new Visual Studio Code support for exploring and editing Fabric item definitions, alongside the Fabric MCP server story, is more important than it first looks. This is not just another convenience feature for people who prefer dark mode and keyboard shortcuts. It is part of a wider shift in how Microsoft is positioning Fabric as a platform that can be inspected, shaped, and automated through developer-native workflows.
In my view, that matters for one simple reason: AI adoption gets stuck when the platform underneath it is too manual.
The challenge
Many organisations say they want an engineering-led data culture. Fewer of them have the tooling model to support it.
Too often, the workflow still looks like this: a platform is configured in a portal, assets are created through point-and-click experiences, and the real logic of what has been built is only partially visible outside the service itself. That is manageable for small teams. It becomes painful very quickly at enterprise scale.
Why? Because repeatability suffers.
If definitions are hard to inspect, hard to compare, and awkward to edit outside the service UI, then governance becomes slower, collaboration becomes messier, and automation becomes harder than it should be.
This is especially relevant as organisations push towards AI-enabled operations. Once teams start using assistants, agents, and code generation to accelerate delivery, they need platform artefacts to be accessible in ways those tools can understand and work with safely.
That is where VS Code and MCP become strategically interesting.
What has changed
Microsoft’s update adds support in the Fabric extension for Visual Studio Code to explore, edit, and organise item definitions more directly. The item definition experience is no longer just something you inspect passively. Teams can work with those definitions in a more developer-native environment.
Alongside that, the Fabric MCP server story points towards a future where AI assistants and tooling can interact with Fabric in a structured, controlled way using the Model Context Protocol pattern.
This matters because MCP is not just another acronym for the pile. It is part of a broader movement towards making tools and platforms legible to AI systems in a standardised way. In practical terms, that means an assistant can potentially do more than generate generic text. It can work against actual platform context.
For Fabric users, that opens up interesting possibilities.
Think about a developer investigating item definitions before a release.
Think about an engineer comparing environments.
Think about a team using AI assistance in VS Code to understand how a Fabric artefact is structured, where a dependency sits, or how a definition should be updated.
None of that removes the need for human judgement. But it does reduce friction.
Why this matters beyond the feature list
The obvious reading of this announcement is that Microsoft is giving Fabric users a nicer development experience.
That is true, but it undersells the bigger point.
The more important story is that Microsoft seems to understand that the next phase of enterprise data platforms will be won through workflow quality. Not just feature breadth.
Most organisations do not struggle because their platform lacks another checkbox. They struggle because too much of the day-to-day work is still manual, inconsistent, and difficult to integrate into modern engineering practice.
When item definitions are easier to inspect and edit in VS Code, teams get closer to the disciplines that already work well in software engineering: peer review, diff-based change management, repeatability, and better alignment with version control.
And when MCP enters the picture, the platform starts becoming more accessible to AI-assisted engineering workflows as well.
That is where Leon’s practical lens comes in.
I would not present this as “Fabric now has MCP, therefore AI”. That is shallow and not especially useful.
I would present it like this: if you want AI to help your teams build, govern, and evolve data platforms, the underlying platform has to expose its structure in ways AI tools can safely understand. This announcement moves Fabric a little further in that direction.
The non-obvious business impact
The business impact here is not limited to developer convenience.
It is about delivery speed and control.
When teams can work with platform definitions in familiar tooling, they tend to move faster with fewer handoffs. They can inspect what changed. They can document more cleanly. They can integrate review steps more naturally. And they can reduce dependence on a small number of portal experts who carry too much platform knowledge in their heads.
That matters in enterprise environments where platform maturity is often constrained by people, not by licensing.
There is also a governance angle.
Better visibility into item definitions can make it easier to standardise patterns across teams, audit changes more clearly, and reduce the “mystery box” effect that sometimes appears in low-code and managed-data experiences.
For organisations trying to build confidence in AI-enabled delivery, that is significant. AI accelerates the good and the bad. If your platform artefacts are obscure and inconsistent, AI will help you create obscurity faster. If your platform artefacts are structured and reviewable, AI can become a genuine productivity layer.
Caveats worth saying out loud
There are still caveats.
First, developer-friendly tooling does not automatically create engineering discipline. Teams still need standards, branching approaches, review practices, and a clear operating model.
Second, AI access to platform context should be treated carefully. The more capable the tooling becomes, the more important it is to think about permissions, provenance, and guardrails.
Third, not every organisation is ready to operationalise MCP-driven workflows straight away. Some are still getting basic source control and environment promotion under control.
So yes, this is promising. But it is only valuable if it plugs into a broader platform strategy.
A practical example
Imagine a Fabric team supporting multiple business domains, each with its own pipelines, semantic models, notebooks, and warehouse artefacts.
In a portal-only world, reviewing changes across that surface area can become awkward and slow. Documentation drifts. Small edits are harder to compare. AI assistance is limited because the context is trapped in UI workflows.
In a VS Code-centric workflow, teams can inspect item definitions directly, organise them more deliberately, and start treating the platform estate more like an engineering asset than a black box.
Add structured AI assistance on top, and the question becomes more interesting: not “can AI build my data platform for me?” but “can AI help my team understand, review, and improve the platform more effectively?”
That is a far better question.
Getting started
If your team uses Fabric today, I would suggest looking at this update through three lenses.
First, workflow: where are your current Fabric development tasks still too dependent on portal navigation?
Second, governance: which artefacts would benefit most from clearer, inspectable definitions and better reviewability?
Third, AI readiness: are your platform assets becoming more legible to tools that could support engineering, documentation, and operational quality?
Do not adopt MCP because it is fashionable. Adopt it where it supports a real engineering problem.
And do not treat VS Code integration as a cosmetic preference. For many teams, it is the difference between a platform people can scale with and a platform people tolerate.
What this means
My take is straightforward: this announcement is really about platform maturity.
Fabric is becoming more credible when it meets engineers in the tools and workflows they already trust. That makes it easier to build repeatable delivery, stronger governance, and eventually more useful AI-assisted ways of working.
That does not make the hard parts disappear. But it does move the platform in the right direction.
If enterprise AI is going to work beyond demos, the underlying data platform cannot stay trapped in admin-centric workflows.
It has to become something developers can inspect, automate, and improve with confidence.
This is one more step towards that.
Leon Godwin, Principal Cloud Evangelist at Cloud Direct