Ask a general-purpose chatbot to summarize a meeting and it does fine. Ask it to size a bolted joint and you’re gambling. Independent evaluations put the error rate of general chatbots on mechanical engineering questions near 46%.

Imagine a junior engineer who is wrong almost half the time, sounds completely confident and never says “I’m not sure.” Nobody would let that person near a drawing release. Engineering teams let the chatbot in anyway, because it answers in seconds and the schedule is brutal.

I understand the temptation. I’m a mechanical engineer by training, and I spent years in defense watching colleagues burn hours digging for a standard or reverse-engineering a decision someone made in 2011. When a tool promises instant answers, people use it.

The problem is not that engineers are careless. The problem is that the tool was never built for this work, and it fails in ways that are hard to see until something expensive breaks. The failures are structural, not cosmetic, and no amount of clever prompting fixes them.

Why General Models Fail at Engineering

First, general models don’t read geometry; they read text and pixels. The meaning of a CAD model lives in its boundary representation: topology, mating constraints, tolerances and feature history. A screenshot of a flange is not a flange. When an AI model can’t parse the actual geometry, everything it says about wall thickness, clearance or interference is inference from words, and words are a lossy format for parts.

Second, they learned from the wrong library. General models train on the open internet, which means forum threads and marketing copy sit alongside the occasional textbook excerpt, all averaged together. Engineering knowledge doesn’t live there. It lives in Shigley and Roark, in ASME, ISO, DIN and MIL-STD documents, in materials databases and internal design guides. A model that never trained on vetted sources will happily blend a hobbyist’s rule of thumb with an aerospace requirement and present the result in perfect prose.

READ MORE: Leo AI: How CAD-Aware AI is Changing Mechanical Design and Engineering Workflows

Third, and this is the disqualifying one: The numbers have no provenance. When a chatbot tells you a safety factor is adequate, you cannot see which formula it used, which edition of which standard it pulled from or whether it invented the allowable stress outright. Engineering runs on shown work. A number you can’t trace is not an answer; it’s a liability with good grammar.

Fluency is what makes this dangerous. A wrong answer that looks wrong gets caught. A wrong answer in clean, confident, well-structured prose sails through review when the team is tired and the deadline is close. And late errors are the expensive kind. Every design lead knows the rule of thumb: A mistake caught after release costs 10 to a hundred times more than one caught at the sketch.

What Engineering-Grade Actually Means

None of this argues against AI in engineering. It argues for holding AI to the same standard we hold engineers. In practice, engineering-grade means five things.

Geometry-native models. The AI must consume actual CAD data, boundary representation and assembly structure included, not screenshots or verbal descriptions of parts. If it can’t tell you what it knows about the model tree, it doesn’t know the part.

A curated corpus. Training and retrieval should draw on vetted engineering sources, the textbooks, standards and handbooks real products are built from, plus the company’s own validated designs. What the model learned from matters as much as how big it is.

Citations on every answer. Every claim should point back to a source a skeptical engineer can pull off the shelf and check. Not a vague ”according to industry standards”—the actual document.

Calculation transparency. Every number should arrive with the math behind it: the formula, the assumptions and ideally the runnable code. If the tool can’t show its work, it hasn’t done work. It has produced a guess in the typography of an answer.

The discipline to say, “I don’t know.” This is the hardest one to build and the fastest to test. An engineering-grade system must refuse to answer when the data isn’t there, exactly like the senior engineer whose “let me check” you learned to trust.

Underneath all five sits the boring plumbing that decides whether the tool ever clears a real procurement review: your data stays yours, nothing trains on it and the system can run inside your walls when the work demands it.

A Checklist Before You Let AI Near Production Work

Evaluating a tool doesn’t require a benchmark suite. It requires an hour of adversarial curiosity.

1. Ask it a question you already know the answer to, in your own domain, and include a trap. A subtly wrong premise, a units mismatch, a nonexistent standard. See if it notices.
2. Ask where a number came from. Then, actually check the source. If the citation is vague or invented, you’re done.
3. Give it real geometry and ask a question whose answer lives in the model tree, not in the description. If it can only reason about parts through words, it will fail exactly where your work gets hard.
4. Ask something unanswerable from the information given. The only right response is a request for more data or an honest "I don’t know." A guess, however fluent, is disqualifying.
5. Bring your security team in early and ask the unglamorous questions. Where does the data go? What trains on it? Can it run on premises? Tools fail procurement more often than they fail demos.

Engineers are not anti-AI. They are anti-nonsense, and they’re been right to be. The general chatbots earned their skepticism by being confidently wrong about the physical world nearly half the time. But the standard for fixing that isn’t mysterious. We’ve applied it to every young engineer for a century: show your work, cite your sources, know your limits.

Hold the software to the same bar, and AI stops being a party trick and becomes what it should have been all along, a competent colleague who never gets tired of the tedious parts. The judgment stays where it’s always belonged: with the engineer.