The AI Factory versus the Software Factory

1. Introduction

The subject of this paper is a regulated financial institution — a bank, an insurer or an asset manager — in the EU, the UK or Switzerland that is building an AI factory: the organisational and technical capability that delivers AI applications repeatedly from shared, governed parts. The reader I have in mind runs technology for such a firm and has been told, more than once, that software is about to be manufactured.

That promise is old. The phrase “software factory” dates from 1968, and the fifty-eight years since contain one clear organisational failure, one long partial success in Japan, a tooling wave that under-delivered twice, and two descendants that survive in bounded form. I read that record for its failures, not as a template. The firms where the factory worked were building families of similar systems against stable requirements, which is not what the application estate of a bank or an insurer looks like.

The thesis is this. Every earlier wave industrialised everything around construction — tools, methods, reuse libraries, environments, the path to production — and left construction itself to engineers who were scarce, expensive and not interchangeable. Coding agents change that one input. Construction capacity now follows a budget line and not a hiring pipeline. The consequence is that the constraint on delivery moves: to the capacity to verify that plausible output is correct, and to the supply of validated things worth building. The record also says how such a factory fails, because each historical failure has a descendant that can be named today.

What is evidence and what is argument. Section 2 is evidence. Sections 2.1 to 2.5 report the historical record and say who documented it; section 2.6 reports what has been measured about AI-assisted delivery between 2024 and 2026. Section 3 is my argument. Within it, section 3.5 maps historical failures onto the AI factory and is the part I would defend hardest; section 3.6, on product management and portfolio shape, is conjecture and is labelled as such. Section 4 turns the argument into actions. Section 5 states what the paper does not establish.

Terms. A coding agent is an AI system that reads a task, changes code, runs checks and corrects itself, under the supervision of a named person. A specification is a written statement of intent precise enough to be tested. Context assets are the governed material agents read before they work: the machine-readable inventory of what each product contains, the versioned templates from which a class of application is assembled, the instruction files kept in each repository, recorded architecture decisions and machine-readable design rules. The application foundation is the firm’s sanctioned base for internal applications — identity, logging, deployment and controls already wired in. “The DORA research programme” means the Google-owned DevOps Research and Assessment body of work, not the EU regulation that shares the acronym.

2. Background and evidence

2.1 The term, and the first attempt: 1968 to 1978

The term does not begin with System Development Corporation, although it is often dated from there. Cusumano’s historical overview credits two people in 1968. R. W. Bemer, an engineer at General Electric, wrote a paper that year urging the company to develop a “software factory”; GE left the computer business in 1970 [2, p. 9] [3]. At the NATO Software Engineering conference in Garmisch in October 1968, M. D. McIlroy of AT&T made the mass-production argument in a paper titled “Mass Produced Software Components”. Its first section is headed “The Software Industry is Not Industrialized”, and it opens: “We undoubtedly produce software by backward techniques.” McIlroy proposed a components industry offering families of routines, and was careful about the metaphor: “In the phrase ‘mass production techniques,’ my emphasis is on ‘techniques’ and not on mass production plain” [1]. Hitachi founded its Software Works the following year, 1969, and was, on Cusumano’s account, the first company in the world to apply the word factory to a software facility; the Japanese kojo can be translated as “factory” or “works” [2, p. 27].

System Development Corporation (SDC) built the first facility in the United States to carry the name. Bratman and Court described the design in 1975: an integrated set of development tools and standard procedures intended to make development disciplined and repeatable [4]. The facility opened in Santa Monica in December 1976 with about 200 programmers, took roughly ten major projects between 1976 and 1978, and lapsed in 1978 [2; 5, pp. 2, 30]. Its organisation separated system design, done by program offices close to the customer, from programming, done centrally: the program office handed its specifications to the factory, where three groups worked on them in sequence [5, pp. 20–22].

