Skip to content
Chapter 5 — Agentic Software Factories  ::  §5.1

§5.1 The Software Factory

Earlier in this book, I compared coding agents to 2D and 3D printers. The comparison was about fabricative technology: unlike a specific-purpose tool such as a stapler, a fabricator can realize a broad range of artifacts from a description of what should be made.

We can now expand that metaphor. A fabricator does not operate alone. Once fabrication becomes a means of production, it sits inside a larger system that determines what should be made, organizes how production proceeds, and determines whether what was produced is acceptable. The printer becomes one piece of the factory.

Factories developed to make production repeatable at scales that craft production could not support. Interchangeable parts allowed components made separately to participate in the same product. Mechanization increased the amount of work that machinery could perform. Machine tools increased precision and repeatability. Each advance also exposed a problem. Faster machinery could produce defects faster than people could inspect them; a design was of little use if the available machinery could not realize it accurately; interchangeable parts were not interchangeable if different shops produced incompatible dimensions. Scaling fabrication therefore required engineering the production system around the fabricator.

Two engineering techniques from that history are especially useful for understanding software factories:

  • Process design determines how production proceeds. Work is decomposed and sequenced; responsibilities, machinery, and information are arranged; measurements and decision points occur at selected stages. The process carries knowledge about how production should occur rather than requiring each fabricator to reconstruct it. Scientific management made this separation explicit by moving planning, work methods, instructions, and standards into a deliberately designed production system.11. Frederick Winslow Taylor, The Principles of Scientific Management (Harper & Brothers, 1911).
  • Tolerance states which variation in the product is acceptable. A drawing can specify a dimension and its allowable variation without prescribing every motion of the machinist or every property of the finished part. Gauges and metrology then establish whether selected properties of the realized part fall within those bounds. The factory can therefore leave substantial freedom to the fabricator while retaining control over the properties that matter.22. Simon Winchester, The Perfectionists: How Precision Engineers Created the Modern World (Harper, 2018).
Process design organizes production around the fabricator; tolerance bounds the product One large frame labelled SOFTWARE FACTORY holds two engineering concerns of equal standing, each introduced by a heading over a coloured rule. Across the top, under the heading PROCESS DESIGN — how production proceeds, a dashed band labelled PRODUCTION PROCESS carries a left-to-right path from engineering intent, through context and work, through a box labelled Fabricator, and out to a realization. All four boxes are drawn at the same firm weight: the fabricator is one station among them, not the centre of the picture. A bracket spans the whole path from the first box to the last, and beneath it, set larger than any label on the path, an annotation names what the process design determines: context, tools, routing, authority, sequencing. Below the band, under the heading TOLERANCE — what variation in the product is acceptable, a wide bounded region drawn in the governance colour is labelled ACCEPTABLE REGION. Dots inside it mark distinct acceptable realizations the fabricator may choose among. A measurement arrow drops from the realization to the top of that region, annotated with the mechanisms that establish where a realization falls: tests, property-based testing, analysis, simulation, human judgment. From the region two arrows of equal weight lead out, one labelled within tolerance to admitted change and one labelled outside to revise or reject. SOFTWARE FACTORY PROCESS DESIGN how production proceeds PRODUCTION PROCESS Engineering intent Context / work Fabricator Realization context · tools · routing · authority · sequencing what process design determines measurement tests · PBT · analysis · simulation · human judgment TOLERANCE what variation in the product is acceptable ACCEPTABLE REGION the fabricator may choose among these within tolerance outside Admitted change Revise / reject
Figure 5.1-1. Two problems of factory engineering. Process design determines how production proceeds around the fabricator. Tolerance identifies acceptable variation in what the factory produces; measurement establishes whether a realization remains within those bounds. The two concerns are complementary: a production system may carry engineering knowledge in the organization of production, in explicit bounds on the resulting product, or in both.

