Technical · August 2026
What AI should — and shouldn't — do in engineering software
Why every number in a Valtrin system comes from deterministic code — and what we happily let AI touch.
Every software pitch this year includes AI somewhere. The interesting question is not whether to use it — it is where the boundary sits. In engineering software, drawing that boundary in the wrong place doesn't produce funny chatbot screenshots. It produces wrong numbers on signed documents.
Large language models are genuinely good at what they are built for: language. Reading an enquiry email and pulling out the quantities, dates and site address. Classifying a scanned delivery order. Extracting line items from a messy supplier PDF. Drafting the reply. That entire class of work — unstructured, and until recently automatable by nobody — is now automatable. This is a real shift, and we use it daily.
The same models are probabilistic by construction. Ask twice and you can get two different answers. Their arithmetic is right most of the time. In conversation, "most of the time" is fine. On a quotation, it is a defect.
The failure mode that matters
A number that is nearly always right is more dangerous than one that is always wrong, because the always-wrong number gets caught in week one. Pricing that is 99% correct means one silently wrong quotation in a hundred — signed, sent, and discovered at the worst possible moment: after you have won the job at the wrong price. No engineer accepts a beam calculation that is usually right. The bar for a costing engine is the same bar.
The division of labour
Unstructured work · human review when confidence is low
Deterministic · same input, same output, every time
AI reads and writes. Code calculates.
In practice the two halves meet at a checkpoint. Extraction comes with a confidence score; anything below the threshold routes to a human review queue instead of flowing onward. The reviewed fields then enter deterministic code — your rates, your rules, unit-tested and version-controlled — so the same inputs produce the same totals on any day, and every figure can be traced back through a formula to its inputs.
This is not a theoretical stance. Our estimating engine works exactly this way, and is validated against known results — past jobs whose numbers were already trusted — before it prices anything new. If the engine cannot reproduce what you already know to be right, it does not go live.
What we refuse to build
AI-generated pricing. AI "reading" a drawing and estimating tonnage. Any total whose derivation cannot be replayed. If a number cannot be traced from the document back through a formula to its inputs, it does not ship — however impressive the demo looked.
The refusal cuts both ways, though. Banning AI outright is as lazy as sprinkling it everywhere. Extraction and classification alone can remove most of the retyping in a quotation workflow, and that work was untouchable five years ago. The craft is the boundary: judgement where judgement helps, determinism where accuracy matters.
So when someone proposes AI for your workflow, ask one question: which numbers will it produce? The right answer is none.