The usual summary is that the tools worked and the organisation rejected them. Cusumano’s account is less tidy. He names three problems as the main causes of the dissolution: imbalances in the work flowing into the factory, which made it hard for management to justify; difficulties “both political and technical in nature” introduced by matrix management; and cultural resistance from managers and workers alike [5, p. 44]. Program managers were not required to route their work through the factory and many chose not to [5, p. 49]. Programmers disliked being responsible for a design and then passing it on [5, p. 52]. The word itself was a liability: one manager recalled that “factory” became anathema to managers and programmers alike, and Munson, the manager most identified with the factory, said programmers tended to take it “as being a slur on their professionalism” [5, p. 54]. There was also real technical trouble. Customers ran different machines, and tools and reusable code did not travel between them. One manager is quoted: “We never did solve the problem of heterogeneous hardware, and the fact that tools weren’t very portable”; another said that because machines changed from project to project it was very difficult to reuse code [5, pp. 39–40]. Cusumano’s overview states that the lack of tool portability was one reason SDC’s senior executives lost interest [2, p. 24]. The fair statement is that the factory failed on work flow, on organisation and on portability together, and that Munson rated the political and organisational issues as equal in importance to any other [5, p. 50].

2.2 The factories that lasted: Hitachi, Toshiba, NEC, Fujitsu

The idea lasted longer in Japan. The dates need care, because they are often quoted as founding dates when they are not. Hitachi’s Software Works dates from 1969. Toshiba’s Fuchu Software Factory opened in 1977 [6, p. 5]. NEC’s 1976 date is the start of its Software Strategy Project, which followed a basic software division founded in 1974; it is not the founding of a factory. Fujitsu set up a Software Conversion Factory department in 1977 and a Software Factory Department at Kamata in 1979 [2].

Cusumano’s Japan’s Software Factories (1991) is the most detailed empirical study of these organisations that I know of [8]. I have not been able to consult the book for this paper and rely on the working papers from which it was built [2, 5, 6, 7]. They describe facilities that standardised methods, tools and training, managed reuse as an explicit programme with targets, and concentrated on routine designs across similar projects [2]. Cusumano places this within a broader argument that a “flexible factory” pursues “semi-customization and economies of scope as much or more than scale”: productivity comes from reusing designs and components across a range of products, not from volume in one [7, pp. 1, 24–25]. The phrase “economies of scope” is his.

The best-documented figures are Toshiba’s, and they should be reported exactly. The Fuchu factory had 2,300 personnel at the end of 1986 and was, in 1987, “probably the largest dedicated software facility in the world” [6, pp. 2, 58]. Nominal output rose from 1,390 lines per programmer per month in 1976 to about 3,100 in 1985, measured in equivalent assembler source lines, a unit some five to six times larger than a count of source lines. Of the 1985 figure, 48% was code reused from other programs [6, pp. 40–41; 2, p. 34]. Two qualifications sit beside those numbers in the same source. Gains slowed sharply: output per programmer rose 70% in the factory’s first five years and only 8% between 1981 and 1985. And the factory’s architect, Yoshihiro Matsumoto, described a practical ceiling on reuse of about 50% [6, pp. 40, 42]. These figures show nominal output per programmer more than doubling over a decade in which reuse was the declared programme. They do not say that reuse halved the cost of construction, and I draw no cost conclusion from them.

Reuse was enforced through measurement. Project managers were given productivity targets that Matsumoto said were “not attainable” without reusable modules; staff had to register a set number of reusable modules each fiscal term and were evaluated against reuse targets [6, p. 51; 2, pp. 36–37]. Cusumano also records that Toshiba treated one of its productivity measures as imprecise because programmers did not accurately distinguish new code from reused code [6, p. 37]. Training was heavy: every new employee attended full-time classes for the entire first year [6, p. 58]. At the same time Cusumano’s own conclusion lists the deskilling of operations among the features of the approach [2]. The record therefore does not settle whether these factories raised or lowered the skill of the individual engineer, and I do not lean on it either way.

The domains matter. These factories built industrial control, telecommunications and custom applications with high similarity between projects. They did not spread to packaged products or, later, to the internet, where requirements changed too fast for the stable-inputs assumption to hold. That last sentence is my reading of what happened next and not a finding of Cusumano’s.

2.3 The tooling detour: CASE, MDA and Microsoft’s Software Factories

