Software manufacturing

The question

Generating code got cheap. Knowing whether what was generated is what you wanted did not. I am looking at the system around the code generators: the one that decides what should be built, judges whether it was, and holds the properties that have to stay true no matter who or what built them. That system behaves like a manufacturing system. It has tolerances, inspection, evidence, rework, throughput and process control, and I think it should be engineered like one.

Why it matters now

For most of this industry’s history, construction was the expensive step, and our rituals assume it still is: estimates, standups and code review are all built around the cost of making the thing. At the margin that is no longer true. The constraint moved to verification and governance, and if the bottleneck sits in reviewing and integrating, speeding up generation makes the whole system slower while hiding it behind impressive output. A plausible change nobody has verified is inventory, not velocity.

The landscape

Two bodies of work sit close to this. Policy as code is a decade old: Open Policy Agent, Conftest and HashiCorp Sentinel made rules executable years ago, so that is not the new part. The nearer one is the AI-native software lifecycle, which several vendors and at least one model lab have now published. Anthropic’s AI-native SDLC playbook structures delivery as plan, design, build, test, deploy and maintain, with governance expressed as hooks, skills and evaluations. I agree with where it starts. Where I part from it: a lifecycle says when work happens, not who may decide, and a check that reports a violation still waits for someone to act on it.

Manufacturing itself is the older precedent. Stopping the line on a defect, inspecting against tolerances, and controlling the process rather than each part are all ways of trusting output nobody checks one piece at a time. How far that analogy holds for software, where no two units are the same, is one of the things I am testing.

What I’m testing

My working model is three layers of control: a harness governs a single run, a factory governs a product’s lifecycle, and standards govern properties that outlive both. The open questions are where it gets interesting. Can a standard close its own loop, detecting a violation, dispatching the repair and judging it by the same rule, so the floor only ever rises? Who decides what kind of product something is, when the standards it inherits depend on that answer? Do standards that each hold on their own conflict when they meet? And does any of it survive more than one person whose intent counts? The white paper states the model; its open problems are where I expect it to break.