Two important pieces of AEC software writing in years have landed within weeks of each other. A16z published Every Building You've Ever Been In Was Designed By Software Built in 1997 - a serious investment case for the industry. KP Reddy responded with a rebuttal that has been circulating among practitioners since: the industry already ran a version of this experiment, and the lessons matter.
Both deserve reading in full.
KP's central argument is that the BIM wave of the late 2000s and early 2010s improved the technology without moving the project-level outcome numbers - and that the reason was business model misalignment. Every party in the delivery chain was structured to optimise for their own position rather than the project, and better software just gave each of them a better tool for doing exactly that.
That's mostly right. But it does the previous wave a partial disservice, and the missing nuance matters for what to watch this cycle.
Two other forces were running alongside the business model problem. Marketing overpromised what BIM software could actually deliver in that period - the pitch consistently ran ahead of the product, which made adoption painful in ways that weren't anyone's commercial fault. And the conceptual jump from 2D drafting to BIM was simply too large for many architects to absorb at the pace the industry asked of them, especially when the software still couldn't quite catch up. It's easy to see the promise of new technology if you live and breathe it. It's much harder to deploy that vision across thousands of practitioners whose existing workflow already works.
The business model was the deepest cause. It wasn't the only one. Capability and human-side adoption mattered too - and all three forces are in play again now.
That's not the thread I want to pull on most, though. There's something else neither piece quite follows through on.
KP makes the point bluntly: in the entire a16z piece, the owner appears exactly once - as the party who funds the project and sets the brief.
That's true. And it's strange. The owner is the only party with a structural interest in the whole picture - both the delivery phase and the fifty years that follow. They pay for the overruns and the change orders during construction. They pay for the energy, the maintenance, the rework, and the litigation afterwards. They occupy the building for 30 to 50 years after the design firms have moved on.
The overrun point is worth pausing on, because a16z's framing slides past something important. The $100B+ opportunity they describe is, in a real sense, theoretical money. It isn't a pot sitting somewhere waiting to be paid out. Contingencies exist, but there isn't $100 billion in savings parked in owners' accounts for software to redirect into fees. If projects delivered on time and on budget, the money simply wouldn't have been spent in the first place. The return to the owner isn't a line item you can bill against - it's the capacity to deploy the same capital into the next project, and the one after that, instead of absorbing overruns on this one.
That distinction matters for the business model. You can't straightforwardly capture a share of savings that never materialised. Capturing value here depends on owners recognising the counterfactual - and structuring contracts that reward it - which is exactly the problem KP flagged about the previous wave.
And yet every AI-for-AEC thesis being written right now - a16z's included - is structured around selling software to the firms that build the building, not the firm that lives with it.
There's a reason for that. The delivery firms have software budgets, procurement processes, renewal cycles. Owners are discontinuous. They commission something, move on, and go back to running hospitals or managing property portfolios.
That is also why the industry's technology evolution keeps producing firm-level efficiency gains that don't translate into project-level outcomes. The software optimises for the people buying it. The party bearing the lifecycle cost isn't buying it.
This is where I part ways with both pieces - not as disagreement, but as the obvious next question.
If AI genuinely unlocks the $100B+ a16z describes, the value accrues to whoever sits at the data consolidation point. Every large-scale software market works this way. In sales, it was the CRM. In finance, the ledger. In AEC, three decades of BIM evolution have assumed the consolidation point is the authoring environment - Revit, its challengers, whatever replaces them.
I don't think that's right anymore. The authoring environment is where the building is designed. The operational data layer is where the building lives. And for the first time, AI makes it economically tractable to maintain that layer at lifecycle scale - reconciling as-designed with as-built, ingesting sensor and work-order data, answering the questions an owner actually has about an asset they will own for half a century.
Whoever builds that is not competing with Revit. They're building something that makes Revit a subsidiary concern - the production tool that feeds the real system of record.
This is also what closes the phantom-money loop from earlier - on one condition. The data asset has to demonstrably reduce overruns on the next project. If it does, the savings that were theoretical on this project become compounding returns across the owner's portfolio. The asset is the mechanism by which overruns come down on the next building they commission, and the one after that. That's a line item. That's billable. If it doesn't - if the asset is just more documentation - owners won't pay for it. They've seen plenty of documentation already.
That is the shift I've argued sits behind BIM 3.0. The a16z / KP Reddy exchange is the clearest public articulation yet of why it matters.
If you're deploying capital into AEC software this cycle, the question I'd ask isn't which of a16z's three approaches to back. It's which of them produces the data asset the owner eventually needs - and which of them just makes the delivery chain modestly more efficient on the way to the same outcome as last time.
For the forward-looking argument on where the lifecycle data layer sits, see What BIM 3.0 Might Look Like. For the moat analysis underneath it, The AEC Software Moat Map.