Great breakdown of where AI can unlock value in AEC.
One thing that feels underappreciated here: this isn't just a tech problem, it's an adoption problem.
I'm a structural PE who graduated nearly 15 years after Autodesk acquired Revit — and it still wasn't widely taught in schools. Early in my career we were drafting in 2D because that's what the partners used. On the owner side later, I was challenged by architects, engineers, and contractors when I worked to introduce new tools even when the case for switching was obvious.
In AEC, tools don't win in isolation. They win when they can pull the entire project network with them.
AI will unlock real gains in design. But that may just shift the bottleneck downstream. Construction is still fundamentally constrained by who can execute the work, especially in hazardous, variable, or labor-limited environments.
The next wave won't just be better design tools. It'll be systems that expand who or what can actually build.
Flyvbjerg analysed 16,000 projects. 8.5% finished on budget and on time. 0.5% delivered on budget, on time, and with the promised benefits. Half a per cent. Your numbers, $177 billion in waste, 70% of rework from design errors, land in the same place. The diagnosis isn't in dispute.
But all three attack vectors target the interface layer. Replace Revit, build around Revit, automate what sits on top of Revit. None of them addresses why 70% of rework stems from design errors in the first place. It's not because the software is slow. It's because nobody engineered the decision architecture underneath. Who owns which decisions, what evidence they're based on, and whether there's a traceable chain from assumption to output.
Automating MEP design in minutes is impressive until someone asks: against whose load data, approved when, by whom, against which version of the brief? Those aren't software questions. They're governance questions. No tool, from 1997 or 2026, answers them.
The 18-month window is real. But it's not a window to adopt better tools. It's a window to build the decision layer before the tools arrive, so they compound instead of accelerating the same dysfunction at a higher speed.
The diagnosis is the same. The gap is not what AI knows but what AI can reach. Engineering data is private, spatial and locked inside proprietary formats that language models have no mechanism to interact with.
Your piece frames three attack vectors. We think there is a fourth: build the infrastructure layer that connects AI to engineering software in the first place. That is what we are doing at Bite. We build proprietary tools that natively read and write to structural engineering software. LLMs handle language and intent. Our tools handle engineering execution. The engineer makes the decisions.
Starting with structural engineering, paying design partners live, in WSP UK 2026 Digital Innovation Strategy. Would welcome the conversation.
The infrastructure framing is closer to the real problem than the three vectors in the main piece. "What AI can reach" is a better question than "which software to replace."
But reaching the data is a plumbing problem. The harder question is what happens after the data is accessible: who owns the decision it feeds into, what evidence standard applies, and whether there's a traceable chain from input to output that survives a contractor's query on site. Most of the 70% of rework that traces to design errors isn't caused by inaccessible data. It's caused by decisions made without governance, unclear ownership, unversioned assumptions, and no audit trail.
Getting AI into engineering software is necessary. It's not sufficient. The decision layer between the data and the output is where the cost actually accumulates.
We’re very aligned with you. We’re working intently on audit trails and our live v1 has this feature because we believe it’s critical for the golden thread requirements of the Building Safety Act.
We believe the liability always rests with the engineer and we take an engineer in the loop design approach to allow for explicit approval and we’re working to enable rollback of changes but all within the context of robust audit trails.
Good to hear. Audit trails and engineer-in-the-loop are the right starting point. The Building Safety Act's golden thread requirement is going to force this across the industry whether firms are ready or not. Happy to chat. DM me on LinkedIn.
The "build around vs. replace" framing is the most interesting part of this piece to me.
The SAP analogy is spot on: nobody killed SAP by building a better ERP, they just made it irrelevant layer by layer.
I'd bet the same playbook works here. The firms that win won't be the ones asking engineers to abandon Revit cold turkey, they'll be the ones that make engineers forget they're even using it.
- "Almost every engineer and architect who enters the workforce already knows Revit" is extremely inaccurate. They know of it, or have used it briefly on class projects, but they do not know how to use it for real world projects. It's like saying a guy who plays Microsoft Flight Simulator on semi-realistic settings knows how to fly a 737.
- If any builder wants to know how to take down Revit piece by piece, just hop into any Autodesk forum and look at the thousands of similar questions that people who use the software have been asking for over a decade without any fixes or updates from Autodesk.
- The most difficult part in all this will be getting an industry that is always lagging behind to adopt a new product. Companies refuse to adopt software that will save them time and money constantly in AEC. Clients are also difficult - I work with one of the largest cloud computing companies in the world and they won't let us design their data centers in the Revit cloud due to security concerns which costs an unbelievable amount of coordination time.
PlanGrid, & FMI. (2018). Construction Disconnected: Rethinking the management of project data and mobile collaboration to reduce costs and improve schedules. PlanGrid.
When will Revit/BIM address the foundation: principles of physics which should govern how we design and build. Stop massaging the wooden leg!
Which is exactly the same of all the banks that you bank with and most of mission critical system you interact with are built in a cose from 1947 (COBOL)
Seems like all of the discussions should move to a simulation stage. Then you'd be able to run scenarios and see what shakes out. Ireland is about to spend $BB to put a transport tunnel around Dublin to ease congestion. They'll probably use one of these programs but maybe they'll follow Moscow and use water taxis instead, it would be cheaper, faster and cause less disruption while being more environmentally friendly. The cities share infrastructure issues like building around historic buildings and streets. The water taxis mean less shaking.
The SIM Lab at OSU might be able to provide some answers to all the questions, while saving time and investor/government cash. The last time I had reason to look at them was 2014 when they were running scenarios about building a EV charging network in Ohio.
The 1997 software problem runs deeper than incumbency. AEC has near-zero risk tolerance because a bug in a hospital design or structural analysis has consequences you can't undo with a hotfix. That's why every successful entrant starts at the low-stakes periphery and works inward rather than attacking the core on day one.
Design software isn't the only AEC tool stuck in 1997; scheduling has the same problem. P6 has been the industry standard for decades, but its complexity keeps the office and field disconnected. Modern scheduling software with AI is finally making it possible to close that gap. That's what we're building at Planera. Great piece.
Love all the stats. Great job!
Great breakdown of where AI can unlock value in AEC.
One thing that feels underappreciated here: this isn't just a tech problem, it's an adoption problem.
I'm a structural PE who graduated nearly 15 years after Autodesk acquired Revit — and it still wasn't widely taught in schools. Early in my career we were drafting in 2D because that's what the partners used. On the owner side later, I was challenged by architects, engineers, and contractors when I worked to introduce new tools even when the case for switching was obvious.
In AEC, tools don't win in isolation. They win when they can pull the entire project network with them.
AI will unlock real gains in design. But that may just shift the bottleneck downstream. Construction is still fundamentally constrained by who can execute the work, especially in hazardous, variable, or labor-limited environments.
The next wave won't just be better design tools. It'll be systems that expand who or what can actually build.
Flyvbjerg analysed 16,000 projects. 8.5% finished on budget and on time. 0.5% delivered on budget, on time, and with the promised benefits. Half a per cent. Your numbers, $177 billion in waste, 70% of rework from design errors, land in the same place. The diagnosis isn't in dispute.
But all three attack vectors target the interface layer. Replace Revit, build around Revit, automate what sits on top of Revit. None of them addresses why 70% of rework stems from design errors in the first place. It's not because the software is slow. It's because nobody engineered the decision architecture underneath. Who owns which decisions, what evidence they're based on, and whether there's a traceable chain from assumption to output.
Automating MEP design in minutes is impressive until someone asks: against whose load data, approved when, by whom, against which version of the brief? Those aren't software questions. They're governance questions. No tool, from 1997 or 2026, answers them.
The 18-month window is real. But it's not a window to adopt better tools. It's a window to build the decision layer before the tools arrive, so they compound instead of accelerating the same dysfunction at a higher speed.
We published our thesis on this exact problem yesterday, one day before yours: https://www.bite.engineering/p/advancing-ai-capability-for-the-built-environment
The diagnosis is the same. The gap is not what AI knows but what AI can reach. Engineering data is private, spatial and locked inside proprietary formats that language models have no mechanism to interact with.
Your piece frames three attack vectors. We think there is a fourth: build the infrastructure layer that connects AI to engineering software in the first place. That is what we are doing at Bite. We build proprietary tools that natively read and write to structural engineering software. LLMs handle language and intent. Our tools handle engineering execution. The engineer makes the decisions.
Starting with structural engineering, paying design partners live, in WSP UK 2026 Digital Innovation Strategy. Would welcome the conversation.
The infrastructure framing is closer to the real problem than the three vectors in the main piece. "What AI can reach" is a better question than "which software to replace."
But reaching the data is a plumbing problem. The harder question is what happens after the data is accessible: who owns the decision it feeds into, what evidence standard applies, and whether there's a traceable chain from input to output that survives a contractor's query on site. Most of the 70% of rework that traces to design errors isn't caused by inaccessible data. It's caused by decisions made without governance, unclear ownership, unversioned assumptions, and no audit trail.
Getting AI into engineering software is necessary. It's not sufficient. The decision layer between the data and the output is where the cost actually accumulates.
We’re very aligned with you. We’re working intently on audit trails and our live v1 has this feature because we believe it’s critical for the golden thread requirements of the Building Safety Act.
We believe the liability always rests with the engineer and we take an engineer in the loop design approach to allow for explicit approval and we’re working to enable rollback of changes but all within the context of robust audit trails.
Would love to chat !
Good to hear. Audit trails and engineer-in-the-loop are the right starting point. The Building Safety Act's golden thread requirement is going to force this across the industry whether firms are ready or not. Happy to chat. DM me on LinkedIn.
Great, just sent you a connection request. My name is Daniel Anyanya
The "build around vs. replace" framing is the most interesting part of this piece to me.
The SAP analogy is spot on: nobody killed SAP by building a better ERP, they just made it irrelevant layer by layer.
I'd bet the same playbook works here. The firms that win won't be the ones asking engineers to abandon Revit cold turkey, they'll be the ones that make engineers forget they're even using it.
Great post with a few notes from me:
- "Almost every engineer and architect who enters the workforce already knows Revit" is extremely inaccurate. They know of it, or have used it briefly on class projects, but they do not know how to use it for real world projects. It's like saying a guy who plays Microsoft Flight Simulator on semi-realistic settings knows how to fly a 737.
- If any builder wants to know how to take down Revit piece by piece, just hop into any Autodesk forum and look at the thousands of similar questions that people who use the software have been asking for over a decade without any fixes or updates from Autodesk.
- The most difficult part in all this will be getting an industry that is always lagging behind to adopt a new product. Companies refuse to adopt software that will save them time and money constantly in AEC. Clients are also difficult - I work with one of the largest cloud computing companies in the world and they won't let us design their data centers in the Revit cloud due to security concerns which costs an unbelievable amount of coordination time.
Sabin Lupan 4m
PlanGrid, & FMI. (2018). Construction Disconnected: Rethinking the management of project data and mobile collaboration to reduce costs and improve schedules. PlanGrid.
When will Revit/BIM address the foundation: principles of physics which should govern how we design and build. Stop massaging the wooden leg!
Which is exactly the same of all the banks that you bank with and most of mission critical system you interact with are built in a cose from 1947 (COBOL)
Seems like all of the discussions should move to a simulation stage. Then you'd be able to run scenarios and see what shakes out. Ireland is about to spend $BB to put a transport tunnel around Dublin to ease congestion. They'll probably use one of these programs but maybe they'll follow Moscow and use water taxis instead, it would be cheaper, faster and cause less disruption while being more environmentally friendly. The cities share infrastructure issues like building around historic buildings and streets. The water taxis mean less shaking.
The SIM Lab at OSU might be able to provide some answers to all the questions, while saving time and investor/government cash. The last time I had reason to look at them was 2014 when they were running scenarios about building a EV charging network in Ohio.
The 1997 software problem runs deeper than incumbency. AEC has near-zero risk tolerance because a bug in a hospital design or structural analysis has consequences you can't undo with a hotfix. That's why every successful entrant starts at the low-stakes periphery and works inward rather than attacking the core on day one.
Design software isn't the only AEC tool stuck in 1997; scheduling has the same problem. P6 has been the industry standard for decades, but its complexity keeps the office and field disconnected. Modern scheduling software with AI is finally making it possible to close that gap. That's what we're building at Planera. Great piece.