Who decides what gets built

Founders keep reaching out to show me their product. I have taken a number of those calls.

They have raised millions. The demos are polished. And somewhere in most conversations it becomes clear that the objective is to be acquired by a bigger company. The prize is the exit, not the problem.

That is not a moral complaint — it is how venture works, and Procore proved the category is worth chasing. Other industries got crowded, so capital turned toward construction. But it produces a specific failure, and once you have seen it you cannot stop seeing it: you cannot solve a pain point you have never felt. So the products optimise for what is demonstrable in a demo rather than for what is load-bearing on a project.

Which means the real question is not can this be automated. It is which problem is worth solving, and is it a problem at all. Answering that requires having done the work.

I wanted to know whether the tools were as capable as the pitches claimed, so I stopped evaluating and built one.

What I got wrong, twice

I assumed a model could read a table off an engineering drawing. Whole sheet in, structured rows out. I concluded twice that the packages were unreadable, and moved on.

Both times I was wrong, in the same direction. Whole-table extraction does not fail loudly. It returns something plausible — the right shape, the wrong contents, a few rows quietly missing. Per-cell extraction works, because it shrinks each judgment down to something checkable. The published benchmarks have since caught up with what I found the hard way: professional engineers score around 95% on real construction drawings, the best frontier models around 72%, and on quantity take-off specifically, around 42%.

The second thing I got wrong was assuming it would generalise. It does not. Piping takes off well. Civil and structural do not — and the reason is unglamorous. The popular models are text models. Where a quantity is written down, they read it. Where a quantity is drawn — a symbol, a boundary, a dimension you only get by snapping to points and measuring — they are guessing, and it burns an enormous number of tokens to guess badly.

That distinction is invisible from outside the industry and obvious from inside it. It is also exactly the kind of thing that decides whether a product is useful or merely demonstrable.

What surprised me

That I could build it at all.

One person, working alone, directing coding agents, shipped a platform that would have needed a funded team a few years ago. I did not expect that, and it is the finding with the largest consequences.

Because if a practitioner can build the tool, the calculation changes for everyone. Software companies are, I think, on the wrong side of this. A great many firms will simply build their own — not a general platform, the specific thing their projects need. Better reporting, better dashboards, a faster communication loop. Smaller teams delivering the same work. Better margins, shorter schedules, and — because most friction on a project is informational — better relationships.

The founders are racing toward an acquisition. Their customers are quietly acquiring the ability to build.

What is already arriving

I am seeing it in the change channel. Estimates attached to RFIs come in with more detail and more internal consistency than they used to.

They are not more right. They are more organised, and those are different properties that look identical on a page. An estimate turns on productivity — hours per unit, in these conditions, with this crew, on this site. Nothing about a well-formatted document tells you whether that assumption holds. A polished estimate built on a wrong productivity number is worse than a rough one, because it survives scrutiny for longer.

This is where the industry’s staffing habits collide with the technology. Many project teams have no full-time scheduler or estimator on site. The response has been to centralise those roles — and a centralised estimator with no feel for site conditions was already a problem before anyone added a language model to it. Now the output arrives faster and looks better, and the same missing context sits underneath better formatting.

So the review does not go away. It moves, and it becomes harder to do casually.

What does not yield

The judgment about whether a number makes sense.

Not because judgment is sacred, but because of where the economics land. Where machine output is cheap to check — arithmetic, content hashes, cross-references — automate all of it, to full coverage rather than the samples we used to take. Where checking the output means redoing the work, the human stays in the loop because nothing has actually been saved.

And someone still signs. An estimate at completion goes into a stage gate, a board pack, a regulatory filing. The machine can produce the number. It cannot be accountable for it — and in this discipline a number that cannot cite its method loses the argument, however it was produced.

What the next generation should learn

Three years ago I would have told a junior to go deep: own the schedule, or own cost, or own reporting, and become excellent at it.

I would not say that now.

Report generation and data collection are going to be automated, and they should be — that work was never where the value was. What matters is being able to make a decision quickly from the data once it arrives. That is a different skill, and a harder one to teach, because it used to be acquired as a by-product of producing the reports by hand.

So: learn to vibecode (learn to build). Everyone in this discipline should be able to automate their own reporting. And go multidisciplinary. The person who only does schedule, or only does cost, is describing a job that is being compressed. The person who can read a drawing, price the work, defend the position, and build the tool that checks it is describing one that is expanding.

Why I am optimistic

This industry has been traditional in how it works for a very long time. That is finally going to change, and change is good.

The uncomfortable part is that the direction is not settled. It will be decided by whoever gets to choose which problems are worth solving. A great deal of that choosing is currently being done with venture money, by people who have never priced a change order or stood on a site working out why the pour is late.

It does not have to stay that way. The tools are now cheap enough that the people who understand the work can build for themselves — which means, for the first time, the industry can answer its own questions instead of being sold answers to questions it never asked.

It is going to be an interesting decade. Everyone in this industry should be excited about it.