Modular Isn't Modular: When Extensibility Itself Becomes the Architecture

In an earlier post, we looked at modules that get cut apart so a system stays testable and manageable. But there's a level beyond that: modules that don't just separate cleanly, but can be swapped, extended, and rewired at runtime — without touching the code at all.

A manufacturer of professional testing equipment ran into exactly this problem: the software was stable, had run reliably for years — but every new requirement, like a new device variant, meant touching code and re-testing it. Classic modularization would only have shifted this problem, not solved it, because new requirements would still have meant new programming work.

The idea behind the fix

New functionality isn't programmed in anymore — it's loaded as an independent module at runtime and wired together through a graphical interface. Built concretely as a node editor — a visual workspace where individual functional building blocks appear as boxes and get connected by lines that define the flow of data between them. A new test sequence isn't created through new code, but by rewiring existing building blocks on that surface.

The difference from the classic modularization in the earlier post: there, the goal was to cut an existing system apart so it stays maintainable. Here, the goal is to make extensibility itself part of the architecture — the system changes without the code changing.

What this means for AI-built products

For products built with AI coding tools, this is more than a theoretical idea. As a product grows and needs to support more variants, customer requests, or edge cases, the question becomes real: should every new requirement mean new code and new risk — or can extensibility be built into the architecture from the start?

The answer depends on the product. Not every system benefits from this kind of runtime configurability. But the question is worth asking early — because retrofitting extensibility is significantly harder than designing for it.