Construction AI: the construction court writes its first rules for AI, and Grok arrives married to Cursor

The Technology and Construction Court is where the sector's biggest fights end up: adjudication enforcement, professional negligence claims against engineers and surveyors, delay and disruption disputes worth eight figures. On 1 July it published the fourth edition of its Guide, the first update since October 2022. Most of the coverage went to the practical rewrites, the new guidance on Building Safety Act 2022 proceedings and a procurement section reworked for the Procurement Act 2023. But the quieter addition is the one worth your attention. For the first time, the Guide addresses the use of AI. On 9 July, the barrister Gordon Exall published a detailed examination of that section on his Civil Litigation Brief, and his summary is that it's short but significant, because it shows the courts now simply expect AI to be used.

Here's the principle that matters. The Guide stresses that legal representatives remain personally responsible for the material they put before the court, whatever tool produced it. That sits alongside the Civil Justice Council's wider work, which consulted until 14 April on whether procedural rules are needed for AI in court documents, and published its findings update on 1 July. Put the two together and the direction is clear: no hiding behind the model. If a witness statement, a pleading or an expert report has been drafted with AI and it turns out to contain a hallucinated authority or a figure that never existed, the person who signed it wears it. There have already been enough embarrassments in other courts, fake citations and invented case law, for the judiciary to have lost patience.

Now the bit that's easy to miss if you're not a lawyer. This isn't only a problem for your solicitors. Think about who actually feeds a construction dispute. The delay analyst rebuilding a programme. The quantity surveyor pricing a variation account. The building control consultant writing a compliance narrative for a Building Safety Act matter. More and more of that work leans on AI to move faster, and the moment any of it becomes evidence in the TCC, it inherits this standard. So the comparison only goes so far, but it's a bit like signing off a structural calculation someone else ran: your name on it means you checked it, not that you trust the machine that produced it. That's what it's about.

The practical bit: put an explicit verification step into any workflow that could end up as evidence, a named person who checks AI-assisted figures and citations before anything is signed. Do it now, while it's a discipline, not after a judge makes it an expensive lesson.

xAI announced Grok 4.5 on 8 July 2026, and pitched it squarely at coding, agents and knowledge work. The headline detail isn't the benchmark score. It's that this is the first model co-trained with Cursor, the AI code editor a lot of developers now live in. Grok 4.5 went live the same day in Cursor on every plan and in the xAI console, though not in the EU, where availability was flagged for mid-July. On the numbers, xAI and Elon Musk described it as roughly comparable to Opus-class performance but faster, around twice as token-efficient, running at fast-model speeds, at roughly two dollars per million input tokens. Every one of those figures is the vendor's own, so treat them as a starting claim, not a settled fact. I'm not sure the "comparable to Opus" line survives independent testing intact, but the direction, cheaper and faster at the same rough quality, is real and it's relentless.

Why does a coding model matter to a construction audience? Not because you'll run Grok from the site cabin. It matters because of the shape of the deal. A frontier lab and a tool vendor tuned a model to the tool's own data, and shipped it inside the product on day one. That is exactly how the construction software you already pay for is going to work. Your estimating tool, your document platform, your compliance assistant, they all sit on top of a frontier model, and that model can be swapped underneath you between releases. GPT-5.6 shipped last week. Grok 4.5 this week. The churn is now weekly, and most of it happens without you being told.

So the useful move isn't to chase the model of the month. What we've found is that the durable questions are the dull ones. Which model is under the hood of the tool I'm buying? Where does my project data travel when I use it? And when the vendor swaps the engine, does my data handling change with it? The EU availability lag on Grok 4.5 is a small reminder that where a model can legally run still matters, and for anyone holding client data under a UK or EU obligation, that's not a footnote. The tool changes weekly. Your duty of care doesn't.

The procurement filter: ask any AI vendor to name the underlying model, its data residency, and their notice period for changing it. If they can't answer all three in writing, you haven't finished due diligence.

For weeks this brief has tracked the data centre pipeline as the thing that's meant to keep UK contractors busy, and the caveats have been about power and planning. Here's a different kind of caveat, and it comes with a figure. Buildots' Intelligence Lab, the aggregated research hub it launched on 25 June drawing on anonymised data from projects worldwide, found a gap of 20 to 50% between the mechanical, electrical and plumbing output planned for a given week and what was actually delivered on data centre builds. That's the firm's own aggregated data, so read it as evidence from a vendor with a product to sell, not as an independent audit. But the size of it is hard to wave away, and it lines up with what anyone who's run an M&E-heavy programme already suspects.

Think about where that bites. A data centre is, structurally, a shed wrapped around an enormous amount of building services. The value and the risk both live in the MEP. If a fifth to a half of the planned services work isn't landing week on week, the programme isn't slipping at the margins, it's slipping at the core, and it's doing it quietly because the superstructure looks fine from the road. That's the trap on these jobs: the bit that photographs well is on time, and the bit that decides your completion date is drifting. Buildots also pushed its AI progress tracking into the superstructure phase on 1 July, so it's now watching frame as well as fitout, which is the point, you can't manage a gap you can't see.

So the standing discipline for anyone resourcing against this pipeline is the same one as ever, just with sharper numbers behind it. Measure planned against delivered, at trade level, every week. Not overall percent-complete, which flatters everyone, but the specific question of whether this week's M&E actually happened. The people who feel a 30% delivery gap first are the site manager staring at a services programme that won't close and the commercial lead watching the completion date move. Catch it in the weekly data and it's a conversation. Catch it at handover and it's a claim, and it might just end up in the court we opened this brief with.

The takeaway: track weekly MEP delivered-versus-planned as a named metric on every services-heavy job, and treat any sustained gap above 10% as a programme risk, not a reporting quirk.