AI in construction: what actually works on a live job

Most of what gets written about AI in construction is written by people who have never priced a job. The result is a genre of article that lists eleven "use cases", each a sentence long, none of which survive contact with a live project. This is the other kind: what has actually turned out to be useful, what has turned out to be a trap, and the one structural rule that separates them.

The adoption numbers, and what they actually say

Adoption stopped being theoretical some time in the last eighteen months. ServiceTitan's 2026 Commercial Specialty Contractor Industry Report, which surveyed over a thousand industry leaders, found 38% of contractors now seeing measurable results from AI — up from 17% the year before. Houzz's 2026 State of AI report put the share of construction firms using AI tools for business tasks at 52%, a twenty-point jump in a year.

The interesting number is not the headline. It is the breakdown. The top two uses were cost estimating (24%) and bid management (22%). Not site safety, not scheduling, not the robot dogs. Pre-construction — reading documents and turning them into a price.

That is not an accident of what vendors happen to sell. It is where the conditions for automation are actually met: the inputs are documents, the work is repetitive, the cycle is short enough to learn from, and the cost of doing it slowly is a bid you did not submit.

The three things that work

1. Reading documents you were going to read anyway

A drawing set, a specification, a subcontractor's quote with four pages of exclusions buried in it. This is the clearest win because the baseline is so poor: everybody skims, and the thing that bites you is always in the part that got skimmed.

What good looks like here is narrow. The model should extract and cite, not summarise and assert. A quantity that arrives with the sheet number and the detail it was measured off is checkable in ten seconds. The same quantity arriving as a number in a list is a liability you have to re-measure to trust, which is the whole job again.

This is also the honest answer to the takeoff question. AI takeoff off a PDF is real and it is useful. It is a first pass, not a submission. Treated as a first pass it removes several hours of measuring; treated as an answer it eventually removes your margin.

2. Drafting work a human then signs

Scopes of work, subcontractor packages, the RFI you have been avoiding writing, the follow-up to the sub who has not come back. The value is not that the model writes better than you. It is that it writes at all, at 4pm on a Thursday, when the alternative is that the email does not get sent this week.

Two conditions make this safe. The draft has to be visibly a draft — sitting in front of you, editable, not already gone. And it has to be built from your own data rather than invented: a purchase order that pulls the actual line items from the actual estimate is useful, while one that hallucinates a plausible scope is a trap with your letterhead on it.

3. Noticing things in your own numbers

This is the quietest one and probably the biggest. Every builder is already sitting on the information that would have told them the job was going wrong — the committed cost that crept past the budget line in week six, the variation that was done and never priced, the retention that was never released. Nobody looks, because looking means opening four systems and doing arithmetic.

A machine that watches those numbers continuously and says one sentence when something moves is worth more than any amount of generated text. The output is not a document. It is "section 08 is 2,800 dollars over and it happened this week".

The three places it should never go

Contractual dates

A language model asked to reschedule a programme will give you dates. They will look right. They will not be defensible, because the model is pattern-matching, not running critical path — and the moment practical completion moves, you are in a conversation about liquidated damages where "the AI suggested it" is not a position.

The pattern that does work: the model proposes the change in plain words, and a real CPM engine validates it, cascades the consequences and refuses anything that breaks a constraint. The model is the interface. The engine is the authority. If a tool cannot tell you which of the two moved your dates, that is the answer to whether you should use it.

A price that goes out the door

Same principle, higher stakes. A generated estimate is a draft until a human has looked at every line that carries money. The dangerous version is not the one that is obviously wrong — you catch those. It is the one that is 4% light on a section you did not open because the rest of it looked fine.

The structural fix is that nothing should be able to change a priced line without showing you the blast radius first: every line a rate change would touch, what it does to the contract sum, and which sections are already locked under a fixed price. Preview, then commit. Never the other way round.

Anything that moves money

Approving a bill, releasing a payment, issuing a credit note. There is no version of this where unattended automation is worth the downside. Policy can prepare the decision — match the invoice to the order, flag that it is over, draft the payment run — and a person makes it.

The rule underneath all of it

Every one of those six judgements is the same judgement:

The model may propose. It must never dispose.

Where a deterministic engine or a person sits between the model's output and the consequence, AI is safe and usually valuable. Where it does not, you have automated the production of confident mistakes.

This is worth being blunt about because the industry is about to learn it the expensive way. The failure mode of a bad spreadsheet is that the numbers are wrong and look wrong. The failure mode of a bad model is that the numbers are wrong and look right, which is a different class of problem and one that construction — with its fixed prices, long tails and thin margins — is unusually exposed to.

Why this matters more in Australia than the marketing suggests

The context here is not a productivity story, it is a survival one. ASIC's insolvency data has construction as far and away the worst-hit sector — around 27% of all company failures nationally, with 3,435 construction companies entering external administration in 2025-26. That figure fell 4.5% on the year before, the first drop in five years, which counts as good news and still means roughly ten builders a day.

Almost none of those businesses failed because they could not build. They failed on the parts either side of building: a price that was wrong before the job started, a variation never captured, cash that went out faster than it came in. Small firms — under twenty full-time staff — are disproportionately represented, which is exactly the cohort with no commercial manager and no time to do the checking.

That is the honest case for AI in construction, and it is a narrower case than the vendors make. Not "transform your business". Just: do the reading, draft the boring documents, and tell me when a number moves — so that the person who should be checking actually can.

What to do about it this quarter

If you want to get something out of this rather than file it:

1. Start where the documents are. Estimating and quote levelling, not site. It is where the hours are and where a mistake is expensive enough to justify the change.
2. Demand traceability, not accuracy claims. Ask a vendor to click a number and show you the drawing. If they cannot, the accuracy percentage is unfalsifiable and you should treat it as marketing.
3. Find out what can write without you. For any tool you are considering: which actions does it take unattended? Get the list. If dates, prices or payments are on it, that is not a feature.
4. Keep the estimate. Whatever you adopt, the estimate that won the job has to stay the basis of the budget, the claims and the closeout. Most of the value in this whole category is just refusing to re-key the same job into four systems.

Base is built on exactly the rule above — the model proposes, the engine disposes, and nothing that carries money writes itself. If you want the detail on the estimating half, that is the next article.