Can AI Really Design Engineering Drawings? What I Believe the Future Looks Like for Engineers

I was skeptical about AI on our projects for a long time, genuinely skeptical, not the performative kind of skeptical people write in LinkedIn posts before pivoting to "but actually it's amazing." Then we had a coordination review where a junior engineer used an LLM tool to draft a structural note summary, and the tool quietly hallucinated a load rating that didn't exist anywhere in our actual calculations. It read completely plausible. It was wrong.

Nobody caught it in the first pass because it read like something an experienced engineer would write, confident, specific, the right kind of jargon in the right places. The junior engineer had asked the tool to "summarize the structural notes for the client deck," and it did exactly that, fluently, and quietly filled in one gap in the source document with a number that sounded right. It got flagged two reviews later by a senior structural engineer who happened to have the actual figure memorized from a nearly identical project he'd worked on years earlier. He just paused mid-meeting and said, "wait, that's not the number," and the room went a little quiet.

If he hadn't been in that particular meeting, that note could have gone into a client-facing document with a fabricated figure sitting inside it, looking completely legitimate, sitting there until someone downstream built on top of it.

That was the moment I stopped thinking of AI tools as something you point at a task and trust the output of. Not because the tool is useless, it genuinely isn't, but because the failure mode is specifically dangerous in engineering. A hallucinated email tone is embarrassing. A hallucinated load rating on an infrastructure project is a different category of problem entirely, the kind that doesn't announce itself.

What Actually Changed on Our Team

We didn't ban the tools. That would have been the easy, wrong answer, and honestly nobody would have followed it anyway since half the team was already using them quietly for drafting and research, myself included.

Instead we built one hard rule into our review process. Anything AI-assisted, drafting, summarizing, generating boilerplate text, gets a specific tag in our document control system, and anything tagged that way requires sign-off from someone who did not use AI to produce it. It sounds like a small procedural tweak, and honestly it kind of is. In practice it changed how people actually used the tools, because now there's a specific human accountable for catching exactly the kind of error that slipped through that first review. Our BIM manager pushed for it in a meeting where two people rolled their eyes, and I understood the eye-rolling, it does add friction to something that used to be instant. It's friction I've come around to.

I use these tools constantly now, for drafting meeting summaries, for restructuring messy site notes into something readable, for generating first-pass Python scripts I then actually test against real data before trusting them anywhere near a live model. What changed isn't whether I use AI. It's that I stopped treating fluent output as correct output. Those are two completely different things, and the tool is very good at the first one and only sometimes good at the second, which is exactly what makes it dangerous in a technical field where fluency and correctness usually travel together.

Where AI Actually Earns Its Place

The tasks where it's genuinely changed my workflow are boring ones, on purpose. Summarizing a forty-page geotechnical report down to the three paragraphs I actually need before a meeting. Restructuring field notes a site engineer scrawled at 6am into something the rest of the team can read without decoding handwriting. Drafting a first pass of a client email that I then rewrite half of anyway, but starting from something instead of a blank page saves real time on a Tuesday when I already have four other things burning.

None of that touches load calculations, structural logic, or anything where being fluently wrong carries real consequences. That line matters to me now in a way it didn't a year ago, back when I mostly thought about AI in terms of what it could save me time on, rather than what it could quietly get wrong while sounding completely sure of itself. I've started asking a specific question before I trust any AI output on something technical: could this be confidently, plausibly, and completely wrong, and would I actually catch it if it were. If the honest answer is no, it doesn't go anywhere near a live document without someone else's eyes on it first.

The engineers I know who've adapted well to this aren't the ones using AI for everything, and they're not the ones avoiding it either, holding out on principle while everyone else moves faster. They're the ones who got specific and a little paranoid about exactly where the line sits, and who built a process, even a small annoying one like our tagging system, that catches the failure mode instead of just hoping it doesn't happen to them. I'd rather have an extra sign-off step that slows down a Tuesday than another close call like the one that started all this, sitting two reviews deep in a document nobody had double-checked yet.

This connects to something I've run into on the modeling side too, the same pattern where a document or model can look completely correct and still be wrong in a way that only shows up once someone tries to build something from it, which I wrote about in The Duplicate Family That Cost Us Two Weeks on a Tunnel Ventilation Shaft. Different tool, same lesson, clean output is not the same thing as correct output, and the gap between the two is exactly where it gets expensive.

Related reading:

The Duplicate Family That Cost Us Two Weeks on a Tunnel Ventilation Shaft

Beyond the Manual Trap: Why I Started Using Python to Automate My Engineering Workflow