A factory must solve both problems: production must proceed at an economically useful rate, and what it produces must remain within the bounds required for the product to work. Together, process design and tolerance allowed production to scale beyond the judgment of a single craftsperson. Watt's improved steam engine provides an early example. The design required cylinders more accurately bored than ordinary eighteenth-century production could reliably make; Wilkinson's precision boring machinery made cylinders sufficiently true for Watt's engine to perform as intended. The advance was therefore not simply a faster way to make an existing artifact. A more capable production system made a different artifact practical. As factories developed, this relationship generalized: some judgment remained with the skilled human fabricator, while other knowledge moved into drawings, tolerances, machinery, gauges, process plans, and inspection. The factory became capable of producing at a scale and consistency that could not depend on one person's judgment being exercised over every part.

5.1.1 What Does a Software Factory Produce?

The analogy requires one adjustment before we apply it to software. A physical factory commonly produces many instances of a product. Software usually does not. Another copy of a program may cost almost nothing, while a software service may consist of one continuously evolving system serving millions of users.

The output of a software factory is therefore not another copy of the product. It is the next working realization of the product. Software organizations repeatedly change an existing system: adding features, repairing defects, adapting to new environments, migrating dependencies, changing architectures, and responding to new requirements. Each production cycle begins with a working software system and attempts to produce a changed system that still works.

The factory's job is therefore to realize controlled change. This is the same object named by the definition of software engineering used throughout this book. As the Glossary states — and the companion Software Engineering Handbook develops more fully — software engineering is the engineering discipline of controlled change in software systems. It creates and evolves software while preserving sufficient control over the properties and consequences that matter.33. James C. Davis, The Software Engineering Handbook: A Judgment and Decision-Making Approach, 1st ed. (2026), https://davisjam.github.io/model-based-agentic-software-engineering/book/se-handbook/index.html. A software factory is the production system through which that change occurs.

Software factory. The engineered production system through which software changes are realized from engineering intent and evaluated, admitted, deployed, and improved.

A factory therefore contains more than its fabricators. Models say what should be made: drawings, process specifications, tolerances. Tools are what the work is done with: jigs position parts, gauges measure them, and fixtures hold them in place. Controls bound what may be done and what may be accepted: a permission a machinist does not have, a quality gate that rejects a part.

Software factories hold all three. Models describe the product: architecture descriptions, service graphs, and the properties a change must preserve. Tools work on it: linters, test harnesses, validators, and analyzers. Controls bound both: permissions, admission gates, and enforced policies. A test is ordinarily a tool — an agent runs it and reasons about the result. It participates in a control when the result carries a consequence the agent cannot reason away: a failing test blocks admission. Fabricators build the product from models, using tools, subject to controls.

Producing changes rather than copies also changes how the two problems of factory engineering apply. Process design organizes the production of changes: how engineering intent becomes work, how that work is decomposed and realized, what information and tools are available to the fabricator, and how a proposed change moves through evaluation and admission. Tolerance constrains the resulting realization: how much freedom the fabricator may exercise while the changed product remains acceptable. The factory does not need to reproduce the same artifact. It needs to repeatedly produce new realizations of an evolving artifact without losing the properties that matter.

That task carries a cost that physical manufacturing can often amortize differently. A drawing for a manufactured part can remain useful across thousands of instances of that part. A representation of a software system describes a target that is itself being changed. Requirements, architecture descriptions, interface specifications, models, tests, and other engineering artifacts therefore incur a carrying cost: as the software changes, they may also have to change if they are to remain useful representations of it.

Software organizations have made different economic judgments about that cost. Some have found enough durable value in explicit models, specifications, interface definitions, and other representations to justify creating and maintaining them; others have found it cheaper to keep skilled human engineers close to implementation, where they can resolve open questions about behavior, structure, interfaces, failure handling, and performance as the software changes.44. Oliver Kautz et al., “Achievements, Failures, And the Future of Model-Based Software Engineering,” in The Essence of Software Engineering, The Essence of Software Engineering, ed. Volker Gruhn and Rüdiger Striemer (Springer, 2018), https://doi.org/10.1007/978-3-319-73897-0_13. Neither choice is intrinsically irrational. The tradeoff depends on how much reusable engineering knowledge a representation carries, how expensive that knowledge would be to reconstruct during implementation, and how expensive the representation is to keep accurate.

