Microsoft Power BI was the gift that kept giving. Non-developers could drag fields around, slap together a dashboard, and feel like data wizards by lunchtime. It was genuinely good at what it did, democratizing analytics for the masses.
Then Microsoft decided to apply that same playbook to a full enterprise data platform. The result is Microsoft Fabric, and the data engineering community has some thoughts. Most of them are not suitable for a Microsoft marketing brochure.
Here’s the uncomfortable truth: Fabric’s “low-code first, pro-code maybe later” philosophy is alienating the very people it needs to succeed, experienced data engineers. And in the age of AI, that’s not just a developer experience problem. It’s a strategic vulnerability.
It’s Databricks from Temu
Let me set the scene. A senior data engineer with a decade of experience across Spark, Airflow, Databricks, Snowflake, and Fabric recently quit their job after a year of working with Fabric. Their reasoning wasn’t about compensation or team culture. It was the platform itself.
The frustration isn’t subtle. Fabric’s interface is a maze of menus that feel bolted on one after another, with no clear entry or exit point. One engineer described it as “designed by committee, where nobody stopped to ask if it actually made sense to navigate.” The workflow across workspaces, pipelines, and notebooks doesn’t feel intuitive. It feels like navigating a shopping mall built by architects who never consulted a floor plan.
Comparisons to other platforms aren’t kind. The most brutal assessment circulating in engineering circles: “It is just Databricks from Temu.” That’s harsh, but it captures a genuine sentiment. Every GUI data platform now has to justify its existence when AI coding assistants have made writing and debugging pipelines trivially easy. Code can be tested. Code can be reviewed. Code can be debugged. Fabric’s JSON-based definitions? Not so much.
The Inverted Priorities Problem
Here’s where things get truly backwards. One engineer put it perfectly: “Fabric is upside down for where a data platform should be in 2026. It’s GUI where I want code to be, and code where I want GUI.”
Let’s break that down because it’s the sharpest critique of Fabric’s design philosophy I’ve encountered.
Where you need GUIs (but get code):
- Monitoring and observability are virtually nonexistent. You have to install Fabric Unified Monitoring (FUAM), which feels like assembling furniture from IKEA without the instruction manual. Why isn’t monitoring just part of the platform?
- Alerting requires setting up additional services or writing custom code. Compare that to Azure Data Factory, where notification setup was straightforward.
- Lineage visualization requires navigating code, not visual maps.
Where you need code (but get GUIs):
- Pipelines force you through click-driven configuration flows that make version control nearly impossible.
- Git integration took an absurdly long time to arrive, and even then, it’s wrapped in so much workspace complexity that it barely resembles the Git workflows developers actually use.
This inversion isn’t an accident. It’s the predictable outcome of prioritizing a non-developer persona above all else. Microsoft wanted to replicate Power BI’s success by making Fabric accessible to citizen data enthusiasts. The problem is that data engineering isn’t dashboarding. It’s building reliable, testable, maintainable systems.
The Version Control Tragedy
Git integration is where the low-code-first philosophy truly shows its teeth. Microsoft shipped Fabric with GUIs and fancy visualization tools, but developers waited an eternity for basic version control functionality. And when it finally arrived, it was, in the words of frustrated engineers, “not Git.”
You can’t just branch, commit, and merge. You’re wrestling with a workspace abstraction layer that complicates what should be a straightforward developer workflow. This has real consequences when you’re trying to implement rigorous testing strategies for ETL pipelines in complex data environments. Without proper version control integrated into the development flow, you can’t reliably track changes, review pull requests, or roll back broken deployments.
This gets even more painful when Fabric’s Data Factory (FDF) JSON structure enters the picture. It’s so convoluted that hand-editing for review or debugging is practically impossible. And if you want AI to help review or modify your pipeline definitions? Good luck. The opaque JSON structure makes AI-assisted development infinitely harder than working with clean, human-readable code.
Where Fabric Actually Shines
Let me be fair, because this isn’t a one-sided story. Fabric genuinely excels in specific scenarios.
For small companies, and even some medium-sized ones, that don’t need enterprise-grade platform management, Fabric is a legitimate superpower. You can build functional data systems at breakneck speed. The deep integration with the rest of the Microsoft stack is a significant advantage for organizations that live and breathe Azure, Microsoft 365, and Power Platform.
The problem emerges when you try to scale those early wins into something that resembles a mature data platform. The same features that make rapid prototyping effortless become constraints when you need fine-grained control, complex governance, or robust security controls. This echoes the broader challenge in the low-code vs no-code debate: what feels liberating in month one becomes a labyrinth by month six.
The AI Question That Nobody’s Answering
Here’s the existential question hanging over Fabric and every other GUI-centric data platform: what happens when AI agents become the primary developers?
The data engineering community is increasingly asking whether GUI-focused platforms can keep pace in an AI-driven world. Code-first tools have a natural synergy with AI assistance, models trained on code can write, review, and debug actual programming languages. But they struggle with proprietary, complex JSON schemas and clicking through nested menus.
A developer can’t easily prompt an AI to modify a Fabric pipeline definition because the underlying JSON is so convoluted that both human review and AI generation becomes error-prone. Copilot exists, but early experiences suggest it feels more like a party trick than a productivity multiplier.
Microsoft’s own response to the AI-assisted data refinement challenge will determine whether Fabric remains relevant. But right now, the platform’s architecture wasn’t designed with AI-first development in mind. It was designed for mouse clicks.
The Governance Blind Spot
Another critical failure point is governance. Fabric’s approach to monitoring and observability effectively demands assembling a separate stack. That’s unacceptable when data platforms need robust security controls as a native capability, not an afterthought.
Lineage, alerting, monitoring, and approval workflows shouldn’t require duct-taping multiple tools together. They should be platform primitives. When they aren’t, governance becomes a manual exercise, and manual governance is exactly the kind of non-scalable practice that causes compliance and PII handling failures down the line.
What This Means for Your Career (Yes, Really)
Despite all this criticism, there’s a pragmatic argument for learning Fabric. It’s increasingly everywhere in Microsoft-centric enterprises. The exposure is valuable, and the money is good. Deploying Fabric capabilities is a legitimately marketable skill.
But the advice from battle-hardened engineers is to treat Fabric as a tool, not an identity. Keep your fundamentals sharp, clean data modeling, robust transformation logic, scalable architecture. Don’t let convenience erode your standards for what well-structured medallion architecture looks like. The platform should serve you, not the other way around.
The Real Takeaway
The Fabric controversy is a microcosm of a broader tension in enterprise software. Vendors keep trying to make complex systems accessible by hiding their complexity behind GUIs. But you can’t UI your way out of version control, testing, monitoring, and governance requirements. Those are engineering problems that demand engineering solutions.
Platforms that treat developers as second-class citizens ultimately fail at the enterprise level. When organizations hit the limits of low-code abstraction, and they always do, they’re left with massive technical debt and frustrated teams. Smart architecture platforms recognize that low-code has its place but it’s not a replacement for developer-centric design.
Fabric isn’t doomed. Microsoft has the resources and ecosystem gravity to iterate. But the product philosophy needs an adjustment. Give developers real Git, real code, real monitoring, and real control. Layer the GUI on top of those solid foundations rather than replacing them.
Until then, data engineers will keep doing what they do best: building workarounds, documenting frustrations, and quietly questioning whether the low-code revolution was really about empowering them or just selling more licenses.