The 1980s and 1990s looked for factory economics in tools. Computer-aided software engineering promised that modelling environments would generate the code. The Object Management Group’s Model Driven Architecture repeated the attempt with UML as a universal modelling language. Martin Fowler’s critique of February 2004 dismissed the platform-independence claim, doubted that drawing sequence or activity diagrams was as good as writing code in a modern language, and observed that CASE tools had failed because they “couldn’t come up with a coherent programming environment” [9].

Microsoft’s attempt is the closest ancestor of the AI factory. Greenfield and Short’s Software Factories (2004) proposed assembling applications from patterns, frameworks and tools, with domain-specific languages and models, deliberately not general-purpose UML, as the means of automation [10]. The architecture of the idea was sound: put the domain’s constraints in a machine-readable form and generate the repetitive construction from it.

What happened to the products can be stated from Microsoft’s own pages. The Domain-Specific Language Tools shipped in Visual Studio and are still documented for Visual Studio 2022: a project wizard, a graphical designer for a language definition, a validation engine and a code generator [11]. The larger modelling effort did not survive. In October 2007 Microsoft introduced “Oslo” as “a set of technical investments to apply model-driven principles to building applications and services”. In September 2010 the company announced that it would not bring the Oslo repository or its visual tool, “Quadrant”, to market, while continuing to invest in the “M” language [12].

Why the software-factories programme did not become mainstream practice is a matter of interpretation, and what follows is mine. I think it was killed by meta-cost. Every domain needed its language designed, its tooling built, its generators written and all of it versioned, and that cost more engineering time than the generation saved except in narrow and stable domains. The abstraction also belonged to the tool vendor, so a firm’s investment depended on a roadmap it did not control. The Oslo announcement shows the second half of that happening. For the first half I have no published cost data, only the observation that the tools existed and were not widely used to build factories.

2.4 The discipline that survived: software product lines

While the tooling wave rose and fell, the Software Engineering Institute codified the organisational version of the same idea as software product line engineering: a managed set of core assets — architecture, components, test infrastructure — from which a family of related products is derived. Its Framework for Software Product Line Practice, version 5.0, describes the practice areas [13], and Clements and Northrop’s book carries an earlier version with case studies [14].

The classic case is CelsiusTech Systems, a Swedish builder of shipboard command-and-control systems, documented by Brownsword and Clements in 1996 [15]. The figures in that report are CelsiusTech’s own and are large. Systems of 1 to 1.5 million lines of Ada were delivered with software accounting for about 20% of system cost, against 65% for similar systems not built as a product line (p. 2); the report later puts it as an inversion of the software-to-hardware cost ratio from 65:35 to 20:80 (p. 69). On average 70–80% of each system consisted of components used verbatim (p. 12). The report gives no single figure for improvement in delivery cost or time, and the common “order of magnitude” summary is not in it. What it shows on schedule is more instructive. The first system ran almost nine years and the second about seven, “not dissimilar” to the firm’s previous system built the conventional way; neither showed greater productivity on its own, but the two were built, with the shared assets, by roughly the staff of a single project. Only the later ships show sharply shorter schedules (pp. 11–12). The price was “a formidable initial investment in time and capital” (p. 2), and the capability “took many years to develop” (p. 17).

Product lines worked where a firm could commit to a bounded domain, a stable architecture and a standing organisation that owned the core assets. The documented successes are concentrated in embedded systems, defence and product companies, though not confined to them: the SEI framework itself mentions a company of about fifty people building a product line of information systems [13]. My judgement is that the approach saw limited take-up in enterprise IT because the up-front investment needs a stability of portfolio that enterprise IT rarely has.

2.5 The descendant in production today: platform engineering

Platform engineering carries the idea forward with two amendments. The platform is a product with users and not a mandate with subjects. And it industrialises the path through delivery — provisioning, integration, deployment, compliance checks — and leaves construction to the product team.

The evidence for it is positive but mixed, and it is survey evidence. The DORA research programme’s 2024 report found that using an internal developer platform “improves individual productivity, team performance, and overall organizational performance”, and that it “can also lead to decreased change stability and throughput” [16]. The 2025 report states that 90% of organisations have adopted at least one platform and reports “a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI” [17]. So the lineage stood, when agents arrived, with nearly everything around construction industrialised and construction still done by hand.

