The headlines about AI replacing engineers are wrong. But the idea that LLMs are just toys for generating marketing copy is also wrong. The reality, as usual, is somewhere in the middle — and it’s more interesting than either extreme.
After spending the past year integrating LLMs into my own engineering workflow and talking to dozens of engineers who are doing the same, here’s what’s actually working.
Technical Report Drafting: The 80% Solution
An environmental impact assessment chapter, a process design basis document, a equipment specification sheet — these documents have a structure that doesn’t change much from project to project. The specific numbers, site conditions, and design decisions are different each time. The framework around them is 80% the same.
The workflow that works: feed the LLM a previous successful example of the same document type, along with the project-specific inputs (site data, design parameters, client requirements), and ask it to generate a first draft. The output won’t be submission-ready. But it’ll be a solid starting point that saves 4-6 hours of staring at a blank page.
What makes this work: providing the example. LLMs are mediocre at generating documents from scratch in a specific professional format. They’re excellent at adapting an existing document to new inputs. Always give the model a template or example.
What doesn’t work: expecting the LLM to get technical details right without providing them. If you ask it to “write the process description for a lithium battery NMP recovery system,” it’ll write something that sounds plausible but contains critical errors. If you give it your PFD, your mass balance, and your equipment list, and ask it to write the process description based on those inputs, the result is dramatically better.
Code Generation for Engineering Calculations
Environmental and process engineers do a surprising amount of programming — Excel VBA macros for repetitive calculations, Python scripts for data processing, MATLAB for modeling. Most of us are not professional programmers. We write code that works but is ugly, hard to maintain, and takes three times longer to write than it should.
LLMs are genuinely useful here. A prompt like:
“I have a CSV file with columns for date, flow rate (m3/h), pH, COD (mg/L), and TSS (mg/L). Write a Python script that reads the file, calculates daily averages, identifies any days where any parameter exceeds these limits (flow > 500, pH < 6 or > 9, COD > 150, TSS > 50), and outputs a compliance summary to a new CSV file.”
…will produce a working script in 30 seconds. An engineer might spend 45 minutes writing and debugging the same thing.
The key to getting useful output: be specific about inputs, outputs, and edge cases. The difference between “write a script to analyze water quality data” and the prompt above is the difference between getting a toy example and something you can actually use.
Another pattern that works well: “Here’s my VBA macro that does X. I need to add functionality for Y. Show me where to add the code and what to add.” The LLM reads your existing code and extends it, rather than generating from scratch.
Technical Translation and Communication
Most engineers I know read technical English well but struggle to write it naturally. LLMs are excellent at taking technically correct but awkward English and making it read like a native speaker wrote it.
The workflow: write your technical content in whatever English you can produce. Feed it to the LLM with the prompt: “Polish this for a professional engineering audience. Keep all technical details and numbers unchanged. Fix grammar, flow, and word choice only.”
Critically: always review the output. LLMs occasionally “improve” text by changing a technical term to a synonym that isn’t quite right — “scrubber” becomes “washer,” “sludge” becomes “sediment,” “actuated valve” becomes “motorized valve.” These are close but not correct in a technical context. The review step is non-negotiable.
Research Synthesis and Literature Review
The volume of technical literature is overwhelming. When I researched AI applications in wastewater treatment, I found over 400 papers published in 2024 alone.
LLMs can help with the first pass: given a set of paper abstracts (which you can get from Google Scholar, Scopus, or Web of Science), ask the LLM to categorize them by application area, summarize the consensus findings, and identify the outlier results. This doesn’t replace reading the important papers. It helps you identify which ones are important to read.
A practical workflow: export 50-100 abstracts from your literature search. Feed them to an LLM with context about what you’re looking for. Ask for a structured summary: “Group these papers by application area. For each group, summarize the consensus finding. Highlight any studies whose conclusions contradict the consensus. List the 5-10 papers I should read first.”
This turns a two-day literature survey into a two-hour exercise.
Standards and Code Navigation
Environmental engineering projects involve dozens of standards — GB codes in China, ISO standards, ASTM methods, local provincial requirements. Finding the right standard for a specific question is a skill that takes years to develop.
LLMs can shortcut this: “What Chinese GB standard covers the design of industrial wastewater treatment plants for the chemical industry? What are the key effluent parameters it specifies?” The model will identify the relevant standard and summarize the key requirements.
But — and this is critical — always verify against the actual standard. LLMs hallucinate standards. They’ll cite a standard that sounds right but doesn’t exist, or quote a limit value that’s close but wrong. Use the LLM to point you in the right direction, then go read the actual standard.
What Doesn’t Work Yet
Engineering judgment. An LLM cannot look at a P&ID and tell you that a particular valve should be relocated for better maintenance access. It cannot evaluate whether a proposed treatment process is appropriate for a specific wastewater. It cannot tell you that a vendor’s performance guarantee seems unrealistic. These are pattern-recognition tasks that require years of hands-on experience and cannot be reduced to text generation.
Design calculations. LLMs can explain how to calculate head loss in a pipe, but they make arithmetic errors when actually doing the calculation. They don’t “calculate” — they predict the most likely tokens based on training data. For actual engineering calculations, use engineering software. LLMs are useful for explaining the methodology, not executing it.
Project-specific optimization. Every plant is different. The optimal solution for Plant A might be wrong for Plant B because of a constraint the LLM doesn’t know about — space limitations, operator skill level, existing infrastructure, client preferences. LLMs provide general answers. Engineering provides specific ones.
The Engineer + AI Workflow
The most effective pattern I’ve seen: engineer does the thinking, AI does the drafting. The engineer defines the problem, gathers the inputs, makes the judgments, and reviews the output. The AI writes the first draft, generates the boilerplate, formats the references, and checks for consistency.
This isn’t about replacing engineers. It’s about spending less time on the parts of engineering that are clerical work and more time on the parts that require professional judgment. The 40-hour work week doesn’t get shorter — but the proportion of it spent on genuinely valuable engineering work goes up.