From hand-fitted cars to hand-fitted code.

Around 1908, cars were built the way most software is built today: by skilled craftsmen who held the whole design in their heads and made everything fit through judgment at the bench. What Ford did over the following five years wasn’t primarily an invention in machinery; it was a behavioral reorganization of work, and the product had to change to make that reorganization possible. Software is now at the same threshold, and the parallels run deeper than the usual “assembly line for code” metaphor suggests.

Start with what craft production actually was, in both domains. The carriage builder didn’t work from someone else’s blueprint. Design decisions were embedded in the act of making; he designed a little, built a little, discovered constraints through his hands, and revised as he went. Software developers have always worked the same way. Development contains two distinguishable activities, deciding what to build and the labor of realizing that decision in working code, but they’ve been performed by the same person, interleaved minute by minute, so tightly that they looked like a single activity. The design often lived nowhere but in the developer’s intuition, discovered through the act of writing the code itself.

Ford’s central move was to separate those activities into different people with different feedback loops. Design became explicit, frozen, and communicable (drawings, specifications, tolerances) precisely so that production could be performed by people and machines who never participated in the design. Everything else followed from making that handoff survivable. This is the frame in which the specific product changes make sense, and each has a direct software analog.

First, interchangeable parts. A hand-built car’s components fit because a craftsman filed them to fit; any part had to work in any car before an assembly line was possible. The software equivalent of the hand-fitted part is code that works only because of implicit assumptions, undocumented invariants, and tribal knowledge: code that requires someone who understands the whole system to modify safely. For AI agents to produce and modify software at scale, modules need the properties of interchangeable parts. Typed interfaces, explicit contracts, schemas, clean boundaries. An agent shouldn’t need the entire codebase in context any more than a line worker needed to understand the whole vehicle.

Second, tolerances and gauges. Interchangeability was worthless without a cheap, objective way to check whether a part was in spec, so hardened gauges replaced the craftsman’s eye as the arbiter of fit. In software that role belongs to type checkers, test suites, CI pipelines, and evals. This may be the single most important parallel, because it identifies the actual bottleneck: AI can already generate code in enormous volume, but volume without verification is a liability. A codebase with weak tests is a machine shop without gauges; you can’t tell a good part from a bad one until the car breaks. We’ve argued before that code generation was never the bottleneck. The binding constraint on AI software factories is verification.

Third, design for assembly. Model T parts were redesigned so that unskilled workers could attach them with simple, repeatable motions: fewer fasteners, self-locating pieces, no judgment calls at the bench. Software must be redesigned for agent legibility the same way, with smaller modules, conventional structures, and self-documenting patterns. Clever, idiosyncratic code is the hand-filed part: admirable craftsmanship that gates all future work on the one mind that understands it. Boring, conventional code is what assembles at scale.

Fourth, standardization. Ford froze the design and eliminated variation; black paint won because it dried fastest. The organizational software parallel is ruthless convention: standard stacks, standard frameworks, standard patterns. Every bespoke build system and in-house abstraction is a custom part demanding hand-fitting, and agents perform better on popular, well-documented conventions, which are the training-data equivalent of a standardized parts catalog.

Fifth, subassemblies. Engines and magnetos were built on separate lines and joined to the chassis later, which is what allowed parallel work. Software needs the same decomposability, with independently completable and independently verifiable units of work, so that many agents can operate in parallel without merge conflicts becoming the new hand-fitting.

Now the deeper point, which the standard version of this analogy gets wrong. It’s tempting to say the analogy breaks because in software “the code is the design” and production was automated long ago by compilers. But that’s an artifact-centric view. Behaviorally, design and production always existed as separate activities in software; they were just never organizationally separated. What AI is industrializing is exactly the separation Ford performed a century ago: the human retains design (intent, architecture, specifications, acceptance criteria) while the generation of code becomes production, performed by something that did not participate in the design.

And the separation forces the same discipline it forced in 1913. When designer and producer are the same brain, the spec can live as intuition. Once they’re separated, vague intent produces defective parts. This is why spec quality suddenly matters so much, and why evaluation infrastructure is becoming the center of gravity: the spec is the engineering drawing, and the test suite is the gauge on the line. The durable artifacts of software engineering are shifting from the code itself to the things that survive the handoff. Specifications, tests, review processes. The code becomes the stamped part.

This framing also explains the friction of the current moment. Much of the discomfort developers feel with AI coding tools is the discomfort of unbundling two behaviors that were never separate in their working lives. Developers are used to discovering the design through the act of production, learning what the system should be by writing it. Handing production to an agent breaks that loop, and it feels wrong in the same way it must have felt wrong to a craftsman handed a drawing and told to stop making judgment calls at the bench. The design discovery that used to happen implicitly during hand-production doesn’t disappear; it has to relocate, into faster prototyping loops, into spec iteration, into reviewing the agent’s output and revising intent. Teams that pretend that discovery work no longer exists will ship the software equivalent of parts that don’t fit.

The labor consequences rhyme too. Ford’s line deskilled the assembly worker while dramatically upskilling the process engineer, the person who designed the line, the tooling, and the verification. The same inversion is underway: less value in the ability to write individual functions, much more in architecting systems, specifying behavior precisely, and building the machinery that verifies machine-produced work. The craftsman didn’t vanish; his skills migrated upstream or into the niches where craft still commanded a premium.

Finally, the uncomfortable lesson. Ford bought scale by selling variety and elegance: good enough, identical, cheap. The software version of that bargain is more boilerplate, more convention, less cleverness — code optimized for machine production and machine verification rather than human admiration. The craftsmen hated it then. Many will hate it now. But the price of a Model T fell from $850 in 1908 to under $300, assembly time dropped from over twelve hours to ninety-three minutes, and that, in the end, was the argument that won.

This essay opens a series. Each of the parallels above compresses an engineering problem we’ve hit in practice while running a software factory, and the next eight essays take them one at a time: what complexity actually measures, why the product architecture has to change and not just the tooling, what it costs to keep the gauges honest, and where the human work goes when the typing stops being the job.