Last week I wrote about specification quality - the idea that the binding constraint in AI-assisted development has shifted from can it be built to can it be described clearly enough. This is the follow-up to that piece, and it takes a different angle: not the craft of building, but the competitive structure of the market.
Because there are two things that have changed significantly in the last year, and the implications for anyone building or investing in AEC software are real - and underappreciated.
The Two Accelerants
AI coding capability. What an AI model can actually build from a clear specification has improved dramatically. Not incrementally - dramatically. The gap between "I could describe this workflow" and "I have a working application" has compressed in a way that wasn't true even twelve months ago. Sixty to seventy percent of a typical construction management platform - document management, RFIs, submittals, issue tracking, cost management - consists of standard web application patterns. Solved problems that can now be assembled quickly with a well-specified brief.
Open-source AEC tooling. This is the less-discussed accelerant, and arguably the more important one for the industry. The open-source BIM library ecosystem has matured significantly. That Open Company has done substantial work making IFC tooling accessible - their components stack makes browser-native BIM viewers and model interrogation tools a realistic starting point rather than a research project. ifcopenshell continues to mature. xeokit remains a serious foundation for web-based visualisation. And the ecosystem keeps moving: projects like ifc-lite - a browser-native IFC viewer built on WebGPU rendering and a Rust/WASM parser - are pushing the performance ceiling of what's achievable without a plugin or install. The net effect: the BIM-native layer that was previously a hard technical barrier - IFC parsing, model federation, geometric processing - now has credible open-source answers, and those answers are getting faster and more capable.
The combination is what creates the genuine inflection. AI can assemble the 60–70%. And the remaining 30–40% - the BIM-native layer - is no longer a moat by default. It's a moat where the open-source tooling doesn't reach yet.
Where the Moats Are Holding
BIM authoring environments. Revit, ArchiCAD, Vectorworks. The depth of workflow integration, training ecosystems, file format dependencies, and the parametric complexity of full production authoring represent real switching costs and real engineering challenges. The open-source libraries have improved most in the downstream, model-consumption direction. The authoring direction - producing a parametric BIM model - remains genuinely hard.
The BIM 2.0 challenger landscape makes this point clearly, and not in the way the challenger narrative would have you believe. Arcol, Snaptrude, Motif, and others are positioning as next-generation authoring environments, but in practice they're currently focused on early-stage conceptual design. Qonic is the only current player explicitly pursuing detailed authorship. The rest are building core geometry engines from scratch - well-funded, talented teams taking years to reach parity with a single phase of Revit's workflow. That tells you something about the scale of the problem. BIM 1.0 incumbents, counterintuitively, have a stronger position relative to BIM 2.0 challengers than the challenger narrative suggests. The transition will come. It's measured in years, not months.
Enterprise governance. SSO, audit trails, procurement relationships, compliance certifications. Genuinely sticky at enterprise scale and has nothing to do with whether the underlying software could be replicated.
Where the Moats Are Weakening
Non-authoring BIM tools. The category to watch most closely. Clash detection, quantity surveying, model checking, model-based analysis: all downstream of authoring, all operating on a model someone else produced. The combination of mature open-source tooling and AI-assisted query and analysis means the gap between "I have an IFC file" and "I can do useful things with it" has narrowed substantially. If your product is essentially an interrogation and workflow layer on top of a model, your moat is thinner than it was.
"UI on top of an open engine." Energy analysis on EnergyPlus. Carbon calculation on openLCA. Model visualisation on xeokit. If the underlying engine is open and the differentiation is interface and workflow, the barrier to competitive entry is dropping. Products in this category need to be honest about where their value genuinely sits.
Generic CDE functionality. Document management, transmittals, issue tracking, RFI workflows are commodity web application patterns. This layer is the most straightforwardly replicable - and that was true before the current AI capability jump.
Structural analysis. AI-assisted structural tools are already performing well at a level that surprises people. The underlying FEA solvers - OpenSees, CalculiX - are open source and mature. This moat is thinning faster than the other safety-critical categories.
What's Actually Different Now
The pre-AI question was: can a competitor build a comparable product? The answer was usually yes, eventually, at significant cost and time.
The post-AI question is different: can a well-specified team assemble a comparable product in a meaningful fraction of the time? For the exposed categories, the honest answer is yes - and "meaningful fraction" is now weeks to months for some of them, not years.
That doesn't mean every AEC software product is suddenly under threat. Enterprise relationships, service infrastructure, brand trust, and the genuine operational overhead of running production software at scale all matter. But the "too hard to replicate" assumption - which underwrites a lot of product and pricing decisions - needs to be stress-tested against a more capable competitive context.
The Opportunity Side
It would be a mistake to read this as a threat narrative only. The same two accelerants that compress competitive moats also dramatically expand what AEC software companies can offer.
AI embedded into existing products - not as a feature, but as a delivery mechanism - can build capabilities that weren't commercially viable to develop before. That Open Company's open-source components mean that BIM-native features can be added to products that previously couldn't justify the engineering investment. The companies that move first to deepen their product using these tools raise the bar for what any open-source alternative would need to reach - and buy themselves a meaningful runway in the process.
The window isn't closing. It does, however, require a clear view of where you actually stand.
If you're building or investing in AEC software and want to work through what this shift means for your product strategy or commercial model, I'd welcome the conversation.