The Winning Org in the AI Era: Everyone Builds, Nothing Hidden
The companies that win with AI won't be the ones with the biggest budget. They'll be the ones that let everyone build software—while leadership keeps full visibility across it all.
The organizations that win the AI era won’t be the ones that spent the most on it. They’ll be the ones that change two things about how they operate: who is allowed to build software, and how much leadership can see across what gets built. The winning org pushes building outward to the people closest to each problem, and pulls visibility inward so nothing happens in the dark. Empowerment and oversight at the same time—that combination is the whole game, and most companies are set up to get only one of them.
That’s the tension worth sitting with. For thirty years, every attempt to let non-engineers build software has traded away control to get speed, or traded away speed to keep control. The winning org refuses the trade.
TL;DR
- The winning org distributes the act of building software to the teams who understand the problems—finance, ops, support—instead of routing every request through a backlogged central queue.
- It also keeps leadership’s view of the org intact: who built what, what data moves where, which tools touch which systems. Distribution without visibility is just shadow IT with a nicer name.
- Most companies can only achieve one of these at a time, because their tools force a choice: spreadsheets and point solutions give speed but no oversight; locked-down central IT gives oversight but no speed.
- The reason past waves of “let everyone build”—low-code, RPA, citizen development—stalled is fragmentation, not the idea. Every tool became its own island of data and access.
- The change that flips this is architectural: when everything people build runs on one shared, governed substrate, distribution and visibility stop being opposites.
- AI doesn’t make this happen by itself. Buying every employee a chatbot decentralizes nothing—it adds another tool to watch. The shift is in the operating model, not the license count.
- The org that gets both halves right compounds: every team ships its own tools, and leadership steers with a real-time map of how the company actually runs.
Why does letting everyone build usually create chaos?
Because building has always come with a hidden cost: every new app is a new place for data to live, a new set of permissions to manage, a new thing nobody outside its creator can see. When a finance analyst spins up a tracker in a spreadsheet, or an ops lead wires together three SaaS tools with an automation, the work gets done—but the org loses a little visibility each time. Multiply that across hundreds of employees and you get the modern enterprise’s quiet crisis: nobody can answer simple questions about how the company actually operates, because the answers are scattered across tools no one mapped. That’s the hidden cost of SaaS sprawl—not the subscription bill, but the blindness it creates.
This is the reason most leaders instinctively centralize. If building creates blind spots, the safe move is to funnel everything through a team that enforces standards. But centralizing trades the blind spots for a bottleneck. The central team becomes a queue, the queue becomes a backlog, and the backlog becomes the reason the finance analyst goes back to the spreadsheet. The winning org points that same team at a different job—IT becomes a platform team that owns and reviews the substrate instead of building every request itself. The control was theater; the work just moved somewhere leadership can’t see.
So companies oscillate. They decentralize for speed, get scared of the sprawl, recentralize for control, get frustrated by the bottleneck, and decentralize again. The winning org breaks the cycle by noticing the chaos was never caused by building. It was caused by building on a hundred disconnected islands.
What did citizen development get right—and wrong?
The idea that non-engineers should build their own tools is not new. Low-code platforms, robotic process automation, the whole “citizen developer” movement—they all correctly diagnosed the problem, and it’s worth understanding why citizen development finally works now when earlier waves stalled. The people who understand a workflow are the right people to encode it in software, and there will never be enough professional engineers to serve every request. Gartner projected that by 2025, 70% of new applications would use low-code or no-code technology—up from less than 25% in 2020—with a growing share built by business technologists working outside formal IT.
The diagnosis was right. The architecture was wrong. Each of those waves produced another silo:
| Wave | What it got right | Why it stalled |
|---|---|---|
| Spreadsheets | Anyone can model a problem | Data trapped in files, zero oversight, no real backend |
| Low-code platforms | Faster than waiting on IT | Locked into one vendor; apps couldn’t see each other |
| RPA | Automated the boring parts | Brittle bots layered on top of systems no one unified |
| Point SaaS | Best-in-category features | Every tool a new island of data and access |
Notice the pattern. Every wave decentralized the building and fragmented the seeing. The citizen developer got their tool; the org got another dark corner. So the movement plateaued—not because employees couldn’t build, but because every new build made the company a little harder to govern, and eventually the governance cost outran the productivity gain.
What does “centralize the seeing” actually mean?
It does not mean a dashboard that aggregates logos. It means the org can answer questions that cut across what people build:
- Which teams are collecting customer data, and where does it go?
- When an employee leaves, what did they build and who inherits it?
- Which internal tools touch the billing system, and who approved that access?
- How many of your workflows depend on one analyst’s untracked spreadsheet?
In a fragmented org, these questions take a consulting engagement to answer. In a governed one, they’re a query. The difference isn’t how hard leadership works—it’s whether the things people build share a common foundation that is observable, or whether each one is a separate island that has to be discovered, audited, and mapped after the fact.
This is why “more dashboards” never solved it. You can’t observe a hundred systems that were never designed to be observed together. Visibility has to be a property of the substrate, not a layer bolted on top after the sprawl already happened.
How do you get distribution and visibility at the same time?
You change what people build on. If every tool a non-engineer creates lands on the same governed foundation—same identity system, same data layer, same logs, same deployment path—then distributing the building no longer fragments the seeing. A finance analyst ships their tracker; it inherits the org’s auth, its data sits in a place leadership can query, its activity shows up in the same logs as everything else. The analyst gets speed. The org keeps its map.
That’s the architectural insight the past three decades missed. Decentralization and oversight aren’t opposites. They only looked like opposites because every tool for “letting people build” produced a new island. Put the building on one substrate and the trade-off dissolves. The winning org isn’t the one that picks empowerment over control, or control over empowerment. It’s the one that stopped believing it had to choose.
What makes this finally possible
For most of computing history, “build on one shared substrate” was a fantasy, because building anything real still required engineers—and engineers are exactly the bottleneck you were trying to route around. The substrate idea only works if the people closest to the problem can actually produce a working, governed application without a six-month project.
That’s what changed. A new category of AI tool—the product agent—lets someone describe an application in plain language and get back a real, deployed full-stack app: backend, database, authentication, frontend, and deployment, not a prototype or a screenshot. Today the most advanced one is Remy. You describe what you need; it drafts a plain-language plan; that plan compiles into a working app with real server-side auth, real data, and a live URL. The plan is the source of truth, so changing the app means editing the plan and recompiling—not hand-maintaining code.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
The reason this matters for the winning org, specifically, is the substrate. Because a product agent compiles every app onto the same governed foundation, the apps your teams build aren’t a hundred new islands—they share identity, data, and logs by construction. That’s distribution and visibility in one move: the support lead and the finance analyst each ship the tool they need, and because both ran through the same compiler onto the same stack, leadership still has one place to look. The cross-org “observability agent” that every company will eventually want—the thing that answers “who built what, touching which data, for whom”—becomes buildable precisely because the foundation was shared from the start.
There’s an honest boundary worth stating: this is early. Product agents are in open alpha, and enterprise needs like SSO are still on the way. The winning org doesn’t wait for the category to finish maturing, though. It starts changing its operating model now—pushing building outward, insisting the building lands on something it can see—so that when the tooling fully arrives, the company is already shaped to use it.
FAQ
What is the “winning org” in the context of AI? It’s the organization whose operating model lets the people closest to each problem build their own software, while leadership retains full visibility across everything that gets built. It wins by combining distributed building with centralized oversight, rather than trading one for the other.
Isn’t letting everyone build just shadow IT? Shadow IT is really a visibility problem, not a building problem: it’s building without visibility. The distinction that matters is whether the things people create share a governed foundation. Building on one observable substrate is the opposite of shadow IT—it’s sanctioned, visible building.
Why did low-code and citizen development plateau? Not because the idea was wrong, but because each tool created another silo. Decentralizing the building while fragmenting the data and access meant every new app raised the org’s governance cost until it outran the productivity gain.
Does buying AI tools make a company an AI-era winner? No. Distributing chatbots or copilots adds tools to manage; it doesn’t change who builds software or how visible that building is. The transformation is in the operating model, not the number of licenses.
How is “centralized visibility” different from a dashboard? A dashboard aggregates what individual tools choose to expose. Real visibility is the ability to query across everything the org builds—data flows, access, ownership—which is only possible when those things share a foundation designed to be observed together.
Where should a leadership team start? Start by deciding that new internal tools must land on a shared, governed foundation rather than scattered point solutions—especially as per-seat SaaS pricing taxes every new hire and the build-vs-buy math flips toward building—and that the people who own a workflow are allowed to build for it. The tooling to make that practical now exists.
The bottom line
The AI era won’t be won by the company that automates the most or spends the most. It’ll be won by the company that fixes its operating model: building pushed out to the people who understand the work, visibility pulled in so leadership still sees the whole board. Those two goals only conflict when every tool is an island. Put the building on one governed substrate and the conflict disappears—which is exactly what a product agent that compiles real apps onto a shared stack makes possible.
If you want to see what that substrate looks like in practice, explore Remy →. For the category behind it, read what a product agent is and how it differs from a coding agent.