2.6 What has been measured about coding agents so far

The evidence on AI-assisted delivery is recent and thin. Four findings bear on this paper.

The DORA research programme’s 2024 report estimated that a 25% increase in AI adoption was accompanied by a 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability [16]. Its 2025 report, drawing on nearly 5,000 survey responses, found that the throughput relationship had turned positive while AI adoption “does continue to have a negative relationship with software delivery stability”. The announcement of that report states the mechanism its authors propose: “AI accelerates software development, but that acceleration can expose weaknesses downstream”, and “without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability”. It also reports that 30% of respondents had little or no trust in AI-generated code [17]. These are associations in survey data.

METR’s randomised trial of 16 experienced open-source developers on 246 issues found that with the AI tools of early 2025 they took 19% longer, having forecast a 24% speed-up, and afterwards believed they had been 20% faster [18]. METR now labels those results out of date. Its February 2026 update reports estimates of −18% for returning developers and −4% for new ones, with confidence intervals reaching +9%, and calls the new data “an unreliable signal” because of selection effects [19].

GitClear’s analysis of 211 million changed lines written between January 2020 and December 2024 reports cloned lines rising from 8.3% of changed lines in 2021 to 12.3% in 2024, and lines associated with refactoring falling from 25% to under 10% [20]. This is one vendor’s data set.

Read together, these findings are consistent with the first half of my thesis: more change is being produced, and stability and maintainability are where the cost appears. They do not establish it. None of them measures review capacity directly, and none of them says anything about discovery. As of November 2026 I know of no multi-firm, multi-year study of agent-driven delivery comparable to Cusumano’s study of the Japanese factories.

3. Analysis

Everything in this section is argument unless a source is cited.

3.1 Why every earlier factory under-delivered: the missing worker

A factory earns the name from three properties: interchangeable inputs, a repeatable transformation, and capacity that can be added. Software delivery achieved the first two in bounded domains; that is what Toshiba’s reuse programme and CelsiusTech’s product line did. It did not achieve the third. Construction ran through engineers whose capacity grew only by hiring, whose skills were not interchangeable and whose cost dominated the rest.

Each wave therefore industrialised around the constraint. SDC standardised the tools around the engineers. Hitachi and Toshiba standardised the methods and the reuse libraries around the engineers. Greenfield and Short tried to compile the engineers’ domain knowledge into languages, the most direct attack on the constraint, and on my reading the compiler cost more engineer-hours than it saved. Platform engineering is candid about its scope: it industrialises the path and gives the engineer a better bench.

Brooks explained in 1987 why the constraint held. “No Silver Bullet” separates the accidental difficulties of software, which attend its production, from the essential ones, which lie in specifying, designing and testing the conceptual construct itself, and argues that no single development promises an order-of-magnitude improvement because the essence resists mechanisation [21]. My summary of the lineage is that each wave attacked accident and was sold as an attack on essence.

3.2 What is different this time, and what is not

Three things are different. I mean three and not “everything”.

The labour supply. A coding agent is the first construction worker in this lineage whose capacity is elastic, in that it scales with spending and not with recruitment, and largely interchangeable, in that any agent given the same context can pick up the same specified task. A code generator executes a transformation someone has already encoded. An agent reads intent, acts, observes the result and corrects. That is a different kind of input, and the rest of this paper follows from it.

The cost of a change. I do not claim that agent construction is free or nearly so. Token spend is a material budget line, and the 2025 trial evidence does not show that agents make experienced engineers faster on code they know well [18]. The narrower claim is that the cost of producing a candidate change no longer scales with headcount, so the cost of a governed change tends towards the cost of specifying it, verifying it and running it. Reproduction becomes cheap enough that a failed attempt can be discarded and regenerated from the specification, which makes the specification, and not the code, the asset worth keeping. No earlier wave had that property.

The cost of the abstraction. The domain-specific-language approach required a language, tooling and generators per domain. The AI factory’s “language” is structured natural language plus context assets. These cost real effort and return little at first. They are still far cheaper than building a language, they belong to the firm and not to a tool vendor, and they degrade differently: a stale specification misleads an agent, where a broken generator stops a toolchain. Whether misleading is the better failure is not obvious, since a halted toolchain is at least visible.

