When Specialization Becomes Cheap

For most of software history, architecture has been shaped by a constraint that had almost nothing to do with computers: human development cost.

Building software was slow. Maintaining it was expensive. Every new feature meant people—designers, engineers, operators, documenters—spending weeks or months on work that could not be casually thrown away. So we learned to optimize for reuse, generality, and scale across many customers at once.

That is not a failure of imagination. It was rational economics.

The platform era made sense

When specialization is expensive, the winning move is to build one large thing and make many domains fit inside it.

A generic CRM. A configurable SaaS platform. A workflow engine with plugins. A monolithic product with settings screens for every edge case. A marketplace where third parties extend what you could not afford to build yourself.

These patterns share a logic: amortize human effort across many use cases. You accept that no single customer gets a perfect fit. You trade specificity for maintainability. You centralize knowledge in one schema, one admin panel, one release train.

For forty years, that was often the right trade.

What changes when building gets cheaper

This is not an article about "AI builds software." That framing is too narrow, and it invites the wrong argument—whether generated code is good enough today.

The deeper shift is economic. If the cost of creating and evolving software drops sharply, specialization stops being a luxury.

Not because every domain instantly gets a bespoke system tomorrow. Because the calculation changes. The question is no longer "can we afford to build something specific to this domain?" but "what is the cost of forcing this domain into a generic mold?"

That reframes architecture from a technical puzzle into a first-principles one.

A different shape: many small systems

If specialization is cheap, the optimal shape may not be one platform containing every workflow. It may be an ecosystem of small, autonomous, domain-specific intelligent systems—each responsible for its own corner of the world.

Each system might own:

• its own knowledge
• its own memory
• its own workflows
• its own evolution
• its own documentation
• its own maintenance

Not because isolation is virtuous for its own sake. Because ownership is what lets a system adapt without waiting for a central product roadmap, a shared data model, or a committee.

A thin shared layer still matters: governance, routing, resource management, communication. The intelligence does not disappear into chaos. It moves out of the platform and into the systems—closer to the domain, closer to the work.

We have seen a smaller version of this pattern in agent design: a network of narrow roles beats one generalist that tries to do everything. See The myth of the single AI agent and Why agent roles matter more than model quality. The architectural question is whether that logic scales from agents inside a product to products inside an organization.

Assumptions worth questioning

None of this is a prediction. It is a list of things that might have been optimal for human economics—and might not be anymore.

Generic CRMs. Perhaps sales, support, and success are different enough that one shared object model was always a compromise. Perhaps what we called "configuration" was really "paying down the gap between your domain and our platform."

Configurable SaaS. Perhaps the settings screen is a scar—a visible record of domains forced into someone else's abstraction.

Workflow engines. Perhaps orchestration belongs with the domain that understands why step three exists, not in a central engine that knows syntax but not stakes.

Plugin ecosystems. Perhaps plugins were a patch for specialization we could not afford to build natively.

Huge monolithic products. Perhaps the monolith was not the best design. Perhaps it was the best design given who had to build and maintain it.

Again: not verdicts. Questions.

What happens when every domain gets its own system?

If the cost curve bends far enough, organizations may stop asking "which product do we buy?" and start asking "which entity do we stand up for this function?"

That entity would not be a static app. It would be closer to an operational system—one that reads its domain, updates its own procedures, explains its own decisions, and ages with the business around it. Memory would not be a bolt-on feature. It would be structural—see Living memory for your project and Context is not memory.

The hard parts do not vanish. They relocate.

• Governance becomes more important, not less—many autonomous pieces need shared rules. See Autonomous systems still need governance.
• Understanding may matter more than raw execution—the systems still need to know why they act. See Execution is not the bottleneck.
• Leadership may look more like architecture than task management. See The CEO becomes a system architect.

What becomes the role of platforms?

Perhaps platforms stop being "the place where work happens" and become infrastructure for coordination.

Routing messages between systems. Enforcing policy. Allocating compute. Auditing decisions. Providing identity and trust. The platform becomes thinner, more like a city grid than a single building everyone must live inside.

That is uncomfortable if your business model is seat-based access to one large product surface. It is interesting if your business model is enabling many systems to exist safely.

Products or operational entities?

We have long optimized software as products: features, releases, user interfaces, adoption metrics.

Domain-specific intelligent systems may look less like products and more like operational entities—always on, always learning their patch of the world, maintained by the same forces that maintain the work itself. The interface might be secondary. The continuity might be primary.

Does that make software less important?

Perhaps it makes code less central and intelligence plus structure more central. The repository might evolve from a container for source files into something closer to a living system—specs, memory, workflows, and governance co-evolving in one place. Maintenance is not a quarterly chore. It is part of the entity's metabolism—aligned with Let the agent maintain itself.

A thought experiment

Imagine two companies in the same industry.

Company A runs on a mature SaaS stack: CRM, ticketing, billing, analytics—each a large generic platform, heavily configured.

Company B runs on a mesh of small domain systems. One handles customer relationships the way their sales motion actually works. One handles support the way their product actually fails. A thin layer connects them.

Ten years ago, Company B's architecture would have been dismissed as unaffordable fantasy.

The question is not whether Company B is feasible today. The question is whether the breakeven point is moving—and whether we have been optimizing for the wrong abstraction while assuming the old economics were laws of physics.

What we are not claiming

We are not claiming monoliths are dead. We are not claiming every team should fragment tomorrow. We are not claiming generic platforms have no place—shared governance, security, and communication will still want a home.

We are claiming something narrower and, we think, more useful:

If AI changes the cost of building and evolving software, it may change what "good architecture" means—not because models got smarter, but because the tradeoffs shifted.

Maybe the goal is no longer one system that does everything adequately for everyone.

Maybe it is many systems that each do one thing properly for their domain—and a shared layer that keeps them honest.

Open question

If specialization becomes cheap, what should we design for: products, or autonomous operational entities?

And if repositories become living systems rather than code containers, what is the new unit of architecture—the service, the agent, the domain entity, or something we have not named yet?

We came to this line of thinking while building intelligent systems and watching the same pattern repeat: the expensive part was rarely typing code. It was fitting reality into generic shapes.

Maybe AI is not only changing how we build software.

Maybe it is changing what software should be.