AI in estimating: a framework for what to automate

Every estimating software vendor is shipping AI features right now. Most of them are bad.

The pattern I see most often: the vendor bolts a language model onto the existing product, exposes it as a chat interface, and markets it as "AI-powered estimating." You ask it a question. It confidently produces an answer. The answer is sometimes right, sometimes wrong, and either way you have no way to verify it short of doing the work yourself.

That's not estimating. That's a parlor trick with liability attached.

A more useful framework separates AI tasks into three categories: things AI is genuinely good at, things AI is genuinely bad at, and things where the accountability question has to be resolved before you decide.

Things AI is good at

Searching and summarizing documents. Specifications, addenda, RFIs, solicitation amendments — these are long, dense, and structured enough that language models can extract specific information reliably. "What's the dewatering requirement in section 31 23 00?" is a question an AI can answer faster and often more accurately than a human scrolling through a 400-page PDF.

Pattern recognition in structured data. Given a library of past estimates, an AI can notice that the production rate you just entered for placing concrete is 30% lower than the rates your team has historically used. That kind of comparison is boring and error-prone for humans and trivial for software.

Translating between formats. A specification describes work in prose. An estimate quantifies work in bid items. Getting from the former to the latter is a well-defined translation problem, and AI is reasonably good at suggesting candidate bid items from spec text.

Things AI is bad at

Numerical precision. Language models are not calculators. Do not ask one to multiply unit prices by quantities and trust the result. Use real arithmetic for the math.

Judgment calls with real stakes. Should this risk be carried as contingency or as a line item? Is this crew composition realistic for the jobsite access? Is the owner likely to accept this schedule compression strategy? These are judgment questions whose answers depend on context the AI doesn't have and accountability the AI can't accept.

Edge cases in messy data. AI works well on representative cases and fails silently on outliers. Estimating is full of outliers — the one job with an unusual haul distance, the one spec with a non-standard compaction requirement. The cases where you most need a second opinion are the cases where AI is most likely to give you a wrong one.

The accountability question

Here's the test I apply to any AI feature in estimating software: if the output is wrong, who is accountable?

If an AI writes a line item into an estimate without explicit human review, and that line item is wrong, the estimator is accountable for the error — but the estimator didn't write it. That's an untenable position. Either the human is responsible, in which case they must approve each suggestion, or the software is responsible, in which case the software vendor needs to carry real professional liability. Both of those are bad answers for the second case; the first is the only workable one.

This is why the AI sidebar in CSR Foundry suggests but never writes. It can propose bid items, flag inconsistencies, summarize documents, compare proposed rates against your historical data. It can accelerate every task in the estimator's workflow. But the estimator approves every change that lands in the estimate, because the estimator is the one who signs their name to the number.

The test for your own tools

Next time a vendor shows you an AI feature, ask three questions. What is the AI doing that a human couldn't do faster? Where does the human confirm the output? And if the output is wrong, who carries the liability?

If the answers are coherent, the feature is useful. If they aren't, you're looking at a parlor trick.