One thing has not changed. Brooks’s essence — deciding what to build, specifying it precisely, and verifying that what was built matches the intent and serves the user — is untouched by elastic construction labour. Agents remove a great deal of accidental difficulty and in doing so leave the essential work as the visible constraint.

3.3 Where the constraint moves

In the classic factories construction was scarce and inspection could keep pace with it. With agents that relation reverses. Candidate changes are abundant, and two things become scarce: the capacity to establish that plausible output is correct output, and the supply of validated things worth building.

The first half has some support in section 2.6. The second half has none and is my conjecture.

The practical consequence is about planning, not identity. The factory still exists to deliver. What changes is the station that sets its pace. Review capacity, test infrastructure and the precision of specifications used to be treated as controls applied to a delivery flow whose rate was set elsewhere. They now set the rate. Capacity planning, funding and measurement should start from them: a firm that buys agent capacity without enlarging its capacity to verify has bought a queue. The same reasoning applies upstream. A firm that enlarges verification without improving the rate at which it learns what its users need will verify, efficiently, things nobody wanted.

3.4 The four waves compared

The first three columns summarise section 2. The last column is argument.

3.5 The failure catalogue, mapped forward

Each historical failure has a descendant in the AI factory. This mapping is, in my view, the most useful thing the lineage offers.

SDC’s split returns as the specification department. SDC separated design from construction, put them in different places under different managers, and lost the loop between the people who understood the problem and the people who built the answer; program managers who did not have to use the factory stopped using it [5]. An AI factory deliberately runs two cadences: a human-paced one in which intent is discussed and written down, and a machine-paced one in which agents execute it. That is structurally the same separation. It is survivable only when both cadences sit inside one product team, joined by the specification, with the people who wrote the intent reading what came back. A firm that implements the two cadences as two organisations — a specification department feeding an agent pool — has rebuilt SDC’s matrix at machine speed, with the feedback loop cut in the same place. I expect this to be the most common structural mistake, because it looks like sensible specialisation and because agent capacity is easy to centralise.

The condition of Toshiba’s success returns as stale context. Toshiba’s reuse worked as a standing programme: targets, registration of reusable modules, evaluation, and a factory organisation that owned the library [6]. The AI factory’s reusable asset is not code. It is context: inventories, templates, repository instruction files, recorded decisions, design rules. These are consumed on every task, so their decay is paid for on every task, and nothing fails loudly when they decay; agents follow a stale instruction with confidence. My reading of the lineage is that this slow decay, more than any dramatic failure, is how a working factory stops working. It is an inference: Cusumano’s papers describe the programme that sustained reuse, not a factory that lost it.

The cost of the domain-specific language returns as specification bureaucracy. On my reading of section 2.3, the earlier factories failed because encoding the domain cost more than the generation saved. The AI factory wins the same trade only while writing and maintaining specifications and context costs less than the construction it unlocks. That is true today for most work and is not guaranteed at the margin. A firm that requires a full specification for a one-line change, adds approval stages to the writing of intent, or measures specification completeness for its own sake recreates the meta-cost in natural language. The symptom is the one the earlier wave showed: capable people routing around the apparatus because doing the work directly is quicker.

The vendor-owned abstraction returns as dependence on one model and one tool. Investments in CASE and in vendor modelling platforms depended on the vendor’s roadmap, and the Oslo history shows a roadmap moving [12]. The present equivalent is a factory whose context assets are formatted for one agent product, whose automation assumes one tool’s behaviour and whose economics assume one vendor’s prices. The mitigation is to keep context assets in open, plain formats and to bind the firm’s processes to a role in the delivery chain and not to a product. Cross-vendor conventions help: the AGENTS.md format, stewarded by the Agentic AI Foundation under the Linux Foundation, is described by its site as used by more than 60,000 open-source projects and lists over twenty supporting agents and tools as of November 2026 [22]. A file format is a partial answer. Portability of behaviour between models is not something a format can supply.

