A week on from NXT BLD 2026, and the noise has settled enough to write something [hopefully] worth reading.
Last week I MC'd the Lenovo Stage on Day 1 - eighteen presentations across the day - and the NVIDIA-sponsored Software Development Stage on Day 2. I also presented What the Prototypes Showed, the working-through of the four agentic BIM prototypes I built earlier this year.
The social side was the best I've experienced at the event. Old faces, new faces, conversations that started on the floor and finished three hours later in a pub off Victoria. Ten years in, NXT BLD has earned the kind of trust that lets the conversations get to the actual point quickly. That matters more than the official programme some years.
I still have videos to catch up on from sessions I missed while running a stage. The first day's stream remains available here at the time of writing, and the full archive will appear at nxtaec.com over the coming weeks.
Being a host it was difficult to full absorb the presentations as you were always tracking down the next speakers. Of what I did see, three sessions are worth pulling out - not as a ranking, but as the talks that have stayed in my head a week later.
Matt Gough - Rebuilding the Construction OS
are we distributing the benefits equitably?
Matt opened with a line that did not get the pushback it would have got a year ago: AI-led automation has solved design.
It is a deliberately provocative framing, and worth taking seriously rather than dismissing on reflex. The claim is not that architects are out of a job. It is that the bottleneck has moved. The hard problem now is not generating the design. It is the fragmented, sequential, risk-multiplying delivery machine that consumes half the value of a project before a building is complete. AI tools that improve the design phase, without addressing the delivery machine downstream of it, will continue to produce firm-level efficiency gains that do not translate into project-level outcomes.
This is exactly the through-line KP Reddy pulled out of the a16z piece a few weeks ago, and which I wrote about in The Missing Player. Matt's case is the operational version of that argument - virtual vertical integration as the structural answer, with data and AI as the substrate that finally makes it possible.
The framing Matt then layered on top of that is the part that has stayed with me longest. Every major technology shift, he argued, forces a societal question alongside the technical one: are we distributing the benefits equitably? Mechanisation, the computer, the internet - each rewarded a narrow set of beneficiaries by default, and required deliberate choices later to spread the gains more widely. AI in construction will be no different unless the question is asked at the design stage rather than retrofitted afterwards.
The second move was the harder one. The reflex of any industry adopting a powerful new tool is to point it at the existing process and make that process faster. Matt's challenge was to refuse that reflex. He put a number on it: right now the industry is spending roughly 80 cents in the dollar on AI-based productivity improvements within existing workflows, and only 20 cents on genuinely new ways of working. His argument is that the ratio needs to be flipped. 80 cents on rethinking the system; 20 cents on improving the parts. The opportunity is not to use AI to improve the broken delivery machine - patching the same fragmented, sequential, risk-multiplying chain with smarter individual tools. The opportunity is to rethink the construction operating system itself. The same AI capability that could make the current process modestly more efficient could, if pointed at the system rather than its parts, make the current process unnecessary.
I do not know yet if I agree with the full strength of his framing. But it is the most ambitious thesis on what AEC technology should now be aiming at that I have heard publicly, and it is the talk that I have referred back to most in the conversations since.
Lucas Epp - Structural Design at the Speed of Thought
Branch was the surprise of the week for me, and my next piece is going to expand on this properly. Short version here: an architect's-eye view of a structural tool that finally solves the upstream feedback problem.
Structural decisions at early design stages have always been throttled by the time it takes to generate and evaluate options. The architect makes massing decisions, the structural engineer catches up days or weeks later, and the conversation about cost, carbon, and systems integration happens too late to influence the decisions that already shaped the building. Branch collapses that gap into real time, across materials, with enough depth to be useful rather than indicative.
The roadmap Lucas showed - more complex geometry, connection design, shop drawings, CNC files - extends the same logic downstream into fabrication. If they execute it, this is the structural counterpart to what the BIM 2.0 architecture-side challengers are doing. The same upstream conceptual phase, the same time horizon, the same shift away from authoring-as-bottleneck.
branch3d.com is on my watch list with more in a follow-up post.
Al Fisher - Inside Buro Happold's Development Practice
Al's session was the first of around half a dozen talks on my day two stage from leading practices on their in-house development work - a thread that, more than any single topic, defined the Software Development Stage this year. Buro Happold, Fosters+Partners, Zaha Hadid, and others all came at the same problem from different angles. Al's framing was the one I keep coming back to.
He walked through how Buro Happold builds software internally - not the tools themselves, but the system around them. How a tool moves from development through QA into release to the wider team. What gets versioned, what gets validated, what gets retired. The unglamorous machinery that determines whether internal software is an asset or a liability over the long run.
The point Al made that I keep coming back to: as AI compresses the cost of building the tools themselves and broadens who can actually develop them, the system around them matters more, not less. If anyone in your firm can spin up a calculation engine in an afternoon, the question shifts from can we build it to how do we know it is correct, how do we know who is using it, and how do we retire it when it stops being useful.
This is the same insight that landed for me from Richard Parker's a.engineer session. I am going to pull this thread out properly in an upcoming piece on what "agent" actually means, because it is the same shape of argument applied to a different problem.
What Tied the Week Together
The year-on-year shift in the room was the clearest I have seen at NXT BLD. In 2025 the question on the floor was should I use AI? In 2026 that question has gone. Everyone is in. The question now is how do we control it? - how do we trust the output, how do we govern its use, how do we keep it from quietly making decisions the firm cannot defend.
That is the question the programme reflected. The session-by-session focus was on capability and control: better agents, better outputs, better guardrails on individual tools. There was a huge amount of talk around Agents this year along with Design Intelligence.
The thing I think the conference did not spend enough time on - and which the in-house development thread was the closest the programme came to engaging with - is what sits underneath both questions: the system around the AI. Not the model. Not the agent. Not the prompt. But the systems that take these and turn them into repeatable, reusable processes.
That is my own opinion of where this needs to head, not a summary of where the room had landed. The capability and control questions are the right questions for this year. The systems question is the one I would like to see foregrounded at NXT BLD 2027.
This is the BIM 3.0 substrate question in a different costume. It is the same question Martyn Day raised in his agentic future of BIM cover story, and the same question Greg Schleusner has been pushing on for years.