The Agile movement placed substantially greater weight on the second approach.55. Kent Beck et al., “Manifesto for Agile Software Development,” 2001, https://agilemanifesto.org/.66. Ken Schwaber and Jeff Sutherland, “The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game,” 2020, https://scrumguides.org/. Working software became the primary measure of progress; changing requirements were expected rather than exceptional; close collaboration was preferred to elaborate handoffs; and documentation was valuable insofar as it continued to serve the work. These choices make particular sense when the object of engineering is controlled change. A representation that does not change with the software can cease to describe the thing it is meant to govern. Keeping knowledgeable humans close to implementation accepts repeated human judgment partly in exchange for avoiding representations whose carrying cost may exceed their continuing value.

Earlier attempts to separate engineering judgment from implementation encountered the same tradeoff from the other direction. Moving decisions upstream could allow implementation to be performed by less experienced programmers, but only if sufficiently detailed requirements, architecture, interfaces, or models carried the judgment that those programmers would otherwise need to supply. Producing those representations required skilled engineering labor, and maintaining them as the software changed added further cost. Leave more decisions open, however, and the organization again needed skilled human fabricators capable of resolving them during implementation.

The economic question was therefore never simply whether software should use models. It was where engineering judgment could be carried most economically without losing control. Craft production remains economical when transferring enough judgment out of fabrication would cost as much as leaving that judgment with the skilled human fabricator. Factory production becomes economical when reusable production structures can carry consequential judgment more cheaply than repeatedly exercising it during fabrication.

Commodity intelligence changes this tradeoff. In an agentic software factory, substantial realization work is performed by agents rather than human engineers. These fabricators are inexpensive and capable enough to resolve many ordinary realization decisions themselves. Engineering therefore need not choose between specifying most decisions upstream and paying skilled human programmers to resolve them downstream. The production system can instead carry selected consequential judgments while leaving substantial realization freedom to the agent.

5.1.2 Walking Through a Software Factory

The factory metaphor gives us a vocabulary for walking through an agentic software production system without assuming in advance how it should be organized. Four questions orient a walkthrough:

  1. What does the factory produce? What kinds of controlled changes enter the production system, and where do they originate?
  2. What do people do? Which judgments remain with engineers, and which acts of realization or decision have been delegated to agents?
  3. How is production organized? What process determines how work is represented, routed, realized, evaluated, admitted, deployed, and learned from?
  4. What are the tolerances? Which properties of the resulting software must remain within bounds, how are those bounds represented, and what evidence establishes that a change satisfies them?

The last question deserves care. In physical manufacturing, a tolerance can often be written as a dimension and checked with a gauge. Software properties are more varied. A tolerance may be a quantitative bound, an invariant, a behavioral requirement, an architectural constraint, a security policy, or another statement of acceptable variation. Some can be checked mechanically. Others still require human judgment. The engineering question is the same: what variation may the fabricator choose, and what variation must the factory control?

Those questions are deliberately broader than MAGE. A factory may answer them with tests, policies, human review, simulators, permission systems, or models. §5.2 applies them to DocAble, where the production system can be observed longitudinally as realization capacity grows. §5.3 asks the same questions of independently developed industrial systems. Only after seeing those factories will we ask what their different arrangements imply for engineering under abundant realization.

Works Cited

  1. Taylor, Frederick Winslow. The Principles of Scientific Management. Harper & Brothers, 1911.
  2. Winchester, Simon. The Perfectionists: How Precision Engineers Created the Modern World. Harper, 2018.
  3. Davis, James C. The Software Engineering Handbook: A Judgment and Decision-Making Approach. 1st ed. 2026. https://davisjam.github.io/model-based-agentic-software-engineering/book/se-handbook/index.html.
  4. Kautz, Oliver, Alexander Roth, and Bernhard Rumpe. “Achievements, Failures, And the Future of Model-Based Software Engineering.” In The Essence of Software Engineering, The Essence of Software Engineering, edited by Volker Gruhn and Rüdiger Striemer. Springer, 2018. https://doi.org/10.1007/978-3-319-73897-0_13.
  5. Beck, Kent, Mike Beedle, Arie van Bennekum, et al. “Manifesto for Agile Software Development.” 2001. https://agilemanifesto.org/.
  6. Schwaber, Ken, and Jeff Sutherland. “The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game.” 2020. https://scrumguides.org/.
© James C. Davis, 2026–present