When you design a circuit, you don't invent the resistor. You don't redesign the transistor for your application. You don't write a new SPI protocol because the existing one offends you. You compose standardized components -- resistors with known tolerances, ICs with documented behavior, protocols with published semantics -- into something specific to the problem. The design is creative work. The substrate is standardized.
That standardization is not an accident. Electronics went through an industrialization arc. Standard component values (E-series, mid-twentieth century). Standard fabrication processes (silicon refinement, decade by decade). Standard interfaces (Ethernet 1980, I2C 1982, USB 1996). Tooling that codified design rules so the designer doesn't re-derive them on every project. The result is a profession where the design work is dense with creative tradeoffs, but the substrate beneath those tradeoffs is industrially deep.
Software has been mostly going the other direction. Each generation invents new component vocabularies, new build systems, new design patterns to internalize. The substrate underneath the creative work has not been industrialized. It has been re-invented, badly, every five years.
That is changing. The arc of industrialization that manufacturing and electronics walked first has lessons software can now use -- and the steps of that arc map cleanly to specific shifts that have arrived in software over the last decade.
Four moments that industrialized manufacturing
Eli Whitney delivered a contract for ten thousand muskets in 1798 with a property that hadn't been guaranteed before: any lock fit any musket. Before Whitney, every musket lock was hand-fitted. A broken part wasn't replaced -- it was re-fitted by a craftsman who could improvise to the assembly. Whitney's parts didn't have to match the gun; they had to match a spec. Variability became tolerance. Tolerance became the unit of standardization.
Henry Ford's assembly line at Highland Park in 1913 took Whitney's principle further. Standardized parts let workers be standardized too. Any worker could do any station's task. The Model T didn't depend on which artisan happened to be in the shop on any given day. Quality and throughput stopped depending on tribal knowledge in the heads of senior craftsmen. The system was the technology, not any one worker's skill.
The CAD/CAM revolution that began in the late 1950s and matured through the 1970s and 80s separated what to make from how to make it. Computer-Aided Design tools let engineers parametrize geometry rather than draw it freehand. Computer-Aided Manufacturing translated those parametric designs into machine instructions. Designer surprises -- will this fit, will this clear, will this be machinable -- collapsed because the spec was unambiguous. The design stayed creative; the path from design to fabrication became deterministic.
Industrial robots arrived in 1961 with Unimate at General Motors, doing welds. The robot didn't replace the engineer. It took the part of fabrication that didn't need judgment. Engineers moved up: design, supervision, quality, problem-solving. The floor under the profession rose. The work of being an engineer changed.
Each step took years to land. Each step raised the floor on what the profession could do. None of the steps replaced creative work -- they freed it from the parts that had been holding it back.
Mapping the arc to software
Each step has a software equivalent. Most of them have arrived in the last decade or two, and the arrival times -- when you line them up -- tell you where software is right now in its compressed version of the same arc.
Whitney's interchangeable parts → standardized vocabulary.
Software's standardized vocabulary in any given codebase has historically been local. This team's idioms. This framework's conventions. This language's mainstream patterns. Across teams, interchangeability dropped sharply -- a developer joining a new codebase has spent decades onboarding into local vocabulary because there was no inter-codebase standard. JBCT (Java Backend Coding Technology) commits to a small named vocabulary -- three containers, six patterns, one boundary primitive -- that's the same in any codebase that uses it. Any developer who knows the vocabulary can read any JBCT codebase. Interchangeability of parts (code structures) and of people (developers).
Ford's production line → JBCT as technology.
Ford's deeper contribution wasn't speed. It was that the standardization itself was the technology. The assembly line was a deliberately engineered system that produced consistent output regardless of which worker staffed any given station. JBCT positions itself the same way -- not a methodology you adopt to taste, but a deliberate technology that produces consistent code regardless of which engineer wrote any given module. The system is what makes consistency possible; consistency isn't expected to flow from individual discipline.
CAD/CAM → JBDT.
JBDT (Java Backend Design Technology), the methodology articulated in Java Backend Design Technology: A Process-First Methodology, is software's CAD/CAM. It separates what the system should do from how it's built. The designer answers a structured set of questions -- about boundaries, dependencies, modalities, and process shape -- and the answers are deterministic enough that the implementation isn't an open interpretation but a derivation. Designer surprises -- will this scale, will this be testable, will this be maintainable -- collapse because the spec is unambiguous. The design stays creative; the path from design to code becomes deterministic.
Industrial robots → AI.
AI assistants are the routine-work automation that arrived late in the manufacturing arc and is arriving now in software. They don't replace the designer. They do the parts of code production that are routine -- boilerplate, scaffolding, well-trodden compositions, test fixtures, documentation. Engineers move up: design, supervision, domain judgment, the parts of the work that benefit from human attention. The floor under the profession rises. The work of being an engineer changes.
The four steps line up. JBCT is software's Ford-with-Whitney's-parts. JBDT is software's CAD/CAM. AI is software's industrial robots. The catalyst that has put all of these in conversation simultaneously is AI -- but AI is not the industrialization. Large parts of JBCT existed in practice well before AI was useful -- patterns that were waiting to be named and unified. JBDT articulates the upstream design technology those patterns implied. Both reached their current articulated form with AI assistance, which is part of the point. AI didn't create the standardization; it crystallized standardization that was already there in practice. And that crystallization is what made the next step -- mechanical-work automation -- immediately available on top.
What this looks like in practice
The pattern is the same across all four steps. The substrate gets standardized. The creative work concentrates on what only humans can do.
In a JBCT codebase, the developer doesn't invent error-handling conventions, naming rules for types, or scaffolding for cross-cutting concerns. Those are standardized. The developer's attention goes to the domain -- what the business is trying to do, what the types should mean, where the boundaries genuinely lie.
Under JBDT, the designer doesn't invent a fresh design process for each project. The eight questions, the dependency-data graph, the six patterns -- those are standardized. The designer's attention goes to the answers -- what's actually true about this business, what this domain genuinely requires.
With AI assistance, the engineer doesn't write the boilerplate that the same engineer wrote a hundred times last year. The AI does. The engineer reviews, judges, integrates -- work that benefits from human attention because it requires judgment.
The result is not less work. It is differently distributed work. The profession does not shrink -- it grows in the parts that scale with creative attention. This is what happened in manufacturing. It is what happened in electronics. It is what is happening now in software.
This is the part the discourse usually misses. Less art, more engineering is sometimes read as a directive to make software more rote, more constrained, less creative. The actual move is the opposite. It concentrates the creative work where creativity earns its keep, by removing the thousands of small decisions that didn't need to be creative in the first place. Naming a type. Choosing an error-handling pattern. Deciding how to thread observability through a use case. All of these are standardizable. None of them was the part of the work that drew anyone into the profession.
Where the analogy bends
Software is not the same as manufacturing. The manufactured product is a physical thing whose properties don't change after it leaves the factory. Software's product is updated, extended, debugged, and reshaped continuously after delivery. The factory never closes. The bill of materials evolves. Knowledge work -- figuring out what to build, what it should mean, what edge cases lurk -- is more central in software than in cars or muskets, and that work resists the kind of standardization that reduces variability in physical parts.
That is true. It is also true that parts of software's production are standardizable in the same way physical parts are: the vocabulary, the patterns, the cross-cutting plumbing, the design questions. Electronics is the more honest analogy here. Electronics has the same continuous-update property in many senses -- firmware revisions, derivative designs, errata, board respins -- and electronics has industrially deep standardization despite that. The standardizable parts are the standardizable parts. The creative parts stay creative. The two layers don't compete.
What's still coming
The manufacturing arc took roughly 150 years from Whitney to mature CAD/CAM. The electronics arc took about 70, depending on where you start counting. The software arc has had about 70 years and is now hitting industrial-robots time -- compressed, but recognizable.
What's still missing in the software arc is the equivalent of standardized interfaces -- the USB, I2C, Ethernet of software. Standardized parts (vocabulary) and standardized processes (methodology) are the prerequisites for standardized interfaces, and the work of articulating those is now becoming possible.
The book in progress, Process-First Design, articulates one substrate for the next layer of standardization -- process composition vocabulary that holds across altitudes, recovery-class taxonomy, design-question stages, and how those connect. Whether that particular substrate becomes the standard or something else does is not the question. The question is what the appearance of any candidate signals: that the next layer has become workable, where a decade ago it would have been premature.
Closing
If you design a circuit today, you don't invent the resistor. You don't even think about not inventing it. The standardization is so deep that the question doesn't surface -- and the design work that does surface is dense with creative tradeoffs that the standardization made possible.
Software is reaching that moment. The substrate is being standardized -- vocabulary, patterns, design questions, the parts of the work that didn't need to be invented fresh each time. The creativity concentrates where it earns its keep: domain modeling, system architecture, the judgments that benefit from human attention.
Manufacturing took 150 years. Electronics took 70. Software is on compressed timelines, but the arc is recognizable. The substrate gets industrialized. The design stays creative.
This article is part of work on Process-First Design -- a forthcoming book on methodology for enterprise backend software. Earlier pieces in the series, including Saga Is Not a Pattern, develop specific implications of the principle described above.
