My fellow co-founder and CTO of Xano, Sean Montgomery, was in a conversation recently with the SVP of Engineering at a large wealth management firm, walking through how we think about visual development and what it enables. At one point, their SVP of Engineering said something that stopped the conversation: “So you guys are democratizing the pull request.”
The more I've sat with that phrase, the more I think it identifies something important—not just about what we're building at Xano, but about a growing pattern in the industry. Everyone is racing to democratize building—more people contributing, more AI generating logic, more tools lowering barriers. That's exciting. I’m here for it. But, while everybody is racing to democratize building, nobody is racing to democratize understanding—and building without understanding is just shadow IT at scale.
But the new shadow IT isn't just on the business side anymore. It's inside engineering itself. The call is coming from inside the house.
What "democratizing the PR" actually means
Think about what “democratizing the PR” actually implies: letting non-developers—PMs, designers, data folks, operations teams—propose and review changes through friendlier interfaces. Lowering barriers so newcomers can confidently contribute. Sharing review and merge power more broadly, rather than leaving it with a few gatekeepers. Turning the PR from a niche developer practice into a common collaboration tool across an entire organization.
What I especially like about the PR framing is what it does to the development step itself. It almost downplays it. Build however you want—manually, with AI, with low-code or no-code tools—we don't care. When you're done, let's look at what you've built together. The PR becomes the moment of shared understanding.
It’s a good concept. But it only works if the people reviewing can actually comprehend what they're looking at. And right now that’s where things are starting to fall apart.
Shadow IT has jumped the fence
Most technology leaders are familiar with shadow IT—where business teams build tools, automations, and workflows that IT never sanctioned and doesn't know about. It's been a recurring headache for decades. A marketing team spins up a Zapier workflow that moves customer data between systems. A finance analyst builds a critical process in a spreadsheet macro. These things work until they don't, and when they break, nobody, least of all IT, knows how they were built or what they depend on.
And the pressure is only growing. An HFS Research survey of 123 Global 2000 companies found that 97% of business units want to build in parallel to IT. Meanwhile, average code reuse has fallen to just 33%—meaning teams are rebuilding two-thirds of their functionality from scratch. The desire to build is outpacing every organization's ability to govern what's being built.
For a long time, shadow IT was a containable problem. It lived at the edges. The business side built things IT didn't know about, but at least the engineering side had a handle on its own systems. Code was written by humans, reviewed by humans, and understood (however imperfectly) by the people responsible for it.
That assumption is breaking down. AI doesn't just empower citizen developers on the business side. It's generating logic for actual engineering teams—schemas, services, API integrations, workflow automations—that the engineers who requested it don't always fully understand. The opacity problem has jumped the fence. It's no longer just unauthorized building that's the risk. It's ungovernable building—and it's happening inside engineering itself.
Shadow IT, in other words, is no longer just a business-side phenomenon. It's a structural condition of any system where the authorship of logic outpaces the understanding of that logic. And in a world of AI-generated code, that gap is widening fast.
Governance without comprehension is theater
This is what brings us back to the PR metaphor. The pull request, at its core, is a governance mechanism. It says: here's what I want to change, here's why, and I need someone else to look at it before it goes live. Opening that mechanism to more people is the right instinct. But a PR is only useful if the reviewer can comprehend what they're approving.
If a PM opens a pull request that contains AI-generated business logic, but neither the PM nor the reviewing engineer can clearly see how that logic interacts with permissions, data flows, and downstream services, then the review is theater. You've democratized the form of governance without democratizing the substance.
Dan Shapiro's recent framing of AI development levels is helpful here (I also talked about it in this Futureproof post about the transition from no-code to visual validation). He suggests that for the foreseeable future, most teams will live in the middle of the spectrum—Levels 3 and 4—where AI generates substantial portions of software, but humans still decide what actually runs. That's the world we're entering. And in that world, the most dangerous failure mode isn't runaway AI autonomy. It's humans approving systems they don't fully understand.
Understanding as the scarce resource
Here's where the shift gets interesting. For most of software's history, the scarce resource was the ability to build. Writing code was specialized, time-consuming, and expensive. The entire industry—from IDEs to frameworks to SaaS platforms—was organized around reducing the friction of creation.
AI has dramatically reduced that friction. Building is becoming abundant. But understanding hasn't kept pace. In fact, as creation accelerates, the gap between what gets built and what gets understood is growing. Teams are shipping faster but comprehending less.
This is the new constraint. The bottleneck isn't "Can we build it?"—it's "Can we see what we've built?" Can a team inspect how business rules are applied, how data moves through a system, how permissions are enforced, where decisions branch, and which services hold authority over an outcome? Can they do this quickly enough to maintain confidence in what's going to production?
If the answer is no, then every expansion of authorship—whether it's more contributors to PRs, more citizen developers, or more AI-generated logic—makes the system harder to govern, not easier.
Visual validation closes the loop
This is why I keep coming back to visual validation—not as a nice-to-have, but as the connective tissue that makes democratized building actually work.
When I talk about visual validation, I mean the ability to see, concretely, how a system behaves: where rules live, how decisions propagate, which policies are enforced, and whether those behaviors align with what your organization actually intends. It's the interface between authored logic—whoever or whatever authored it—and human judgment.
Think about it in terms of the democratized PR. If a non-developer proposes a workflow change, visual validation is what lets the reviewer understand the impact without reading raw code. If an AI agent generates a new integration, visual validation is what lets the team see whether it respects the permission model and financial rules before it ships. If a citizen developer builds an automation, visual validation is what makes it visible to IT—turning potential shadow IT into governed contribution.
The pattern is the same in every case: visual validation transforms opaque authorship into legible governance. It's what turns "more people building" from a risk factor into an actual capability.
The real democratization
Here's the bottom line. The conversation about democratizing PRs, democratizing development, democratizing AI-powered building—it's all pointed in the right direction. Expanding who can contribute to software is a good thing. The more perspectives that shape a system, the better it tends to serve the people who depend on it.
But contribution without comprehension is just a faster path to fragility. If you democratize building without democratizing understanding, you end up with more authors, more complexity, and less visibility—which is exactly the shadow IT problem, scaled up and moved inside the house.
The teams that get this right will be the ones that invest as much in making systems legible as they invest in making them buildable. They'll treat visual validation not as a layer on top of their tools, but as a core requirement of their architecture—the thing that makes every other form of democratization safe.
Xano's no-code roots make visual validation a first-class concept. Want to see how to scale human-in-the-loop code review? Try Xano for free!
