AI in Engineering Practice: What It Can and Cannot Do
Deliberate Academy Editorial Team
Reviewed for accuracy and professional relevance
- Map the categories of non-software engineering work where AI is demonstrably useful against those where it is unreliable or professionally inappropriate
- Explain why the engineer of record cannot delegate calculation verification, stamped sign-off, or safety-critical judgment to an AI tool regardless of output quality
- Apply a two-axis risk framework -- consequence of AI error and degree of engineering judgment required -- to categorize engineering tasks by AI suitability
- Identify the numeric hallucination failure mode and explain why it is the most dangerous default assumption a new AI user makes in engineering work
A structural engineer used to spend three hours a week writing the narrative sections of her design calculation packages by hand: load derivation summaries, code-basis paragraphs, assumptions statements. She now drafts those same sections with Claude in about twenty minutes, then spends the time she saved on an independent second check of the governing load combinations -- the step that gets skipped first under deadline pressure. That shift, not faster calculations, is where AI is actually changing engineering practice.
The failure mode that catches new users almost immediately: asking an AI model to check a beam deflection or a pipe wall thickness calculation and trusting the number it returns. Large language models predict statistically plausible text. They do not reliably execute engineering arithmetic, and a confidently stated wrong answer looks identical to a correct one until someone checks it by hand, in verified calculation software, or against a code table. Every category of usefulness described in this course sits downstream of that one distinction: AI is a strong drafting and research tool and an unreliable calculator.
The Engineering Function Mapped Against AI Applicability
Documentation and specification drafting. Design basis reports, technical specification sections, meeting minutes, requests for information, and submittal review letters are heavily text-based and follow recognizable structures. AI can produce a strong first draft in minutes from a structured prompt. This is covered in depth in Lesson 2.
Design iteration and generative design support. Tools like Autodesk Fusion 360's generative design environment and nTopology can explore many geometric variants against stated constraints -- load cases, materials, manufacturing method -- far faster than manual iteration. The engineer still owns every failure mode the tool was not told to check. This is covered in Lesson 3.
Compliance and code research. AI tools, including general-purpose assistants and specialized platforms such as UpCodes, can orient an engineer quickly to which code sections and standards likely apply to a given condition. They are a starting point for research, never a substitute for reading the current, applicable code text. This is covered in Lesson 4.
Simulation and analysis interpretation. Finite element and computational fluid dynamics platforms increasingly ship AI-assisted summarization of results. These tools can help an engineer scan a large result set for anomalies faster, but they do not replace the engineer's judgment about mesh convergence, boundary condition validity, or whether the model represents reality. This is covered in Lesson 5.
Project reporting and troubleshooting support. Progress reports, client memos, and failure investigation write-ups are all areas where AI creates genuine drafting leverage without requiring new infrastructure. These are covered in Lessons 6 and 7.
A practical risk framework for categorizing engineering tasks by AI suitability has two axes: the consequence of an AI error (low to high) and the degree of engineering judgment required (routine to complex). Drafting the narrative section of a report that a licensed engineer will fully review sits in the green zone. Performing or verifying a load calculation, interpreting an ambiguous simulation result, or drawing a root-cause conclusion from limited evidence sits in the red zone. Most AI use in engineering practice should start in the green zone and extend into amber only with a defined, documented verification step.
A Drafting Tool Mistaken for a Checking Tool
Context
A project engineer at a 40-person structural consultancy was under deadline pressure on a warehouse expansion project. To save time, he asked ChatGPT to verify the factored load combination he had derived for a roof truss, pasting in his dead, live, and snow load values and asking the tool to confirm the governing ASCE 7 combination and resulting factored load. The tool returned a confident, well-formatted answer with a specific number.
Action
The engineer's firm had a policy, introduced after a near-miss the previous year, requiring every AI-assisted numeric output to be independently reproduced in the firm's calculation software or by hand before it could appear in a sealed package. He ran the same combination through the firm's spreadsheet template as required. The factored load did not match the AI's figure -- the AI had applied an outdated load factor from an earlier code edition it had been trained on more heavily.
Outcome
The discrepancy was caught before the calculation package went to the engineer of record for stamping. The firm's post-incident review concluded that the AI tool had been used correctly as a first-pass drafting aid for the narrative sections of the package, but the near-miss on the load combination reinforced why the independent verification policy existed specifically for numeric content. The firm's AI use policy was updated to state explicitly: AI tools draft language, they do not perform or verify calculations.
A mechanical engineer asks an AI tool to calculate the required wall thickness for a pressure vessel given a stated design pressure, diameter, and material allowable stress. The tool returns a specific thickness value with a citation to an ASME code formula. What is the most professionally appropriate next step?
Select one answer.
Why Engineering AI Literacy Is Categorically Different
Most professional AI literacy focuses on efficiency and general risk management. For engineers in the physical disciplines, AI literacy also intersects with a professional structure that is non-delegable: the engineer of record's stamp or seal, the standard of care that licensure boards and courts use to judge professional conduct, and the safety consequences of an error that reaches a built structure, a manufactured part, or an operating system.
An engineer who stamps a drawing containing an AI-drafted calculation that turns out to be wrong has not delegated that error to the AI tool. The stamp attaches personal professional responsibility regardless of which tool, person, or software produced the underlying content. This is the framing that underpins every lesson in this course: AI outputs are drafts, research orientations, and drafting accelerants. They are under your professional supervision. You are responsible for what leaves your office bearing your stamp, seal, or signature. Lesson 9 covers this framework in full detail.
Do not adopt an AI tool for engineering work based solely on a vendor demonstration using prepared, favorable examples. Before relying on any tool -- general-purpose or engineering-specific -- test it against your actual work: your discipline, your typical project types, your governing codes and standards. Specifically probe its numeric outputs and its code citations against known-correct answers you already have. How it fails on problems you can independently verify tells you far more than how it performs on a vendor's chosen examples.
An electrical engineer uses an AI tool to draft a short technical memo explaining a proposed panel schedule change to a client, and separately uses the same tool to estimate a conductor ampacity for a new circuit run. Which of these two uses fits the green zone of the risk framework from this lesson, and why?
Select one answer.
Exercise
Your Task
List five tasks from your own engineering work over the past two weeks -- drafting, research, calculation, review, communication. For each one, score it on two axes from this lesson: consequence of an AI error (low, medium, high) and degree of engineering judgment required (routine, moderate, complex). Identify which tasks fall in the green zone (safe to draft with AI, full review before use), which fall in amber (usable with a defined, documented verification step), and which fall in red (AI should not produce or verify the core content, full stop). Write one sentence for each red-zone task explaining what makes independent, non-AI verification non-negotiable.
Your reflection
Did you complete this exercise? What did you find? (Saved locally in your browser)
- AI is demonstrably useful in non-software engineering work for documentation drafting, design exploration, code research orientation, simulation result summarization, and report writing -- but unreliable for performing or verifying calculations, and inappropriate for any output that will carry a stamp, seal, or certification without independent professional verification.
- The engineer of record cannot delegate calculation accuracy, stamped sign-off, or safety-critical judgment to an AI tool -- professional and legal responsibility for what leaves your office attaches to you personally, regardless of which tool produced the draft.
- Use a two-axis risk framework -- consequence of AI error and degree of engineering judgment required -- to categorize tasks: low-consequence drafting is a safe starting point; numeric calculations and safety-critical determinations require independent, non-AI verification every time.
- Numeric hallucination is the single most dangerous default assumption a new AI user brings to engineering work: a confidently formatted, correctly cited AI answer is not evidence that the underlying arithmetic or code reference is correct.
- Test any AI tool against problems you can independently verify -- your discipline, your codes, your typical project types -- before relying on it for real work. How a tool fails tells you more than how it succeeds on a vendor demo.