Decentralize the Building. Centralize the Seeing.
The two motions look contradictory: push building to the edges, pull visibility to the center. They only conflict when every tool is a separate island.
The right operating model for software in the AI era runs two motions at once: push the building outward to the people closest to each problem, and pull the visibility inward so leadership can see across everything that gets built. Decentralize the building. Centralize the seeing. Said out loud, it sounds like a contradiction—if everyone builds, how does anyone keep track? Most organizations treat it as exactly that, a tradeoff to be managed, and pick a side. The companies that will win pick both, because the contradiction is an illusion created by one bad assumption: that every tool a person builds has to be its own separate island.
Drop that assumption and the two motions stop fighting. Building goes to the edge, where the problem-context lives. Visibility stays at the center, where leadership steers. Neither has to give ground.
TL;DR
- The winning operating model decentralizes building—the people who own a workflow build the tool for it—because problem-context lives at the edge, not in a central queue that’s never seen the workflow.
- It simultaneously centralizes seeing—who built what, what data moves where, which tools touch which systems—because leadership can only steer with a view across the whole company, not a pile of disconnected reports.
- These two motions look like opposites, and most orgs treat them as a tradeoff: you can have speed at the edge or control at the center, pick one.
- They only conflict when every tool is a separate island. Put every build on one shared foundation and the tradeoff dissolves—distribution stops fragmenting visibility.
- Every past wave that decentralized building—spreadsheets, low-code, RPA, citizen development—decentralized the building but fragmented the seeing, which is why each one plateaued.
- The fix was never tighter central control or a better dashboard. Visibility has to be a property of the substrate the building happens on, designed in, not bolted on after the sprawl.
- Handing everyone an AI chatbot or coding assistant doesn’t run either motion—it adds a tool to watch without changing who can build a real, governed app.
Why does decentralizing the building actually matter?
Because the context for solving a problem lives with the people who have the problem—and almost nowhere else. A finance analyst who reconciles vendor payments every month knows the edge cases a requirements doc will never capture: the one supplier who invoices in two currencies, the approval that needs a second sign-off over a threshold, the field that’s technically optional but practically mandatory. Hand that workflow to a central engineering queue and the first three weeks are spent re-learning what the analyst already knows. The org closest to the problem should own the build because it starts from the answer.
This isn’t a productivity hack for the individual analyst. It’s a structural advantage for the company. An org that lets the people who understand a workflow build the tool for it ships solutions that actually fit, and it ships far more of them—because it isn’t rationing a scarce central resource. The org that funnels every request through a six-month IT queue isn’t more disciplined. It’s slower, and it builds tools that fit worse.
There’s also a hard ceiling on the alternative. There will never be enough professional engineers to serve every workflow in a 500-person company. The long tail of internal tools—the tracker, the approval flow, the dashboard one team needs—never clears a central backlog, because it’s always lower priority than the next customer-facing feature. Decentralizing is the only way that tail ever gets built. It’s the case citizen development finally makes good on, after three waves that had the right idea and the wrong architecture.
Why does seeing have to be centralized?
Because leadership steers the whole company, and you cannot steer what you cannot see. The questions that matter at the top cut across what individual teams build: Which parts of the org are collecting customer data, and where does it flow? When someone leaves, what did they build and who inherits it? Which internal tools touch the billing system, and who approved that access? How many critical workflows hinge on one person’s untracked spreadsheet?
In a fragmented org, every one of those questions is a project: discover the tools, interview the builders, audit the data flows, assemble a map by hand that’s stale the day it’s finished. In an org where the building shares a foundation, the same questions are a query. The difference isn’t how hard leadership works. It’s whether visibility was designed in or has to be reconstructed after the fact—it’s the difference between an org leadership can read and one whose fragmented tools make it illegible to its own leadership.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
This is the half that gets dropped. Decentralization is the exciting motion—more building, faster, everywhere. Centralized seeing is the unglamorous one, so it gets deferred until the sprawl is unmanageable. But seeing isn’t the brake on building. It’s what makes leadership comfortable letting building happen at all. An org that can see everything its people build has no reason to fear them building. The fear—and the reflex to lock everything down—comes entirely from the blindness.
Why do the two motions look like a tradeoff?
Because for thirty years they genuinely have been one. Every tool that decentralized building made the org harder to see, so leaders learned, correctly, that speed at the edge cost them control at the center. The lesson was real. The cause was misdiagnosed.
The cause was never building. It was that each tool became an island—its own data, its own access model, its own dark corner. Decentralizing across a hundred islands doesn’t just distribute building; it shatters visibility, because there’s no shared surface to observe. So leaders faced a real choice between two bad options:
| Approach | What you get | What you give up |
|---|---|---|
| Decentralized building, no shared foundation | Speed at the edge—teams ship their own tools fast | Visibility—every tool is an island, the org goes blind to itself |
| Centralized control, everything through one queue | Oversight—one team sees and standardizes everything | Speed—the queue becomes a backlog, the backlog drives people back to shadow IT |
| Decentralized building on one shared foundation | Both—teams ship at the edge, leadership sees across the center | The assumption that you had to choose |
The first two rows are the oscillation most companies live in. Decentralize for speed, panic at the sprawl, recentralize for control, choke on the backlog, decentralize again. The third row is the exit. It isn’t a compromise between the first two—it’s a different architecture that makes the tradeoff disappear, because the building and the seeing now happen on the same surface.
Why did past waves decentralize building but fragment seeing?
Every wave of “let non-engineers build” got the first motion right and the second motion exactly wrong. They distributed the building and, in the same stroke, scattered the data, the access, and the visibility. 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 building decentralized. The seeing never followed.
Look at what each wave actually produced:
| Wave | The motion it ran | The motion it skipped |
|---|---|---|
| Spreadsheets | Anyone can model a problem at their desk | Data trapped in files no one can query across; zero oversight |
| Low-code platforms | Build faster than waiting on IT | Apps locked in one vendor, blind to each other and to leadership |
| RPA | Automate the repetitive parts | Brittle bots layered on systems no one ever unified |
| Point SaaS | A best-fit tool for every function | Every tool a new island of data and access to discover later |
Each one decentralized the building and fragmented the seeing—and each plateaued for the same reason. Not because employees couldn’t build. Because every new build made the company a little harder to govern, until the governance cost outran the productivity gain and leadership pulled the reins. These movements didn’t fail on the building motion. They failed on the seeing motion, every time, because no one made visibility a property of the foundation. They left it for later, and later never came.
How do you run both motions at once?
You change what people build on. The two motions only conflict when building lands on a hundred different surfaces. Put every build on one shared, governed foundation—same identity system, same data layer, same logs, same deployment path—and decentralizing the building stops fragmenting the seeing.
Walk it through concretely. A finance analyst builds a vendor-approval tool. On the shared foundation, that tool inherits the org’s authentication, so access follows the same roles as everything else. Its data lands in a place leadership can already query. Its activity shows up in the same logs as every other app. The analyst gets the full speed of building at the edge. The org loses none of its visibility at the center—because the building never left the surface the center can see.
That’s the resolution the past three decades missed. Distribution and oversight were never opposites. They only looked like opposites because every tool for letting people build produced another island. One substrate, and “decentralize the building, centralize the seeing” stops being a paradox and becomes a single design decision. The reframe is the same one underneath shadow IT as a visibility problem: the issue was never that people build, it’s whether what they build is something the org can see.
This is also why “buy more dashboards” never closed the gap. A dashboard aggregates what islands choose to expose. It can’t make a hundred systems observable that were never built to be observed together. Seeing has to be designed into the substrate, not painted over the sprawl afterward—which is why your best engineers should architect that substrate rather than hand-build the apps that land on it.
The turn: what makes one substrate possible
Everything above resolves to a single design decision: put the building on one governed foundation, and the two motions stop fighting. But that prescription had a hard prerequisite that, until recently, made it a fantasy. “Build on one shared substrate” only works if the people at the edge—the analyst, the ops lead, the support manager—can actually produce a working, governed application without an engineering project. And for the whole history of computing, building anything real required engineers, which is precisely the bottleneck the whole exercise was trying to route around.
The recent reflex is to close that gap with AI by handing everyone a coding assistant—Cursor, Claude Code, Copilot—and calling it transformation. But those are coding agents: they’re excellent for engineers, operating at the code layer and assuming engineering skill. Point one at a finance analyst and you’ve relocated the barrier, not removed it. The analyst still can’t ship a governed app, and worse, whatever each person does ship lands on its own island anyway. That decentralizes nothing and centralizes nothing. It just adds another tool to watch.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
A different category runs both motions. A product agent lets someone describe an application in plain language and get back a real, deployed full-stack app—backend, database, auth, frontend, and deployment—not a prototype. 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 and roles, real data, and a live URL. The plan is the source of truth, so changing the app means editing the plan and recompiling. This is the layer a product agent operates at versus a coding agent: the product, not the file.
Here’s why that resolves the two-motion problem specifically. Because a product agent compiles every app onto the same governed foundation, decentralizing the building doesn’t fragment the seeing. The analyst and the support lead each ship the tool they need—that’s the building, pushed to the edge. And because both ran through the same compiler onto the same stack, they share identity, data, and logs by construction—that’s the seeing, kept at the center. One move, both motions. The shared substrate isn’t a convenient default; it’s the entire point, because it’s the only thing that lets the two motions run at once instead of trading off.
One honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO and SAML aren’t shipped yet. What exists today is genuine server-side auth and roles enforced from the plan—the right fit for the internal tools an org most wants visible and governed. The winning org doesn’t wait for the category to finish maturing. It starts running both motions now, so when the tooling fully arrives, the operating model is already shaped to use it.
FAQ
What does “decentralize the building, centralize the seeing” mean? It’s an operating principle for software in the AI era: let the people closest to each problem build the tools they need (decentralized building), while leadership keeps a single view across everything that gets built—who built what, what data moves where, which tools touch which systems (centralized seeing). The two motions only conflict when each tool is a separate island.
Why not just centralize everything through IT? Centralizing gives you oversight but trades away speed. The central team becomes a queue, the queue becomes a backlog, and the long tail of internal tools never gets built—which drives people to shadow IT, putting the building somewhere leadership can see even less.
Why did low-code and citizen development plateau? Because each wave decentralized the building but fragmented the seeing. Every tool became its own island of data and access, so the org’s governance cost climbed with each new build until it outran the productivity gain.
Isn’t decentralized building just shadow IT? Only when it’s invisible. Shadow IT is building without visibility. Building on one governed, observable foundation is the opposite—it’s sanctioned, visible building, where distribution and oversight happen on the same surface.
Can’t a dashboard give leadership the centralized view? No. A dashboard aggregates what individual tools choose to expose; it can’t make systems observable that were never designed to be observed together. Visibility has to be a property of the substrate the building happens on, not a layer added after the sprawl.
Does giving everyone an AI chatbot or coding assistant solve this? No. A chatbot or coding assistant adds a tool to manage without changing who can build a real, governed app. Coding agents operate at the code layer and assume engineering skill, so pointing them at non-engineers relocates the barrier instead of removing it—and whatever gets built still lands on its own island.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
Where should a leadership team start? Decide two things: the people who own a workflow are allowed to build for it, and everything they build must land on one shared, governed foundation rather than scattered point solutions. That’s the two motions encoded as policy—the tooling to make it practical now exists.
The bottom line
Decentralize the building. Centralize the seeing. The two motions look like opposites, and for thirty years they were—every wave that pushed building to the edge fragmented leadership’s view in the same stroke. But the conflict was never caused by building. It was caused by building on a hundred disconnected islands. Put every build on one governed substrate and the tradeoff dissolves: teams ship the tools they need at the edge, leadership sees across the whole company from the center, and neither motion gives ground. That’s the operating model the winning org runs—and what a product agent that compiles real apps onto a shared stack finally makes possible.
If you want to see what building on one governed substrate looks like in practice, explore Remy →. For the bigger picture, read what the winning org looks like and the org chart of 2027.
