Over the last few months I've been seeing people talk about "how fast they ship" or "they use up to 100 parallel agents" or some product owners saying "we don't need developers anymore!", "when development gets automated, knowing what to build is the important skill". 👍 Good for them. While everyone proudly shows off their "superpowers", I started thinking.
For the sake of argument, let's assume we have somehow achieved hyper-productivity on all team members, let's also assume we're doing the right things the right way. Let's skip the obvious failure mode where AI simply helps us build the wrong things faster. That's another article. 😅
Everyone understands the customers. They understand the business. They're technically capable. They have powerful AI tools. They can go from an idea to production much faster than teams traditionally could.
Basically, we've created the perfect Alien/Predator hybrid of product development. The Product Engineer! 🚀
Powerful. Efficient. Maybe slightly terrifying. And they're all shipping.
Coordination Problem? Review Bottlenecks?
Here's the part I think we're collectively skipping: AI scales production. It does not scale the things production depends on.
Review doesn't scale. Comprehension doesn't scale. Integration doesn't scale. Somebody still has to hold a working model of the system in their head. You could try separating boundaries clearly, saying "don't touch my stuff, I won't touch your stuff" but you still need to change a common dependency to make progress from time to time, creating some friction and meetings. 🥲
This could happen:
- One person changes authentication.
- Another redesigns onboarding.
- A third rewrites the billing model.
- Someone modifies a shared API.
- Someone else decides the design system is holding them back and invents a better interaction pattern.
Every decision is defensible. Every person is doing good product work. Every change passes its tests. And the product still ends up incoherent.
When implementation was expensive, cost was quietly doing some of our coordination for us. We were careful about committing to changes because changes were expensive. Now that constraint is basically gone.
Which turns an engineering question into an uncomfortably political one: how do you govern a large number of fast, capable, autonomous Product Engineers?
1. Centralism (Or AI Feudalism 😉)
The first solution is the most familiar and traditional. We already do this in some capacity.
This solution gives developers enormous autonomy locally, but maintains strong central mechanisms for integration. An architect or lead would need to maintain coherence using architecture boundaries, integration tests, design systems, technical standards, checkpoint meetings for major integrations.
Our Product Engineers become powerful local lords. They can move incredibly quickly inside their territory, but somebody still owns the kingdom.
This works. It has worked for decades. It also has one very specific failure mode in an AI-heavy org: you've accelerated implementation by 10x while your coordination layer still runs at human speed.
Twenty hyper-productive Product Engineers generate an enormous amount of work between two architecture reviews. So you delete the implementation queue and immediately grow a governance queue in its place.
So the King becomes the bottleneck, but could still work well in small organizations.
2. Federation (United States of AI)
Another possibility is to coordinate less frequently and instead agree more strongly on boundaries.
Less kingdom, more federation. Each domain owns its territory, you have your own state laws but you also have federal laws. Everyone signs a shared constitution, product principles, design system, security requirements, data conventions, API contracts, architectural boundaries.
Inside those boundaries you don't need permission, because we already agreed on the rules that permission would have been granted under. A UI design system is a perfect example of this.
The question shifts from "Can I make this change?" to "Is this within my domain's authority, and does it respect our shared contracts?"
Which is, unmistakably, political federalism. Some powers belong to the federation, others stay local, and the interesting architectural decision is no longer about code at all:
Which decisions must be shared, and which should stay local?
Good architecture in an AI-heavy organization may be less about organizing systems and more about organizing autonomy.
3. Machine Federalism
Now things get weird 🤣
We'll steal some ideas and concepts from DAOs (Decentralized Autonomous Organization) and combine it with AI and our federation idea.
If AI dramatically increases the speed at which we build software, perhaps AI also becomes part of the mechanism that coordinates it.
We already do a primitive version of this. CODEOWNERS is an ambassador. A contract test is a treaty. A schema registry is a border checkpoint. A deprecation scanner is a very rude diplomatic cable. These mechanisms exist precisely because coordinating by meeting doesn't scale, we just built them out of regex and hope. 🥲
So imagine every Product Engineer gets their own AI representative with actual reasoning ability. All changes are tracked on a ledger (shoutout to blockchain and DAO).
You propose a change to the system. Your representative publishes it.
Billing: Let's support Eurodollar (from Cyberpunk)
The agents inspect contracts, run tests, find collisions, and negotiate. Most disagreements get resolved without a single human opening a calendar. Eventually you get back:
Accepted by 7 domains. One conflict resolved automatically. One product decision requires human judgment.
At which point you have built a DAO whose members are AI agents representing parts of your codebase, which sounds ridiculous until you notice it's just CODEOWNERS with an opinion.
Humans haven't left. They set the goals, draw the boundaries, and define what their representatives are allowed to concede. The unresolved questions are the genuinely hard ones: Who assigns the objectives? And the big one: who writes the constitution?
The Point
Well, the point is we don't know what is best, yet. Technology is changing rapidly, tools evolve, ways of working adapt, it is all at lightspeed compared to before.
Here's my advice, really look at your workflows today, criticise them, change them, try new things because that is the part I see get stuck in tradition.
Also, I just wanted an excuse to apply political science to software architecture. 🤣