From Software Factories to Semantic Systems

Software engineering advances by changing what people have to author directly. Machine instructions gave way to symbolic programs, then languages, libraries, managed runtimes with garbage collection, frameworks, platforms, and models. Each wave let developers state more of what they wanted while delegating more of how it would happen.

Software factories were an ambitious step in that progression. They tried to capture reusable production knowledge in domain-specific languages, product-line assets, frameworks, generators, and tools. Their critics correctly saw the danger: a model can become another brittle artifact, a generator can become an opaque authority, and a factory can optimize the production of systems without helping those systems remain intelligible as they evolve.

AI changes the balance again by producing system artifacts without requiring every variation to be anticipated in a code-generation pipeline. As implementation becomes cheaper, authorship moves toward authoritative semantic artifacts: the system's semantic commitments. These commitments state what exists, how it may behave, what must remain true, who holds authority, and which operational properties each realization must preserve.

The Authored Boundary Keeps Moving

The familiar history of software is often told as a ladder of increasingly powerful notations. The crucial property of each rung is the transfer of responsibility it enables: something below accepts responsibility for the details that the programmer no longer writes.

Assemblers resolve symbolic names into addresses and instructions, while compilers select instruction sequences and representations. Databases assume responsibility for storage, indexing, concurrency, and recovery under a declared recovery model; cloud platforms handle placement, restart, routing, and scaling. Across these layers, abstraction precisely reassigns responsibilities among system participants.

Seen as a working boundary, the ladder becomes a rising sea. Machine instructions remain below the surface established by high-level languages. Each new layer lets most developers reason above that surface while specialists retain access to the machinery below.

Abstraction boundaries remain permeable. Systems programming exposes memory layout, databases allow physical design, and frameworks provide escape hatches into lower layers. Each abstraction marks a negotiated transfer of control while preserving routes across the layers when the work demands it.

The Rising Sea of Responsibility

Garbage collection is a particularly clean example. It did not make object lifetime, heap pressure, or reclamation disappear. It transferred the ordinary proof of when memory could be reclaimed from each application author to a language runtime and collector.

That transfer changed what programmers could safely assume. They could compose object graphs and return references without threading explicit deallocation through every interface. The runtime paid for that freedom with tracing, generations, barriers, compaction, pauses, and new failure modes. As the LLVM documentation puts the responsibility plainly, garbage collection belongs to the language's runtime rather than LLVM itself.

Choosing automatic memory management delegates these responsibilities to the runtime, so the abstraction boundary must state them clearly.

Designers can delegate work clearly only after they understand it deeply enough to name its governing concepts. Manual implementations often leave those concepts tacit or scattered across local decisions. A reusable abstraction must formalize what moves to another participant, what stays with the application, and which guarantees hold at the boundary.

Cohesive makes semantic obligations explicit, then delegates their implementation to compilers, runtimes, infrastructure, and agents that can be checked against them.

The Factory Ambition

Software factories tried to apply this logic at the scale of system families. Repeatedly constructing similar systems by hand wastes more than keystrokes; it wastes production knowledge. Factory approaches sought to capture that knowledge in reusable forms that could guide the construction of each member of a system family.

Software factories brought together ideas and mechanisms from domain-specific languages, model-driven engineering, software product lines, application frameworks, code generation, templates, configuration systems, and integrated tooling. Together they support the ambition of capturing the stable structure and meaningful variation of a system family so that systems within the family can be produced consistently.

The Software Engineering Institute describes a product line in terms of common assets used in a prescribed way, supported by a production plan. Its product-line framework makes clear that the assets are not only code. They include architecture, components, tests, tools, processes, and organizational capabilities.

That is the enduring insight of the factory idea:

• A system is produced from more knowledge than appears in its source files.
• Variation should be explicit rather than scattered across forks and conditionals.
• Frameworks and platforms embody architectural decisions whether or not those decisions are modeled.
• Production rules can preserve consistency across code, schemas, configuration, tests, and deployment artifacts.
• A family of systems can justify richer tools and languages than a single application can.

Once factories elevated reusable production intent, teams had to decide what the durable model should contain and how it would survive contact with an evolving system.

The Limits of the Factory Model

Some pushback against software factories and model-driven development came from familiar resistance to working at a higher level of abstraction. Projects also encountered high upfront costs, specialized toolchains, awkward generated code, model-code drift, and models that were either too generic to be useful or too narrow to survive the next requirement.

The factory model also changed how authority and responsibility were distributed. It can concentrate design authority in the team that owns the generation pipeline while leaving other teams dependent on its outputs. When the generated system misbehaves, the people responsible for it may be forced to debug an artifact they were discouraged from understanding or changing.