Reuse targets return as participation metrics. Toshiba tied evaluations to reuse targets and registration quotas, and Cusumano records that one of its measures was imprecise because new and reused code were not reliably distinguished [6]. I found no account in the sources I could open of engineers gaming those measures, and I do not assert that they did. The general point needs no historical proof: a target on an input invites the production of that input. The present equivalents are suggestion acceptance rate, the share of commits written by agents and the percentage of AI-assisted pull requests. They measure use. A firm should measure flow, review latency and outcomes, and should not set targets on agent participation.

The resented label returns as a question about craft. At SDC the word “factory” was taken as a slur on professionalism [5, p. 54]. The practical lesson is about language and about what the firm actually does with its engineers. The historical record on skill is mixed, as section 2.2 says, and I do not claim that it shows craft moving up the stack. I do claim that a firm which describes its engineers as line workers will get the resistance SDC got.

3.6 Upstream of delivery: conjectures

This section is conjecture. Nothing in it is supported by the evidence in section 2, and a reader who discounts it loses nothing from the argument above.

Discovery may become the pacing function. Product practice already distinguishes discovery, deciding what is worth building, from delivery. The two-track picture originates with Desirée Sy’s 2007 paper on agile user-centred design; Jeff Patton, who traces it to her, and Marty Cagan, who credits Patton for the name, spread it among product managers [23, 24]. Cagan’s formulation is that the discovery track “is all about quickly generating validated product backlog items” [24]. While construction was scarce, delivery set the pace and discovery could stay ahead of it. If construction is abundant, a competent factory may drain the backlog faster than discovery refills it with validated items. An agent capacity that waits for intent then signals a discovery problem. One that never waits may be shipping unvalidated intent, which is worse.

Prioritisation may matter less and selection more. Ranking a backlog rationed scarce construction capacity. If that scarcity eases, two jobs take more weight: choosing which problems deserve to be products at all, and writing intent precisely enough to be tested. I make no claim about what this does to the product-management or design professions. The one design-related point I would stand behind is narrow: a design system that agents read as rules does more work than one that people consult as a library, so whoever owns those rules owns more of the outcome.

The portfolio may tilt towards smaller, reversible bets. If a governed internal application costs weeks of factory time and not a year of programme budget, more and smaller bets become rational. That holds only if stopping is as routine as starting, which section 4 takes up.

4. What a CIO does differently

These follow from section 3 and carry the same status: proposals, not tested practice.

1. Never split specification-writing and agent execution into two departments. The two cadences belong inside one product team. Agent capacity can be provisioned centrally as a platform service; the people who write intent and the people who read the result must be the same team. This is the SDC lesson and the one I would put first.
2. Plan capacity from verification. Before buying more agent capacity, state what will review its output and how fast: tests generated from specifications, automated checks, and human review routed by the risk of the change. Fund those first. Measure review latency as the leading indicator that volume is outrunning verification.
3. Fund the maintenance of context assets as a standing function with a named owner. Give it to an existing role, most naturally whoever owns the platform or the delivery automation. It does not need a new title. It needs a budget line that survives the end of the programme and a duty to retire stale assets as well as add new ones.
4. Keep the specification cheaper than the work. Scale the required precision to the risk and size of the change. Watch for people bypassing the specification step; treat that as evidence the step has become too expensive, before treating it as indiscipline.
5. Industrialise decommissioning. A portfolio of cheap applications becomes a stock of unowned production systems unless retirement, data disposal and closure of the evidence trail are as templated as creation. Retirement depends on the inventory: a firm can cheaply retire only what it can completely enumerate.
6. Make promotion from prototype cheaper than evasion. Cheap construction means every business unit can have a working tool within days. The dangerous artefact in a supervised firm is the successful prototype that gathers users, data and dependencies without ever being registered, because a system nobody has registered is a system nobody can evidence. The application foundation should be the promotion path, and moving a prototype onto it should take less effort than keeping it hidden. Platform engineering’s lesson applies to every control surface: where a control is easier to evade than to use, evasion is what the firm will get, and with agents it will get it quickly.
7. Do not measure agent participation. No targets on acceptance rates, agent share of commits or AI-assisted pull requests. Measure flow, review latency and outcomes.
8. Instrument the discovery claim before relying on it. If the firm wants to test section 3.6, compare the lead time of validated intent — from identified need to a specification someone has tested against users — with the throughput of agent work. If the first is persistently longer than the second can absorb, the constraint is upstream. Until that is measured, the claim is rhetoric.
9. Keep context assets portable. Plain formats, open conventions where they exist, and a periodic exercise in which a representative task is run on a second model or tool. The exercise is the control, not the format.

