Engineers have spent the past few years working out where generative AI genuinely helps. Many now use large language models (LLMs) to find information, organise calculations, write code, prepare specifications, review documents and explore alternatives more quickly.
The pace of improvement has been startling. It has also revived an old question in a more serious form: will AI replace engineers?
Basic engineering tasks are already being automated. Process simulators can construct an initial flowsheet from a written description. Machine-readable P&IDs can be checked for omissions and inconsistencies. AI assistants can suggest thermodynamic models, investigate convergence problems and produce draft control narratives.
The important word is draft.
Engineering judgement is not easily replaced because it is earned in places where models, procedures and plausible answers meet a difficult physical reality. It comes from standing beside a troublesome pump, commissioning a control system that refuses to behave, finding a bad instrument impulse line at two in the morning, or working through a material balance by hand because the simulator result simply cannot be right.
AI can assist with much of the work around those moments. It does not yet carry the responsibility for recognising when the answer is dangerous.
The experience pipeline is under pressure
Every generation of engineers has adopted better tools. Slide rules gave way to calculators, hand-drawn drawings to CAD, and manual heat and material balances to process simulation. Few would argue that engineers should return to graph paper and slide rules as their normal working method.
Yet engineers had to understand what those tools were doing. A slide rule did not remove the need to understand orders of magnitude. A simulator did not remove the need to close a mass balance, select an appropriate thermodynamic package or question an implausible answer.
The same discipline applies to AI.
The concern is not that younger engineers will use AI. They will, and they should. The concern is whether engineers who start their careers with AI doing the basic work will develop the conceptual grounding needed to supervise it.
An engineer may be able to ask an AI assistant to prepare a preliminary heat exchanger datasheet, generate a cause-and-effect matrix or suggest a control strategy. But can that engineer recognise an unreasonable temperature approach, a missing safeguarding layer, a bad process assumption or an instrument selection that will fail in the actual operating environment?
Those skills are developed over years. They come from doing calculations, making design decisions, seeing plant equipment commissioned and living with the consequences when the first version was wrong.
There is an attractive argument that AI will free engineers from routine work so that they can focus on higher-value and more creative work. There is truth in that. Good engineering has always required imagination as well as analysis.
But removing too much of the foundational work creates a problem. It is difficult to become a strong reviewer of engineering output without first having produced and defended that output yourself.
Plausible output is not necessarily good engineering
Most engineers who use AI productively have already encountered its central weakness. It can produce material that looks convincing long before it becomes trustworthy.
The term “AI slop” is often used for low-quality text and images generated at volume. The equivalent in engineering is more subtle. A design note can be well structured, technically fluent and apparently complete, while containing assumptions that have not been checked, references that do not exist, incorrect constraints or a recommendation that makes no practical sense on a live plant.
The danger is compounded by the fact that the output often looks similar whether the underlying work was sound or superficial.
One engineer may submit a single prompt to an LLM, accept the first plausible response and circulate it. Another may spend several hours breaking the problem down, checking primary references, using more than one model, testing assumptions and comparing the result with accepted engineering practice. The documents may look remarkably alike.
Only one has been properly underwritten.
This is where experienced engineers become a constrained resource. Somebody must review the calculation basis, check the sources, challenge the assumptions and decide whether the result is safe enough to use. AI may reduce the time needed to create a first draft, but it can increase the review burden substantially.
That creates its own risk. If every AI-generated document requires a deep review by the same small group of experienced engineers, they become overloaded. Fatigue then becomes part of the safety case, even if nobody writes it down that way.
The answer is not to prohibit AI. It is to use it within a disciplined engineering workflow: traceable inputs, clear assumptions, independent checks, defined review responsibilities and an explicit distinction between generated material and approved engineering.
Tools that show where this is heading
A number of emerging tools illustrate how quickly AI is moving into mainstream process and automation workflows. They should not be confused with established commercial engineering suites, which have extensive development histories, support arrangements and proven industrial user bases. Nor should a free or open-source tool be used casually on a safety-critical project.
Their value lies elsewhere. They show what is becoming technically possible.
ChemE-as-Code is an open research platform from Delft University of Technology’s Process Intelligence Research group. It treats process design as a set of open, machine-readable and version-controlled engineering files. From the same underlying project data, it can generate and check process flow diagrams, P&IDs, 3D layouts, stream tables, material take-offs, cause-and-effect material and life-cycle assessment information. Its Process Atlas currently makes clear that the work is research output, much of it AI-generated and not independently reviewed. That caveat is important, but so is the direction of travel.
DEXPI Studio is a free desktop application for working with machine-readable P&IDs in the DEXPI standard. It can render a P&ID from its underlying model, inspect tagged objects, validate the model, compare revisions and export equipment, line, valve and instrument data. For instrumentation and control engineers, the key idea is that a P&ID need no longer be only a drawing. It can become structured engineering data that can be checked, queried and exchanged between tools.
DWSIM has long been a familiar open-source process simulator for students, researchers and practising engineers. It supports steady-state and dynamic simulation, a wide range of unit operations and thermodynamic methods, process control and scripting. Its newer AI features include an in-application assistant for questions about flowsheets and unit operations, AI-assisted design proposals and support for generating scripts. The value of the simulator remains its engineering models and solvers. The AI layer can help an engineer work with those models, but it does not remove the need to select and validate them.
Therqon AI Process Simulator takes the prompt-to-flowsheet idea further. A user can describe a process in plain language, review the AI’s proposed plan, then instruct the software to create and solve the flowsheet. The supplier is careful to state that the process results come from the simulator’s own solver, not from the LLM. It also includes an AI convergence adviser and a documented validation programme. This is a useful design principle: let AI propose and explain, but retain deterministic engineering models as the source of calculated results.
These tools are early indicators of a different engineering environment. The engineer will increasingly work with a collection of specialised assistants rather than a single chat window: a simulator, a P&ID model, a document generator, a standards search tool and perhaps agents that can carry out defined tasks under supervision.
The engineer remains accountable
No sensible engineering organisation should accept an AI-generated design simply because it is coherent, fast or attractively formatted. The governing question remains the same: who has checked it, against what evidence, and who is accountable for using it?
That requires engineers to learn more than prompting techniques. They need enough understanding of models, data, uncertainty and AI failure modes to judge when a tool is helping and when it is inventing confidence.
It also requires organisations to protect the pathway by which engineers gain experience. Graduate engineers still need opportunities to perform calculations, build models, investigate failures, participate in commissioning and see how operating constraints change design decisions. AI can accelerate this learning if it is used as a demanding tutor and assistant. It will damage the profession if it becomes a shortcut around the learning itself.
The immediate challenge is not whether AI can generate engineering work. It already can.
The harder question is whether the industry will still produce enough engineers who can tell when that work should not be trusted.
