Published August 13, 2026
The Software Foundry named the revolution: AI has changed the production function of software, and a third affordability revolution follows. The App-Stack Tax named what the revolution abolishes: the repeated foundations every business pays for again and again, and the architecture — one core, many products — that ends the tax. Both essays lean on a claim I have so far asserted rather than opened: that there is such a thing as a software production system, as distinct from software development done quickly.
This essay opens the doors and walks the floor. It is written for a particular reader: the builder — the person deciding what to do with the most powerful construction tools ever handed to our industry. Because the awkward truth of this moment is that those tools are available to everyone, and most of what gets built with them will not be a foundry. It will be a faster workshop.
The thesis: AI-generated code is not a software foundry. A foundry is a production system that turns precise intent into dependable software, repeatedly — using specifications as control surfaces, reusable components as tooling, automated quality as inspection, and humans as accountable designers of the system. The model is the ore. The system is the mill.
1
The Workshop and the Foundry
Picture two small teams. Both are talented. Both use the same frontier AI models — the same coding agents, the same context windows, the same per-token prices. Both can produce an impressive working prototype in days. Watch them for six months, and they become different species.
The first team runs an AI workshop. Every product starts from a prompt and a conversation. The agents generate remarkable volumes of code, fast. But each product begins again: a new conversation creates a new repository; the agent chooses a slightly different architecture because the prompt was slightly different; identity is rebuilt, permissions are re-interpreted, logging arrives late, and the tests describe the happy path. The decisions that shaped the product live in chat histories nobody rereads. The team celebrates speed — and speed is real — while debt accumulates at machine pace, because the agents that write code quickly write inconsistency just as quickly. The workshop’s tell is what happens on product two: it starts from a prompt again. Nothing carried over except the people.
The second team runs a foundry. Intent enters as a specification precise enough for machines to execute and other machines to verify. The agents build — but they are instructed to search the existing inventory before creating anything new, they build *from proven components*, and what they generate must pass common gates before any customer sees it. Failures are replayable; operating knowledge flows back into the system; and when product two begins, most of it already exists. The foundry’s tell is the inverse of the workshop’s: the second product is where it gets faster.
The model is identical. The system around it is not.
Here is what makes the fork treacherous: at the demo, the two teams are indistinguishable. Both show a working product; both credit the same models; both are telling the truth. The demo measures the model, and the model is the same. Only repetition measures the system — which means the most important property of a software company is now invisible at exactly the moment everyone is looking. Investors, customers and the teams themselves will spend the next two years confusing impressive first products with production systems, because the evidence that separates them does not exist until product two.
This is the distinction the current discourse keeps missing. The public argument about AI and software is stuck on the model — which model codes best, how many tokens, what percentage of commits. But the model is available to everyone, which means the model is precisely the thing that cannot be the advantage. In the language of the first essay: the generated code is the ore. What separates the two teams is the mill — and the mill has a one-line definition: the difference between a workshop and a foundry is not how much code AI writes; it is how little of the production system must be reinvented for the next product.
A century ago, industrialists learned this same lesson about physical production: the machine tool mattered less than the system of jigs, gauges, tolerances and process discipline built around it. The factories that treated the new machines as faster craftsmen stayed workshops with better tools. The ones that redesigned production itself became something new. Software now stands at the same fork.
Standing at it, a foundry must resist two opposite temptations. The first is to treat every new request as a custom project — that builds an AI services company, fast and unrepeatable. The second is to build the universal platform before shipping a real product — that builds an internal infrastructure programme in search of a customer. The correct sequence is narrower than either: build one real thing, instrument how it was built and operated, then extract only the machinery that proves reusable. A foundry is not designed in advance. It is discovered through disciplined repetition — and the rest of this essay is a tour of the four rooms where the discovery happens: the specification, the tooling, the quality system, and the people.
2
The Specification Becomes the Control Surface
Begin with the most consequential change, and the least visible one. When agents write more of the code, the most important human-authored artefact stops being the code. Code remains the executable artefact. The specification becomes the source of intent — the primary control surface through which humans govern what gets built.
Consider how intent has historically travelled into software: meetings, product documents, tickets, whiteboard photographs, a developer’s interpretation, code review, testing, and a long argument about what was meant. Every hop lost information; the code that shipped was the residue of a negotiation. Slow human execution acted, perversely, as a safety mechanism — there was time for misunderstandings to surface. Agents remove that safety mechanism. The machine is not lazy; it does not pause because the requirement is imprecise. It executes — and a weak specification now generates a large volume of syntactically correct but strategically wrong software, faster than anyone can read it. The faster the machine executes, the more expensive ambiguity becomes.
So the foundry’s first discipline is not prompting. It is executable precision: expressing intent in a form machines can implement and other machines can verify. A serious foundry specification is layered, and each layer answers a different question. Purpose — what job is being completed, and for whom. Behaviour — what the product must do in normal use, stated as observable outcomes. State — what it knows, remembers and changes. Boundaries — what it must never do: the security lines, the data it may not touch, the actions requiring a human. Acceptance — how another machine will know the work is correct: the tests written before the code exists. Operation — how failure will be detected, diagnosed and reversed. The layers are not paperwork; they are the settings on the machine. Change the specification and the production run changes with it.
A worked example makes the difference concrete. “Let managers approve expenses” is a request, not a specification. Which managers? What counts as an expense? What happens when the approver is on leave, the currency is unrecognised, the amount crosses a threshold, the receipt is unreadable, or the employee changes teams mid-claim? Who may override a rejection, and what is written to the audit trail when they do? Which failures block payment, and which merely raise a warning? An agent can generate the screens for this in minutes; the screens were never the hard part. The behavioural truth of the workflow is the product — and every one of those questions is a decision a machine will otherwise make silently, at speed, in whichever direction the ambiguity happened to lean.
Not a pipeline that ends — a loop that learns.
Notice what the figure is and is not. It is not a pipeline with a beginning and an end; it is a loop. The specification drives the build; the build faces inspection; release is controlled; operation produces a trace of what the software did in the world; and the trace flows back — refining the specification, converting failures into permanent tests, teaching the next run what this run learned. In the workshop, the specification (when one exists) helps a developer begin. In the foundry, the specification governs the entire production loop — it is where intent enters, and where learning returns.
This discipline reaches product management too. The traditional product document could remain persuasive while being operationally vague, because a skilled team translated it; the foundry specification cannot hide behind prose. It must separate assumption from fact, normal path from exception, outcome from implementation preference — and state which decisions the machine may make alone, which require verification, and which remain human. It is versioned, diffable, and traceable to the behaviour it produced. All of which creates a craft that does not yet have a name or a curriculum: the writing of specifications that machines execute well. It sits somewhere between product management, systems design and law — the drafting of documents whose every ambiguity will be exploited at machine speed, whose every precision compounds. The people who master it will be to this era what great architects of code were to the last one. And it explains a prediction worth making plainly: in the foundry, the intellectual property that matters will migrate from the codebase — increasingly generated, increasingly commodity — to the specification library: the accumulated, tested, executable statements of what dependable products must do.
3
Components Are the Tooling
In a physical factory, the tooling — the jigs, dies, fixtures and gauges — determines what can be produced repeatedly and to what tolerance. Tooling is expensive to create and priceless once proven, because every subsequent product inherits its precision for free. The software foundry has an exact equivalent, and it is not the AI model. It is the library of proven components: identity and permissions, data models, workflow engines, connector frameworks, interface components, testing harnesses, observability, deployment machinery, billing, support capabilities, security patterns. One clarification before going further, to keep two ideas from blurring: this production tooling is not the shared product core described in *The App-Stack Tax*. One Core, Many Products is an architecture a foundry might *build* — a product decision. The tooling described here is what a foundry *builds with* — the machinery behind every product it will ever make, whatever the architecture.
Here is the accounting change that follows, and it is an unfamiliar one: the code repository is not the balance sheet. Repositories fill up in any AI-equipped team; volume of generated code is nearly free and nearly meaningless. The asset that matters is the reuse ledger: which components exist, which products use them, how reliable each has proven in operation, what each carries in dependencies, what each costs to run — and, the column that justifies the whole ledger, how much production time each one saves when the next product draws on it. A component used once is an expense. A component proven across three products is machinery. Every proven component is stored production time — and the foundry’s net worth is the sum of that column.
The repository is not the balance sheet. This is.
The ledger changes how the agents themselves work. Instead of beginning from a blank context, an agent is required to search the ledger, compare the new requirement against proven patterns, and justify every departure — and it selects on operating evidence, not novelty: which component produced fewer incidents, which connector has known limits, which pattern reduced support questions. The foundry acquires the thing workshops structurally cannot have: institutional memory that survives individual engineers and model upgrades.
The ledger enforces honesty in both directions. It exposes components that were built speculatively and never reused — the foundry’s dead inventory. And it prevents the opposite failure, which has killed more platform efforts than any technology ever has: premature abstraction. The seductive mistake is to build the universal machinery first — the grand internal platform, the framework for every future need — before any product exists to need it. Platforms built in advance of products are speculation wearing an architecture diagram; they generalise from zero examples and are wrong in ways only real products reveal. The foundry’s promotion rule runs the other way: build concretely; reuse deliberately; generalise only after the second real need. A component is extracted from a real product, hardened by a second real use, and only then promoted into the common tooling. The ledger records the promotion — and the temptation it guards against has grown teeth, because agents make frameworks nearly free to generate: a team can now produce an impressive universal layer long before it has discovered the real commonality. A mature ledger therefore records negative knowledge with equal care — the component that is secure but too expensive to operate, the workflow that fits one regulatory context and fails in another, the connector with hidden rate limits. Knowing where reuse is unsafe is as valuable as knowing where it compounds. A foundry’s maturity shows not in the size of its catalogue but in the quality of its boundaries.
Watch what this does to the economics of the portfolio. The first product pays full price: it builds its own tooling as it goes, and most of what it builds is candidate machinery, not proven machinery. The second product is the moment of truth — the essay returns to this at the end. But by the fifth product, something structural has happened: most of a new product is drawn from the ledger, and what remains to build is mostly the product’s one distinctive job. The threshold for viable software falls with every promotion. Products for narrow niches, small categories and local practices — products that could never have carried a full engineering organisation — become economical, because they no longer have to buy their own tooling. The tooling was already paid for, by every product before them. And this is where the durable advantage forms — the answer to the objection that every competitor has the same models. They do. A competitor can reproduce a screen or a workflow in an afternoon. What it cannot reproduce in an afternoon is years of accumulated evidence about which components behave dependably together, under which conditions, at what operating cost. The reuse ledger is not glamorous. Neither is factory tooling. Both are where repetition turns into economics.
4
Quality Must Be Manufactured
Now the objection that every serious reader has been holding since Part 1, and that deserves to be stated at full strength: AI can increase output faster than any organisation increases judgement. Left ungoverned, agents produce brittle code, duplicated logic, insecure dependencies, inconsistent interfaces, and failure modes nobody has mapped — technical debt manufactured at machine speed. The critics who say most AI-built software will be unreliable are not wrong about the workshop. They are describing it accurately. The question is whether the foundry has a structurally different answer — and it does, though it is not the answer people expect.
The expected answer is human review: have experienced engineers read what the machines wrote. At foundry volumes this is arithmetic nonsense — humans reading machine-speed output either become the bottleneck that erases the production advantage, or become a rubber stamp that erases the safety. The foundry’s answer is the one manufacturing found a century ago, when production outran craftsman inspection: industrialise the inspection itself. Machine tools did not make quality control obsolete; they made *statistical* quality control necessary — specifications with tolerances, gauges at every station, sampling, traceability, the discipline Cusumano documented the Japanese software factories borrowing from their own assembly lines. The foundry completes what those factories started, with the ingredient they lacked: generated code makes inspection more important, not less — but inspection must itself become software.
Six gates between generated code and the customer — and a loop that makes each failure permanent knowledge.
The gates come in layers, each catching what the previous cannot. Static controls first: schemas, types, dependency policies and security rules that reject bad structure before anything runs — the cheapest gate, so it runs on everything. Behavioural tests next: unit, integration, contract and end-to-end — and note that in a foundry these are largely written *before* the code, because they are the specification’s acceptance layer made executable. Adversarial tests third: unexpected inputs, permission probing, corrupted data, misuse and attack paths — machines are tireless red-teamers of other machines’ work. Then the gates that operate in the world: controlled release (flags, staged rollout, shadow operation, instant rollback — the assumption that something will eventually be wrong, built into the delivery mechanism); operational inspection (observability, anomaly and drift detection, cost monitoring — the software watched as closely as it was tested); and finally failure replay, the gate that makes the whole system compound: every significant incident captured with its state, inputs and component versions, reproduced, understood, and converted into a permanent test, so the same failure can never ship twice. In a workshop, an incident is repaired. In a foundry, it becomes production machinery.
Consequence, not convenience, sets the level of autonomy at each gate. A cosmetic change moves through the automated path end to end. A permission change, a payment decision, a deletion of customer data — anything whose failure cannot be cheaply reversed — carries heavier gates and a named human approver. The foundry classifies every change by what it could cost, and grants the machines exactly as much independence as the evidence supports: autonomy is earned through evidence, not declared through ambition. And the same production system extends past release into operation, because at radically lower prices the old support model — large success teams, manual diagnostics, repeated explanations — cannot survive. The product must explain itself: structured logs, replayable failures, documentation that updates with the specification, diagnostics that identify likely causes. Human experts remain, concentrated on the novel and the consequential. AI-native operation is part of the production system, not an economy measure bolted on to protect margins.
Two properties make this a production system rather than a checklist. First, the gates are common: every product passes the same inspection, which is what makes quality a property of the foundry rather than a property of whichever team was careful. Second, the loop learns: each replayed failure hardens the gates for every product at once — one product’s incident becomes the whole portfolio’s immunity. This is the honest answer to the slop objection, and it is also the honest standard from the first essay, restated for engineers: trusted affordability means the price fell because waste was removed — duplicated tooling, unused features, manual inspection — not because responsibility was removed. The question a foundry must answer is never whether every line was manually perfect. It is whether the production system detects variation before the customer pays for it.
5
The Craftsman Is Elevated
End where the anxiety is: the people. The shallow version of this era’s story says agents write the code, so fewer engineers are needed — a subtraction story. The foundry’s story is a relocation: the human moves to the level where judgement has more leverage. Nothing in the four rooms above is unmanned. Someone chose which problem was worth a product. Someone wrote the specification’s boundaries — decided what the software must never do. Someone set the architecture, decided what gets promoted to common tooling, judged the exception the gates flagged at 2 a.m., and accepted responsibility for the consequential release. Someone maintained taste — the difficult ability to distinguish a feature that can be generated from a product that should exist. The machines run the loop. Humans design and govern the system — and governing a production system is a larger act of engineering than operating inside one.
This produces a role that existing job titles describe badly. The foundry builder combines product judgement (which job, which user, what sufficiency means) with systems design, specification craft, agent orchestration, quality engineering, and — unusually for an engineering role — economic thinking: what a component costs to run, what reuse is worth, when a product’s margin makes it real. The temperament matters as much as the skills, and it is specific: low ego about who wrote the code, high ownership of the outcome. Comfort moving between product and engineering without treating the border as a wall. The instinct for reuse without the vice of premature abstraction. An obsession with measurement — because in a foundry, the scoreboard is real and public. A willingness to let machines do everything routine, joined to an absolute refusal to delegate judgement. Some of the best people for this work will come from conventional engineering; some will not have written production code for years; a few will be product people who discovered they can now build. What they share is the ability to be accountable for a system rather than proud of a component. The organisation reshapes itself around them: the traditional decomposition — product, design, frontend, backend, QA, infrastructure, support, and the coordination overhead between them — does not vanish, but most of it moves *into the production system*, leaving a small number of people concentrated on end-to-end outcomes. The culture that makes this safe is unusually explicit about responsibility: every product has named human owners for its purpose, its safety boundaries and its economics; high-consequence changes have clear approval; exceptions are reviewed as opportunities to strengthen the system, not as embarrassments. The team is small enough that nobody can hide behind a function, and disciplined enough that nobody must remember everything personally.
The craftsman is not eliminated. The craftsman is promoted — to designer of the system.
And here the essay must be honest about its own boldest claim. Everything above implies that a small team governing a strong production system can outperform a much larger organisation coordinating specialised workshops — that five people with a foundry beat fifty with better tools. I believe it. I cannot yet prove it, and neither can anyone else, because the claim is not a philosophy; it is a wager with numerical terms. The wager: that the small team wins on elapsed build time, on quality reaching the customer, on support load per product, and on the economics of each successive product — measured, not assumed from headcount. A small team can fail faster too; if five people produce fragile products that require an invisible army of rescuers, nothing has been transformed. Headcount reduction is not proof. Reliable utility per unit of human judgement is proof. And it is worth stating what the wager is not: it is not a claim that engineers have become unnecessary, nor that judgement has become cheap. The foundry team is small because its leverage is high — every person governs machinery that multiplies them — and the moment the numbers say otherwise, the honest response is to change the system, not the scoreboard. Every era’s production revolution attracted true believers before it produced evidence; the believers who mattered were the ones who instrumented the factory and published the numbers. That is the temperament this work rewards, stated one final way: the foundry does not ask anyone to believe. It asks them to measure.
The foundry also changes what mastery means, and this may be the deepest cultural shift of all. In the workshop, mastery is visible in the artefact — elegant code, a clever algorithm, a difficult integration pulled off. In the foundry, mastery is increasingly visible in what no longer requires heroics: the dependency standardised, the class of defect caught automatically, the release that rolled back before a customer noticed, the support problem that diagnosed itself, the new product that inherited weeks of work without inheriting yesterday’s mistakes. The highest craft is embodied in the system — which is why the question a foundry asks of every finished product is not “was it impressive?” but “what did it teach the system never to build from scratch again?”
Closing: Product Two
Which is why this essay must end by disqualifying its own most likely misreading. The first product to come out of any foundry — mine or anyone’s — will prove almost nothing about this essay. A talented team with powerful agents can build one impressive application; the workshop can do that too, and 2026 will be full of impressive first applications. The first product proves demand. The test begins with repetition. Does the second product draw on the ledger instead of starting from a prompt? Does it inherit the gates, connect to the existing machinery, and reach dependable operation in a fraction of the time? Does the third become easier still?
Those questions have numerical answers: elapsed build time, percentage of components reused, defects escaping to customers, support load per product, connector effort, operating cost. When those numbers exist for our own foundry, I will publish them — the favourable ones and the unfavourable ones, because public pre-commitment is what stops a metaphor from grading its own homework. If the curves do not move — if the second product turns out to be another act of concentrated craftsmanship — the honest conclusion will be that a new software company was built, not a new production system. A production system deserves to be measured by production. Until then, everything in this essay is exactly what it claims to be: a description of the machine, offered before the machine has run long enough to be judged. The first essay in this series named the revolution. The second named the waste it removes. This one has shown the machine that removes it. The next will show the dials.
Illustrative — the shape is the claim; the numbers are the promised sequel.
**
AI-generated code is not a software foundry. A foundry is specifications as control surfaces, components as tooling, inspection as software, and humans as accountable designers of the system — judged by one measurement: whether every product makes the next one cheaper, faster and safer to produce.
The workshop celebrates what it built. The foundry measures what it will never need to build again.
Not code without craftsmen. Craft embodied in a system — and multiplied.