5. Limitations

• The agent-era half is argument. Sections 3.2 to 3.6 and all of section 4 are reasoning from a historical record and a small body of recent evidence. The evidence in section 2.6 consists of survey associations, one small randomised trial that its authors now mark as out of date, a follow-up they call unreliable, and one vendor’s data set. None of it measures verification capacity as a constraint, and none of it addresses discovery.
• Section 3.6 is conjecture. The claims about discovery, prioritisation, design systems and portfolio shape have no supporting evidence in this paper. The proposed measure in section 4 has not been tried.
• The analogy is selective. The factories that worked built bespoke industrial and defence software for stable requirements. A hostile reader can fairly say they worked where software least resembles the application estate of a financial institution. For that reason the paper uses the lineage as a catalogue of failures and not as a template for success.
• Two interpretations carry weight and are mine. That Microsoft’s software-factories programme was undone by meta-cost, and that product lines saw limited take-up in enterprise IT because of portfolio instability, are my readings. I have no cost data for either.
• The historical record is read through working papers, not the book. Claims attributed to Cusumano rest on four MIT Sloan working papers that preceded Japan’s Software Factories, read as scanned text. The book may differ in detail, and page numbers given here are the working papers’ printed pages. Bemer’s 1968 paper and the Bratman and Court article were not consulted directly; the first is reported as Cusumano cites it, the second from its bibliographic record and from Cusumano’s account. Toshiba’s year-by-year reuse figures before 1985 are not consistent between two of the working papers and are not used.
• The CelsiusTech figures are the company’s own, reported to the SEI’s authors in 1996. They describe one firm in one domain.
• Whether agent review of agent output relieves the verification constraint is open. Spending abundant construction capacity on automated critique may move the constraint or merely relocate it to the residual human review. I know of no strong evidence either way as of November 2026.
• The institutional problem is unsolved. The Japanese factories and CelsiusTech needed a decade of sustained management commitment. Context assets are cheaper than reuse libraries, but funding a standing capability in place of a programme is the same problem, and nothing in the technology addresses it.
• Dependence on model vendors is named, not resolved. The paper does not specify what must be true of a firm’s context assets for a change of model or tool to cost weeks and not a rewrite.
• All quantitative claims decay. The 2024–2026 figures carry their dates and should be re-checked before reuse.
• Verification. The source checks for this version were carried out by an AI research agent, which opened the sources listed below on 10 November 2026 except where a reference says otherwise. That is not peer review, and the paper has not yet had a practitioner review.

References

Web sources accessed 10 November 2026. Page numbers for [2], [5], [6] and [7] are the printed pages of the scanned working papers.

