AI can read the drawings. It cannot decide what they mean.
The demo that should worry you
You have probably seen the demo by now. Upload the plan set, wait a few minutes, and a priced bid comes out the other end. No takeoff, no estimator, no argument about what the specification meant. The pitch underneath it is always the same sentence: estimating is a bottleneck, so let the machine do the estimating.
It is a good demo. It is also aimed at the wrong target, and the reason is not that the technology is bad. The technology is genuinely impressive. The problem is that it has been pointed at the part of the job that was never the expensive part.
What an estimate is actually for
Ask most people what an estimator produces and they will say a number. Price the work, submit the bid, hope you win.
The estimators who are good at it describe the job completely differently. The number is the smallest part of what leaves their desk. What leaves estimating is a project someone else must run: a scope divided into buildable pieces, materials specified precisely enough to purchase, and a record of assumptions made where the drawings were silent. The estimator’s first customer is the project manager, and after that, engineering and the shop.
A bid is not a quote for woodwork. It is a decision to commit weeks of your plant’s future to one job instead of another. That is a capacity decision and a risk decision, and it is the reason a good estimator is worth what they cost.
Automate toward a number and you optimize the one output that was never the hard part. The bid goes out faster and the project still arrives at the project manager as a mystery.
What genuinely should be automated
None of which means estimators should be protected from software. A serious slice of the estimating day is not judgment at all, and every minute of it is waste.
Reading a five hundred page set to find the forty pages that touch your scope. Typing sheet names and numbers that are already printed on the sheets. Drawing the same location rectangle sixty times for a hotel floor. Re-keying a material somebody in your building already typed once. Discovering on page three hundred that a detail contradicts something you priced on page twelve, three days after you priced it.
That is exactly the work machine vision and language models are good at. Software can now look at a sheet set and tell you which sheets contain millwork. It can read a region of a drawing and propose the locations, named and numbered, instead of you drawing each one. It can look at an elevation and suggest the products that belong there. It can pull the sheet names and numbers off the pages as they upload, surface the redlines a reviewer marked up, and let you ask a plain-language question against your own drawings and specification documents rather than scrolling for twenty minutes.
Notice what all of those have in common. Each one produces a suggestion sitting in front of a person who can accept it, correct it, or throw it out. The machine finds and proposes. The estimator decides. That is not a limitation we are apologizing for, it is the design.
The part that should not be
Some of the most consequential calls in a takeoff look like preferences and are not.
Take something as small as whether to take casework off by each or by area. Area is faster and for a budget number it is usually right. But if engineering works downstream from your takeoff, the extra clicks buy back far more time than they cost, because the data arriving downstream is specific enough to use. There is no correct answer in the abstract. The answer depends on who in your building has to use the output, and no model knows that about your shop.
Or locations. Most shops draw one location per room because rooms are what the architect drew. The shops that get more out of it draw a location the size of a work order, so an entryway with a reception desk, a ceiling feature and a run of casework becomes three locations rather than one. That decision saves the estimator nothing and saves the project manager a week. It requires knowing how work moves through your particular plant.
Then there is the one nobody automates because it is not data. An estimate carries two kinds of information: what you priced, and what you decided in order to price it. No specifications provided. The casework note on one sheet disagrees with the specification. This is a long lead item. I assumed the cheaper option and qualified it. Six months later, when the job is awarded and you have to get your head back into it, that record is worth more than the pricing. A system can hold it for you. It cannot generate it, because those are judgments you made and nobody else witnessed.
Three questions worth asking any vendor
If you are evaluating an AI estimating tool this year, the useful questions are not about accuracy percentages.
Can you see what it decided, and change it? A suggestion you can accept, edit or reject is assistance. A finished number with no trail behind it is a liability you have signed.
Does the estimate stay connected to the job afterward? Actual costs have to come back against what you estimated, or you never find out whether any of it was right. A faster bid that nothing checks is just a wrong number arriving sooner.
What happens when it is wrong? Not if. Drawings are ambiguous, specifications contradict themselves, and a model that has never seen your shop will confidently propose the wrong thing at some point. The question is whether that shows up in front of a person before it shows up in a contract.
Where this leaves the estimator
Better off, and busier with the right work.
Strip out the page hunting, the re-keying, the sixty rectangles, and what remains is reading the drawings properly, pricing risk honestly, and setting up a project the next four people can actually run. That is the job worth paying for. It always was. The tools are finally good enough to let estimators spend the day on it.