Industry studies describe partial, incremental adoption. Whittle, Hutchinson, and Rouncefield found that practitioners commonly applied model-driven engineering to important parts of systems instead of attempting whole-system generation. Their state-of-practice report and related industrial case studies emphasize integration with existing work, clear business purpose, and organizational change alongside improvements in modeling tools.

Any successor to the factory model must incorporate these lessons into its design.

A successor to the factory model therefore needs a durable account of system meaning that can accept new commitments without losing the meaning already established.

That account should remain reproducible rather than becoming another hand-edited model. People and agents author modular semantic artifacts. A mechanical compiler parses them, resolves their identities and dependencies, and accumulates them into persistent graph state. Given the same artifact set, compiler version, configuration, and declared inputs, the result must be the same. Probabilistic tools can propose source changes, but they stay outside that boundary.

The language also needs somewhere safe to evolve. A small kernel should contain constructs whose composition and analysis are sufficiently understood. New or domain-specific constructs begin in a periphery with explicit lowering rules and assurance limits. Promotion follows repeated use and evidence. Migration between vocabulary versions becomes a semantic operation with compatibility diagnostics, not a global textual rewrite whose meaning is assumed to survive.

Software Is Evolved, Not Manufactured Once

The factory metaphor is strongest at the moment of production: assets enter, rules are applied, and a product emerges. Long-lived software spends relatively little of its life at that moment. It is interpreted, operated, repaired, extended, migrated, and renegotiated in an environment that changes around it.

M. M. Lehman's account of E-type programs—software embedded in and judged by a real-world activity—makes evolution intrinsic rather than exceptional. His laws of software evolution describe continuing change and increasing complexity as persistent pressures on useful systems. The exact formulations have been refined and debated, but the central observation remains: successful software and its environment continually act on one another.

When production is one event in a much longer system life, the semantic source and its accumulated model must describe continuity and change as well as construction.

A traditional factory asks how to produce another member of a known family. A durable system model must also preserve identity and conceptual integrity while the family, the product, the production machinery, and the environment all change. It needs versioned claims, explicit compatibility and evolution, semantic deltas, migration relationships, and evidence about whether current realizations still conform.

Production automation becomes one phase in a larger lifecycle, consuming the same meaning used for analysis, migration, verification, agent context, operation, and conformance.

AI Raises the Waterline Again

Traditional generators encode a bounded family, producing known artifacts from defined inputs and extension points. AI expands that range by inferring local patterns, adapting to unfamiliar repositories, translating between conventions, and synthesizing variations that the factory author never enumerated.

AI can therefore accept implementation responsibility across a much wider range of variation. That transfer increases the need for an explicit account of the system being changed, the intent of the change, and the authority under which it may proceed.

As argued in Commoditizing Determinism, AI lowers the cost of syntax, scaffolding, and local change while increasing the relative value of trusted system understanding. A model can use local context to produce plausible code. Authority for resolving contradictory artifacts, identifying intentional invariants, generalizing exceptions, or approving changes must come from accepted system knowledge.

The old factory bottleneck was the cost of anticipating and encoding variation. AI relaxes that bottleneck. The new bottlenecks are comprehension and intent specification:

Weak comprehension leaves intent underspecified, forcing each implementation agent to reconstruct policy from local clues. A durable model breaks the loop by accumulating understanding and expressing new intent as a delta over accepted meaning.

Once a change has been accepted, realization becomes a governed search for mechanisms that satisfy it. AI can produce candidates, while capability matching, verification, provenance, and conformance determine whether those candidates are suitable.

The Next Authored Artifact

As successive abstractions move more implementation out of direct human authorship, deciding what the system means becomes central.

That meaning includes:

These commitments outlive any particular class hierarchy, framework, database, cloud, interface, or generated patch. They are the stable subjects against which implementations can vary and evolution can be reviewed.

The next abstraction is the definition of the system as a connected set of semantic commitments. People and agents author those commitments through appropriate system languages, whose modular artifacts accumulate into a shared graph and can be interpreted into many realization artifacts.

A semantic system gives its accepted meaning durable, versioned source and maintains assurance-graded correspondence between accumulated semantic state and the artifacts that realize it. Some correspondences can be verified or derived; others are test-backed, declared, assumption-dependent, or opaque.

The semantic definition gains effect through concrete artifacts. Infrastructure runs code and stores data, interfaces mediate human action, and AI proposes or implements changes. Each implementation artifact is a projection of the semantic definition. Runtime observations and verification results provide evidence that realizations support their advertised capabilities.

Making semantic commitments first-class requires a representation that can connect their identities, relations, versions, mappings, and evidence. Cohesive calls the complete, connected, versioned model of these commitments, mappings, and evidence a semantic system graph.