1. M. D. McIlroy, “Mass Produced Software Components”, in P. Naur and B. Randell (eds.), Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, Scientific Affairs Division, NATO, Brussels, 1969, pp. 138–155. Text hosted by the author: https://mcilroy.cs.dartmouth.edu/components.txt
2. M. A. Cusumano, “Factory Concepts and Practices in Software Development: An Historical Overview”, MIT Sloan School of Management Working Paper 3095-89, version of 5 December 1989. http://hdl.handle.net/1721.1/47992 ; scanned text at https://archive.org/details/factoryconceptsp00cusu . A version was published as “Factory Concepts and Practices in Software Development”, IEEE Annals of the History of Computing, vol. 13, no. 1, 1991, pp. 3–32; the journal version was not consulted.
3. R. W. Bemer, “Position Papers for Panel Discussion — The Economics of Program Production”, Information Processing 68, North-Holland, Amsterdam, 1969, pp. 1626–1627. Cited as given in [2]; not consulted directly.
4. H. Bratman and T. Court, “The Software Factory”, Computer, vol. 8, no. 5, May 1975, pp. 28–37. https://doi.org/10.1109/C-M.1975.218953 . Bibliographic record and abstract only; the article was not consulted.
5. M. A. Cusumano, “System Development Corporation: Defining the Factory Challenge”, MIT Sloan School of Management Working Paper 1887-87, revised December 1988. http://hdl.handle.net/1721.1/49002 ; scanned text at https://archive.org/details/systemdevelopmen00cusu
6. M. A. Cusumano, “Toshiba’s Fuchu Software Factory: Strategy, Technology, and Organization”, MIT Sloan School of Management Working Paper 1939-87, 6 October 1987. Scanned text at https://archive.org/details/toshibasfuchusof00cusu
7. M. A. Cusumano, “Shifting Economies: Craft Production to the Flexible Factory”, MIT Sloan School of Management Working Paper 2012-88, 6 May 1988. http://hdl.handle.net/1721.1/49168 ; scanned text at https://archive.org/details/shiftingeconomie00cusu
8. M. A. Cusumano, Japan’s Software Factories: A Challenge to U.S. Management, Oxford University Press, New York, 1991. Not consulted; see Limitations.
9. M. Fowler, “ModelDrivenArchitecture”, martinfowler.com, 2 February 2004. https://martinfowler.com/bliki/ModelDrivenArchitecture.html
10. J. Greenfield and K. Short, with S. Cook and S. Kent, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Wiley, 2004. Authors’ page: https://softwarefactories.com/TheBook.html
11. Microsoft Learn, “Overview of Domain-Specific Language Tools” (Visual Studio 2022 documentation). https://learn.microsoft.com/en-us/visualstudio/modeling/overview-of-domain-specific-language-tools
12. D. Box, “Update on SQL Server Modeling CTP (Repository/Modeling Services, ‘Quadrant’ and ‘M’)”, Model Citizen blog, Microsoft, 22 September 2010 (Microsoft Learn archive). https://learn.microsoft.com/en-us/archive/blogs/modelcitizen/update-on-sql-server-modeling-ctp-repositorymodeling-services-quadrant-and-m
13. L. M. Northrop and P. C. Clements et al., A Framework for Software Product Line Practice, Version 5.0, Software Engineering Institute, Carnegie Mellon University, December 2012. https://www.sei.cmu.edu/documents/501/2012_019_001_495381.pdf
14. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, Boston, 2002. Cited as given in [13].
15. L. Brownsword and P. Clements, A Case Study in Successful Product Line Development, Technical Report CMU/SEI-96-TR-016, Software Engineering Institute, Carnegie Mellon University, October 1996, pp. 2, 11–12, 16–17 and 69. https://www.sei.cmu.edu/library/a-case-study-in-successful-product-line-development
16. DORA research programme, Accelerate State of DevOps Report 2024, report page, https://dora.dev/research/2024/dora-report/ ; and Google Cloud Blog, “Announcing the 2024 DORA report”, 23 October 2024, https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
17. DORA research programme (Google), State of AI-assisted Software Development 2025, https://dora.dev/research/2025/dora-report/ ; and N. Harvey and D. DeBellis, “Announcing the 2025 DORA Report”, Google Cloud Blog, 23 September 2025, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report (the quotations are from the announcement).
18. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
19. METR, “We are Changing our Developer Productivity Experiment Design”, 24 February 2026. https://metr.org/blog/2026-02-24-uplift-update/
20. GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”. https://www.gitclear.com/ai_assistant_code_quality_2025_research
21. F. P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, vol. 20, no. 4, April 1987, pp. 10–19. https://doi.org/10.1109/MC.1987.1663532 . Bibliographic record only.
22. AGENTS.md, project site (Agentic AI Foundation, under the Linux Foundation). https://agents.md/
23. J. Patton, “Dual Track Development is not Duel Track”, 10 May 2017 (updated 12 April 2023), crediting D. Sy, “Adapting Usability Investigations for Agile User-centered Design” (2007). https://www.jpattonassociates.com/dual-track-development/
24. M. Cagan, “Dual-Track Agile”, Silicon Valley Product Group, 17 September 2012. https://www.svpg.com/dual-track-agile/