Construction AI on DCW eve: the EY×Cambridge case, estimating that pays back, and Grok Build's worktree trick

EY published "The intelligence layer: how agentic AI can connect the infrastructure industry" on 6 May, with academic evidence from the University of Cambridge's Laing O'Rourke Centre for Construction Engineering and Technology and the Centre for Smart Infrastructure and Construction, real-world technology examples from NVIDIA, and additional input from Futurity Systems. It hasn't had the airtime it deserves in the UK trade press, but it's the strongest piece of evidence-backed infrastructure-AI thinking I've seen this year - and the kind of report you can put in front of an infrastructure board or a finance director without having to defend the source.

The argument is precise. Infrastructure productivity isn't constrained by a shortage of technology; it's constrained by fragmentation - BIM, ERP, scheduling, sensor data, supply chain systems all running in parallel without speaking to each other. Agentic AI's actual job is to act as an intelligence layer across those silos, not to be another vertical tool bolted on top. The Cambridge review of 100+ construction productivity studies underpins the diagnosis, and the headline statistic that tends to land in client conversations is that rework alone can absorb up to 15% of total project cost. That's the number to use when someone asks why bother.

For DCW conversations specifically, the report gives you two useful frames. First, when a vendor describes their product as "AI-powered", ask where it sits in the intelligence layer - does it just produce more data, or does it actually connect systems that were previously disconnected? Second, when an internal stakeholder asks about ROI, the rework number is more honest than vendor savings claims, because it's a measured industry baseline rather than a self-reported case study.

A frame for the week: Read the report tonight. Tomorrow at ExCeL, every "AI-powered" pitch should be tested against whether it actually connects something or just adds a new silo.

The use case I'd pick first for a UK SME or mid-tier contractor right now is AI takeoff and estimating. The category has matured fast. Togal.AI reports takeoff-time reductions of 50-80% on complex commercial projects at up to 98% accuracy. Cambridge-based Kreo (which has raised £6.5m to date) reports 85-92% accuracy detecting room boundaries, wall runs and opening counts on simple geometry. Wider industry analysis puts AI-driven bid-preparation time savings at 40-60% versus manual methods. These are vendor or third-party figures, not audited claims, but the direction across multiple providers is consistent and the commercial case is straightforward: if your QS team is spending three weeks on takeoff for a bid that won't be won, halving that time changes which bids are worth chasing.

A few things to do well if you trial this. Run a calibration project first on a complete, recent job you already have a manual takeoff for - that gives you a real accuracy number on your drawing standards, not the vendor's. Build the AI takeoff into the workflow, with the QS reviewing rather than re-doing; the time saving collapses if it becomes a second pass. Note the regulatory perimeter, especially the EU AI Act Article 50 transparency obligations effective 2 August 2026, which will affect any AI used on EU-touching procurement. And keep PI insurance and AI disclosure on the procurement checklist - the policy point from last Thursday's brief applies here too.

For your QS team: Pick one recent bid, run it through one of these tools as a controlled trial, compare against the manual takeoff, and decide based on your own accuracy numbers - not vendor marketing.

xAI quietly turned a corner with Grok Build over the last 10 days. The CLI launched in early beta on 14 May at the top of the SuperGrok Heavy tier; on 24-25 May it expanded to all SuperGrok ($30/mo) and X Premium+ ($40/mo) subscribers, with a $99/mo standalone promotional tier for the first six months (regular price will be $300/mo). xAI also shipped a Windows PowerShell installer on 25 May, which matters more than it sounds - most agentic coding tooling assumes macOS or Linux, and a clean Windows path opens it to a lot of construction-software teams who run mixed estates.

The architectural piece is the one to study. Each of Grok Build's subagents - up to 8 in parallel - runs in its own Git worktree: isolated branch, separate working directory, mergeable output. That means one agent can experiment with one approach to a problem while another tries something different, and you keep the best of either without the messy code conflicts that usually break parallel-agent setups. It's a genuine first in mainstream agentic coding, and a pattern other tools will likely copy. The model behind it - grok-build-0.1 - has a 256K context window and accepts text and image input, with MCP compatibility and a plan-first execution loop. The honest benchmark gap: 70.8% on SWE-Bench Verified, against Claude Opus 4.7 at 87.6% and GPT-5.5 at 88.7%. Grok Build is cheaper and architecturally interesting; the frontier still belongs elsewhere on output quality.

So the agentic coding market now has three serious horses: Claude Code (still the quality leader, especially after Opus 4.8's Dynamic Workflows), OpenAI's Codex CLI (Gartner-anointed Leader as of last week), and Grok Build (cheapest, architecturally novel). If your internal-tools work is locked into one of them, this is the right month to run a parallel trial.

Practical bit: Spin Grok Build up alongside whatever you currently use, give both the same small, well-defined task, and compare. The Git-worktree pattern is worth experiencing even if you end up sticking with your current tool.

I'll keep this short because tomorrow's the day. Three things worth carrying in.

First, an evidence framework. The EY × Cambridge report gives you a defensible diagnosis (fragmented systems) and a defensible number (rework absorbing up to 15% of cost). Use those as your filter when vendors pitch. Anything that doesn't actually connect previously disconnected data sources or measurably reduce rework is window dressing, however nice the demo looks.

Second, a workflow target. If you haven't already picked the "one workflow" we discussed in yesterday's brief, AI takeoff is the easiest defensible answer for an SME or mid-tier contractor. Go to ExCeL with that workflow in mind and ask vendors how their tool handles your particular drawing standards. Most won't have a sensible answer; the few that do are the ones worth a structured trial.

Third, an architecture question. Whichever tool you eventually commission, the model layer is moving fast - Opus 4.8 last week, Mythos in weeks, Grok Build expanding, Gemini 3.5 Pro due in June. Build your stack so the model is a swappable input, not a foundational decision. The teams reporting the strongest gains over the next two quarters will be the ones who can change model without rebuilding the workflow.

The discipline: Filter, focus, future-proof. Same three words I keep coming back to, because the people doing this well keep doing the same three things.