From Software Factories to Semantic Systems

Software engineering advances by changing what people author directly. Machine instructions gave way to languages, libraries, managed runtimes, frameworks, and platforms. Each layer accepts more implementation work so developers can work with higher-level concepts.

Software factories tried to extend that idea across whole families of systems. They captured common structure and planned variation in models, generators, frameworks, and reusable assets. The ambition was sound. The durable artifact often was not.

That history is the focus here. The factory metaphor also applies to contemporary workflows where agents coordinate implementation, tests, review, and delivery. Those workflows can use semantic source as an input and retain it for future changes. The practical relationship between Cohesive, factories, and coding harnesses is covered in Where Cohesive Fits.

AI changes the boundary again. It can produce implementation without every variation being anticipated by a generator. That makes accepted system meaning more important: what exists, what may happen, what must remain true, who holds authority, and which properties each realization preserves.

The Authored Boundary Keeps Moving

Every abstraction transfers responsibility. A compiler chooses instructions and representations. A database handles storage, concurrency, and recovery within a declared model. A cloud platform handles placement, restart, routing, and scaling.

The details remain real. They move below the boundary most application authors work above. Specialists still cross that boundary when performance, failure, or target-specific behavior demands it.

A useful higher-level language therefore does more than hide detail. It names the responsibility being transferred, the guarantees at the boundary, and the conditions under which lower-level control remains available.

That transfer also changes how developers encounter architecture patterns. Which Architecture Patterns Survive AI? examines which pressures persist as their implementations move into tooling.

What Factories Got Right

Software factories recognized that a system is produced from more knowledge than appears in its source files. Architecture, tests, production rules, frameworks, tools, and organizational practice all shape the result.

The Software Engineering Institute describes a product line through shared assets used according to a production plan. Its product-line framework includes architecture, components, tests, tools, processes, and organizational capabilities alongside code.

Three ideas remain useful:

• Capture recurring production knowledge instead of rebuilding it from memory.
• Make meaningful variation explicit instead of scattering it across forks and conditionals.
• Keep generated code, schemas, tests, configuration, and deployment artifacts connected to the decisions that produced them.

Factories made those ideas concrete with domain-specific languages, product lines, generators, and integrated tooling. They showed that a family of systems can justify a richer language than one application can.

Where Factories Stalled

The factory model works best when variation is known in advance. Long-lived software rarely stays within that boundary. New requirements expose assumptions the model did not contain, while generated and hand-written code evolve at different speeds.

Teams also encountered high setup costs, specialized toolchains, model-code drift, and generated artifacts that were difficult to understand or change. A central generator team could accumulate design authority while the teams responsible for operating the software depended on outputs they did not own.

Industrial studies of model-driven engineering found more success in focused, incremental use than in whole-system generation. The state-of-practice report and related case studies emphasize clear business purpose, integration with existing work, and organizational change.

The successor to a factory model needs different properties:

Software Evolves

A factory metaphor centers the moment of production. Useful software spends most of its life being interpreted, operated, repaired, extended, and migrated. Its environment also changes.

M. M. Lehman's laws of software evolution describe continuing change and increasing complexity as persistent pressures on systems embedded in real activity. Production is one step in that longer life.

A durable source model therefore preserves identity across change. It records semantic revisions, compatibility relationships, migrations, and evidence that current realizations still support accepted intent. The same meaning can guide generation, analysis, agent context, operation, and conformance over time.

AI Moves the Boundary Again

Traditional generators produce a known family from defined inputs. AI adapts to unfamiliar repositories, local conventions, and variations that no factory author listed ahead of time. It accepts a wider range of implementation work.

That flexibility does not decide what the system is allowed to mean. Code, documents, tickets, and runtime evidence may be incomplete or contradictory. An agent can infer a plausible model and propose a change. Accepted intent, authority, and constraints still need a durable source.

This creates two uses for agents. In agentic development, agents help understand and change the system. In agentic interaction, agents act through the system's declared surfaces while it runs. Both depend on the same identities, rules, authority, and evidence.

As Commoditizing Determinism argues, cheaper code moves value toward trusted change. AI expands the search for possible implementations. Deterministic tools check accepted definitions and supported realizations.

The Next Authored Source Is Semantic

The next authored layer describes the system as connected semantic commitments:

These commitments outlive a class hierarchy, framework, database, cloud, user interface, or generated patch. People and agents edit readable, modular Cohesive artifacts. A mechanical compiler resolves their identities and dependencies into a shared semantic system graph.

The graph connects accepted meaning to code and infrastructure without collapsing them into the same thing. Some mappings are derived or verified. Others are test-backed, declared, assumed, or opaque. Those differences remain visible.