Over the past several months, the Center for Offsite Construction has been in dialogue with Josh Lobel about the future of AEC, the role of data in reshaping the industry, and the persistent question of why construction innovation so rarely reaches scale. Recently, Josh shared this essay by researcher Sara Hooker that gave both of us a sharper language for an old frustration: the sense that good ideas in construction do not rise or fall on merit alone, but on whether they fit the larger system around them.

What followed was a conversation about AI, industrialized construction, forgotten failures, and why the next era of building will require more than better products. It will require new infrastructure around those products. Below is an edited transcript of that exchange. Source transcript:

Editor’s note: This conversation has been lightly edited for clarity and length. Josh is an employee of Autodesk, but this conversation represents his own thoughts and opinions and does not necessarily represent the view of Autodesk.

Jason Van Nest: Hi Josh. Over the last week or so, we’ve been circling a question that feels increasingly urgent: why does construction innovation keep stalling? When you sent us Sara Hooker’s essay it seems to have opened the floodgates.

Josh Lobel: It did. We’ve had smart people working on these problems for decades. We’ve had enormous amounts of money thrown at them. And still, we haven’t unlocked scale. At some point, you have to ask whether we’ve been framing the problem incorrectly. That’s exactly why Sara’s essay hit me so hard. It felt like something clicked, it unlocked a new way of framing the “why” question.

Hooker’s point, in the context of AI, is that innovation doesn’t happen because the best idea simply wins, in fact it suggests that the concept of a best idea doesn’t make sense outside of its context. Rather, innovation happens only when several contextual conditions line up. Neural networks existed for a long time, but the nature of how CPUs functioned at the time constrained their efficacy and they only became practical when GPUs were put to the task and made them workable. What’s important is that this was an entirely unimagined use case for GPUs. What we now think of as modern AI emerged from that serendipitous overlap of the “right” algorithm, software, and hardware – a triad of key criteria.

Jason: In other words, a winning path for innovation was not guided by pure conceptual meritocracy. It was the path who’s fitness matched the surrounding conditions.

Josh: Exactly. And once that alignment takes hold, investment flows into it, which can lock out other possible directions. That felt very relevant to how progress has, and hasn’t, happened in AEC. For a while now the industry seems to act as if technology is the missing piece. We assume that if we just fund enough software, or enough smart people, the rest of the problems will get resolved. But that’s not what history shows.

Jason: Right. The analogy keeps opening outward. In construction, maybe the “triad ” is not hardware, software, and algorithms in the AI sense, but some equivalent set of interdependent systems: 

• In ETO, AIA contracts as the algorithm, BIM as the software, hammers as the hardware.
• Or in offsite logistics as the algorithm, AutoDesk as the software, and modules as the hardware.

It’s so productive to think through co-dependencies with this framework, because, innovation in AEC depends on multiple systems moving together.

Josh: Which is where the essay’s reference to the Anna Karenina principle becomes useful. In a complex system, success requires all key factors to be in place, while failure can result from any one of them being missing. That gives us a much better frame.

For years, people have described the problem as low productivity or lack of innovation. But those are symptoms. They are not the actual problem statement.

Jason: That has been central to our thinking at the Center. We argue that construction is trying to move from Engineer-to-Order to Configure-to-Order. That is not a minor improvement. It is a paradigm shift.

You cannot get there just by making better bathroom pods, or better panels, or better software. Unless the interfaces are standardized, unless contracts change, unless the market structure changes, you end up with awkward hybrids. Products still behave like services. Services get stuffed into product-shaped packages. Every firm is improvising.

Josh: And that helps explain why the industry keeps repeating itself.

One example that comes to mind is Operation Breakthrough. If you read the documents around it, the language sounds remarkably current: housing crisis, industrialized building, performance criteria, federal support. It was a serious attempt to unlock change. But most people working in this space today barely reference it, if they’ve even heard of it at all.

That absence matters. If you do not understand the history, you cannot explain why your effort might succeed where earlier efforts failed.

Jason: I had the same reaction. When you dig into Operation Breakthrough's documentation at HUD (specifically the Housing Systems Proposals) , you see commercial plays that rhyme directly with today’s firms: volumetric approaches, pod-and-panel approaches, bathroom pod strategies. Looking back fifty years and finding the same basic solutions… oh dear. That tells you that we face a problem that is deeper, more structural.

That is also why the Center exists. We are trying to build missing infrastructure that will enable this kind of market.

Hitherto, offsite efforts did not have were shared interface standards -- between products and buildings. They did not have legal frameworks aligned with product-based delivery. They did not have a file structure capable of carrying not just geometry, but the rules, constraints, and chain of custody that Configure-to-Order delivery requires.

Josh: That’s the part I find so compelling in the Center’s work. The effort is not just to advocate for industrialized construction, but to create the commons that would let industrialized construction actually function as a system.

Jason: Thanks. At the Center, we are writing interface standards. We are developing legal and contractual thinking that better fits the Uniform Commercial Code. We are exploring the Configure-to-Order file type as something that holds both design geometry and business logic. The goal is to make it more likely that different products, firms, and processes can actually work together.

That is why this conversation has been energizing. It reinforces the idea that no single company can solve the transition on its own. This has to be ecosystem work.

Josh: I totally agree, and it was one of your recent posts about this essay that led me to another term I wasn’t familiar with but helps frame this conversation: the word zemblanity, which is the opposite of serendipity. If serendipity is a pleasant surprise, zemblanity is an unpleasant unsurprise – mistakes that are predictable and structurally inevitable rather than random misfortune. It’s bad luck by design.

That feels like a very good description of AEC. My belief is that many of the failures we keep seeing to transform AEC are not random. They are structurally predictable. They happen because the necessary industry conditions were never aligned in the first place.

Jason: That’s a perfect way to put it.

Josh: And it brings us back to the larger point. In a system as complex as AEC, you cannot hope that solving one piece will cause the rest to fall into place. The challenge is not simply to invent better products. It is to align the underlying conditions that allow those products to succeed.

Jason: That's the work ahead.

Josh: And exactly why the conversation is worth continuing.