We Built Lego Bricks for People. That Was the Wrong Customer.
The case for reusable code just collapsed. The case for composable architecture just got stronger.
Not long ago, our team was running our first experiments with spec-driven development. We wrote plain English requirements into a structured specification and watched the computer generate working code almost immediately. It was the kind of moment that stops you mid-thought.
My first reaction was the obvious one: this is fast. My second reaction was the one that stuck: if code can be generated this easily from a spec, does the code itself matter anymore? That question pulled a thread that unraveled something we had spent years building carefully: our composability strategy.
The Original Argument
The composability argument we made, and the one most product and data organizations made, rested on a simple economic premise: writing code is expensive, so write it once and reuse it everywhere.
You simply need to build one pricing service, one inventory availability service, and one consumer identity resolution service. Now any product team, any new solution, any new customer use case can assemble these blocks into something new without rebuilding from scratch. Velocity goes up, duplication goes down, and everyone wins.
This is the Lego metaphor. You invest in a good set of bricks so that builders can make anything they want, faster.
The mistake was hiding in plain sight because we were optimizing for human assembly speed. We assumed the bottleneck was the cost of generating an implementation. And for more than twenty-five years, that assumption was correct. Then it stopped being correct almost overnight.
The Assumption That Broke
Don’t worry, AI code generation has not made composability less important. It has, however, made our original justification for composability mostly irrelevant.
When AI can generate a working implementation from a well-written specification in minutes, the “build once, reuse many times” argument loses most of its force. The bottleneck is no longer the keystrokes. It is now the understanding. Domain knowledge, design decisions, and intent matter.
The reframe that changed how I think about this is straightforward:
Code is increasingly the output of your strategy, not the artifact of it. The specification, the interface contract, and the bounded context are the durable things. The implementation is disposable.
ThoughtWorks’ 2025 Technology Radar specifically identifies spec-driven development as an emerging standard where the specification is the maintained artifact and code is generated and regenerated from it. Andreessen Horowitz described the shift bluntly that code is becoming “more like a compiled artifact than a manually authored source.”
If that is true, and the evidence says it increasingly is, then a composability strategy organized around code reuse is optimizing for the wrong constraint.
The New Customer for Your Architecture
The primary consumer of your composable interfaces is no longer a human developer. It is an AI agent.
Anthropic’s Model Context Protocol (MCP), Google’s Agent-to-Agent Protocol, and the Open Semantic Interchange initiative (backed by Snowflake, Salesforce, dbt Labs, and a dozen others as of late 2025) are all establishing standards for how AI agents discover, invoke, and compose over well-defined service interfaces. These are composability standards built for machine consumption, not human convenience.
When an AI agent tries to answer a business question, it does not read your documentation or intuit your domain model. It hits your interfaces. When those interfaces are clean, bounded, and semantically rich, the agent produces correct, reliable output. If they are ambiguous, monolithic, or semantically thin, the agent hallucinates. Research from Apiiro quantified a 153% increase in design problems in AI-generated code, correlating directly with architectures that lack clear boundaries. Not syntax errors… design problems.
Your composable architecture used to be a developer experience investment. It is now an AI reliability investment.
What Changes and What Stays the Same
When I stress-tested our original strategy against this, a new purpose emerged.
What we were right about: Bounded contexts, API-first design, and separation of concerns are more important than ever (just not because they help developers assemble faster). Instead, they help AI agents operate correctly. Harvard researchers published experimental evidence in 2025 showing that LLMs without architectural constraints produce “architectural mimicry without adherence” (code that looks modular but violates boundaries internally). With enforced constraints, output quality improves dramatically. The boundary is a correctness mechanism as much as it is an organizational one.
What we were optimizing for incorrectly: Code-level reuse metrics (such as: how many times a module gets called or how much duplication got eliminated), are the wrong scorecard now. The better metric is interface stability. You might consider looking at how rarely your contracts change, and how many different consumers, (both human and AI) can compose against them without modification.
What we were missing entirely: Semantic layers. If your domain definitions (what a “customer,” a “price,” a “transaction” means in your business) live inside monolithic systems or under-documented schemas, AI agents cannot reliably access them. The OSI initiative exists precisely because this gap is universal. Your semantic layer is no longer a BI convenience that belongs in debates with human analysts. It is the composable interface your AI strategy now requires.
Where This Lands
Old composability thesis: Build reusable blocks so humans can assemble solutions faster.
New composability thesis: Build governed interfaces so both humans and machines can compose reliably against your platform.
The blocks are still there and the investment in modularity is still justified. But the customer has changed, the scorecard has changed, and the artifacts that matter have changed. The specification is the new source code, and the semantic layer is the new infrastructure.
What To Do About It
If you’re a product or business leader
Audit what your composability investment is actually optimizing for. Pull up the original business case or reconstruct it. If the core argument was “build once, reuse everywhere to accelerate development,” that argument has weakened significantly. If it was “govern our platform so we know what’s running and can enforce standards,” that argument has strengthened. Know which camp you’re in before deciding what to change.
Ask your team one question: “If an AI agent needed to answer a business question using our platform today, what would it hit?” Would it find clean, bounded, semantically defined interfaces or raw schemas it has to guess the meaning of? The answer reveals more about your AI readiness than any roadmap review.
Reframe “reuse” in your investment language. If your teams are still being measured on module reuse rates or duplication reduction, those metrics will steer them wrong. The goal is no longer avoiding redundant code. It is ensuring your domain knowledge is expressed in stable, machine-readable forms. Fund interface governance the way you used to fund shared libraries.
If you’re a data practitioner
Treat your domain definitions as versioned, governed artifacts rather than documentation. Whatever canonical concepts power your business (your “customer,” your “deal,” your “price”), those need to exist as machine-readable, authoritative specifications. A wiki page is not enough anymore. If an AI agent cannot programmatically discover what your organization means by a core concept, that gap will show up as hallucinations in production.
MCP connectivity is table stakes. Semantics is the real problem. By mid-2025, every major data warehouse had shipped or announced Model Context Protocol support, so connectivity is no longer the gap. The problem is that MCP gives AI agents a door into your platform, but if your semantic definitions are thin or missing, the agent walks into an unlabeled warehouse. A protocol without semantics is just faster confusion at scale. The investment that matters is not “can an agent reach our data” but “when it does, does it find authoritative definitions of what that data means.” Most teams are not having that conversation yet.
Shift your architecture metrics from reuse to stability. Count how rarely your interfaces change and how many consumers can compose against them without modification. A stable, well-specified interface an AI agent can reliably invoke is worth more than a cleverly reused implementation. That reorientation sounds subtle, but it will change which technical decisions you advocate for.
Composability was never really about the bricks. It was about making complex systems understandable, governable, and changeable. AI has made that mission more urgent. We just needed to update our mental model of who is doing the assembling.