Software’s Prefab Moment — From Artisan Craft to Assembly Line Code

History doesn't repeat, but it sure does rhyme. Software engineering today, driven by AI code generation, parallels the explosive growth of Chicago in the 1830s. The software engineering industry is having its balloon framing moment.

Outside of software, an interest I am passionate about is urbanism, public transit, and pedestrian-friendly infrastructure. I enjoy learning about the fabric of cities, something "A Paradise of Small Houses" by Max Podemski covers eloquently. The book examines how technological and societal advancements fueled the growth of cities like New York, Philadelphia, and Chicago. The chapter about Chicago brought on some enlightenment about the current state of software development, of all things, and that is where my focus will be for this article. What happened in Chicago over decades is playing out in our industry right now, compressed into a few years.

What Is Balloon Framing?

Balloon framing is a construction technique where long continuous vertical studs run from the foundation sill to the roof, with floor joists nailed to the sides of these studs. To understand why this is important, you must understand that constructing homes was done by skilled artisans. Wood buildings had to be erected using heavy timber frames with mortise and tenon joints. One beam is notched (the mortise) to receive a protruding tongue (the tenon) from another beam, then pegged together. This joinery required skilled craftsmen and was time-consuming and labor-intensive. Each joint had to be precisely cut and fitted, making every home somewhat unique to the materials and the construction process. With the advent of mass-produced nails and machine-cut dimensional lumber in the late 1830s, balloon framing fundamentally changed construction. Workers could now follow a standardized process, simply nailing uniform lumber pieces together on-site. This standardization meant that building designs could be replicated, construction methods could be taught quickly, and homes could be erected by general laborers rather than master craftsmen. The work itself became standardized—dramatically reducing both the skill level and time required.

Why Standardization Supercharged Chicago

Chicago experienced unprecedented growth in the 1800s. Land was inexpensive and flat, creating a perfect environment for speculation. Investors and settlers bet on the city's expanding perimeter, driving demand for rapid home construction to capture the value of newly developed land. The balloon construction technique was integral to meeting this speculative demand, allowing a couple of guys and a horse to build a home in a couple of weeks. This ease and speed of construction enabled Chicago to expand at an extraordinary pace. Buildings sprouted up across the landscape faster than supporting infrastructure could develop. The consequences of this growth-at-all-costs approach became self-evident during the Great Chicago Fire of 1871. The rapid construction prioritized speed over safety, creating dense wooden neighborhoods with inadequate fire breaks and prevention systems. When the right conditions converged (drought, high winds, and densely packed wood construction), the ubiquitous balloon-framed buildings became fuel for catastrophe. The very technique that built the city so quickly helped it burn just as fast.

How Is AI Code Similar To Standardized Lumber?

Hopefully, the parallels between balloon framing and AI-generated code are self-evident. Just as balloon framing replaced complex joinery with simple nailing of standardized components, AI allows developers to quickly assemble software without hand-crafting every detail. With the ability for AI to generate code, the need for artisans has diminished. We likely won't see a singular catastrophic "Chicago Fire moment" for the software industry, but we may witness an increase in fragile codebases that are difficult to diagnose and repair. As institutional knowledge gets AI-shored, understanding the why behind design and implementation decisions will become increasingly challenging.

Just as increased output decreased the attention paid to each home's quality, this productization will continue to erode software implementation uniqueness. Because not every software project is unique, the need to notch and peg custom software is reduced. That does not mean the role of the artisan is removed; it simply divides those who are passionate about the craft from those who are just building within it. The reduced manual workload can keep team sizes smaller and can make feature development prefabricated implementations.

I believe this advancement unfortunately leads to the incorrect assumption that the work itself is now commoditized, which is simply untrue. While AI can generate code like balloon framing enabled rapid construction, understanding what to build, why, and how it fits together still requires expertise. The hard part of software development has shifted from hand-crafting every line to orchestrating complex systems with powerful tools. Just as balloon framing didn't eliminate the need for architects, structural engineers, and skilled contractors who understand building codes and design principles, AI doesn't eliminate the need for developers who understand system architecture, security, and user needs. The work itself still needs to be done by people who know what they're doing; it's the tools that have changed.

What Does This Mean For The Software Industry?

I can't predict the future with certainty, but the pattern emerging mirrors historical precedent. We've already seen initial productivity gains, though some studies question whether these are real or merely perceived. What follows appears to be a contraction in the generalist developer workforce. Those who treated development as pure execution work, building basic CRUD pipelines as a trade rather than a craft, will likely find their roles diminished.

This sounds pessimistic, but it's not the whole story. Three shifts are emerging that mirror what happened in construction. First, domain-specific specialists will become more valuable as the unique complexities of different domains like finance, healthcare, and infrastructure aren't easily transferable or automated. More surprisingly, the ease of construction paradoxically increases project scope. Just as balloon framing enabled larger buildings built more quickly, AI-generated code enables more ambitious projects. But more is not better. Increased generative capability does not automatically translate to increased quality. In the intermediate term, we may see larger, more fragile projects as the ability to generate code outpaces the wisdom of what to build and how to maintain it. This means more developers may be needed, not just to build, but to manage and stabilize the increased complexity. Third, baseline expectations are rising. What was once acceptable as a minimal viable product, like the modest starter homes of the past, is no longer the standard. Even small projects are expected to have the polish and features that ease of construction now makes achievable. The future of software development isn't uncertain. It's simply evolving into something different.

What Should Leaders Do?

The construction industry offers a useful playbook. After balloon framing became standard, successful construction companies didn't stop hiring general laborers. They invested in two parallel tracks: generalists who could execute standardized work, and specialists who understood the nuances of their domains. The same model applies to software.

Continue hiring junior developers as generalists. They are the talent pool from which your future specialists will emerge. Just as construction workers learn the basics before specializing in electrical, plumbing, or HVAC, junior developers need time working across the stack to discover where their interests and aptitudes lie. Cutting off this pipeline because AI can generate code is like construction firms in the 1840s refusing to hire anyone because balloon framing made building "too easy." You're not just hiring for today's tasks. You're cultivating tomorrow's experts.

At the same time, deliberately invest in building specialized teams. Most people understand that electricians and plumbers are specialized construction workers with distinct skill sets. Software faces even more specialization because the work is so broad. A payments infrastructure specialist and a real-time video streaming engineer may both write code, but their domain knowledge, performance considerations, and failure modes are as different as residential framing and high-rise construction. A payments engineer understands PCI compliance, idempotency, and distributed transactions. A video streaming engineer deals with codec optimization, adaptive bitrate streaming, and CDN architecture. These are genuinely different disciplines. Organize teams around these specializations rather than treating all developers as interchangeable resources.

The master-apprentice model will likely return as teams become smaller and more focused. This is natural maturation. Medicine didn't become less valuable when it specialized into cardiology, neurology, and oncology. Construction didn't diminish when it separated general contractors from structural engineers and licensed tradespeople. Software engineering is following the same path. Leaders who recognize this and structure their organizations accordingly will have a significant advantage over those who treat AI code generation as a simple cost-cutting opportunity.

It doesn't matter how uncomfortable or displacing these changes feel. Individuals will adapt because market forces will ensure that firms with properly structured teams dominate those slower to respond. The question isn't whether to adapt, but whether you'll be properly positioned when the AI hype dust settles and the subsidies run out. That moment will separate organizations that built durable competitive advantages from those scrambling to reposition. The shift is happening regardless. Your only choice is timing.