There is real engineering value here, but it is not the story told in every demo
Large language models are impressive at producing explanations, reorganising information and translating between formats. That makes them unusually useful for engineers because engineering work contains a surprising amount of language: specifications, code comments, change requests, test protocols, meeting notes, alarms, tickets and operating procedures.
At the same time, a language model can confidently produce an answer that is technically wrong. In a factory, that is not a philosophical problem. A wrong terminal number or a bad sequence recommendation can waste hours or create a safety issue.
Where LLMs already save time
Documentation is the obvious starting point. An engineer can ask an LLM to turn a set of commissioning notes into a structured handover document, explain a complex Structured Text routine, convert repetitive text into a table or draft a test checklist.
Code review is another useful area. An LLM can identify duplicated logic, suspicious variable names or missing comments. It is especially valuable when used as a second pair of eyes rather than an authority.
Why prompts are not the main skill
There is considerable attention on prompt engineering. For industrial work, context engineering is usually more important. The quality of an answer depends on what the model is given: the relevant specification, tag definitions, error logs, process state and constraints.
A weak prompt says, “Fix this PLC logic.” A strong engineering request explains the PLC family, programming language, intended sequence, relevant I/O, current behaviour and the constraint that safety and interlocks must remain untouched. The model can then reason within a defined boundary.
Do not confuse fluent language with verification
A technically polished paragraph is not evidence. When an LLM produces code or an engineering explanation, the verification path must remain explicit.
For software, that means compiling and testing. For calculations, check the assumptions. For equipment behaviour, compare against documentation and actual signals. For a change affecting production, use the same review and approval process that would apply to a human-authored change.
Where LLMs are a poor fit
Real-time deterministic control is one example. Another is unverified generation of safety-critical logic. The fact that an LLM can write valid syntax does not mean that the resulting sequence satisfies the machine’s intended state model.
They are also a poor substitute for missing process knowledge. A model cannot infer undocumented tribal knowledge reliably. That knowledge must be captured in documents, data or explicit engineering rules.
The best role for an LLM
The most reliable pattern is augmentation. Let the model handle language-heavy work while engineers retain responsibility for engineering decisions.
In practice this means using LLMs as translators, reviewers, summarizers, document assistants and interfaces to well-defined tools. The model becomes an interface between people and information systems rather than the owner of the process.
The skill that matters most
Engineers who benefit the most from LLMs are not necessarily the people who know the longest list of prompts. They are the people who can break a messy problem into inputs, constraints, checks and expected outputs.
That is simply engineering discipline applied to a new tool. The model changes quickly. The underlying habit of defining the problem clearly is much more durable.
LLMs and the engineering knowledge boundary
An LLM is very good at manipulating language because language is exactly what it was trained to predict. An automation engineer deals with a much wider boundary: electrical states, timing, process physics, hardware dependencies and organisational procedures. Problems appear when the model is treated as though it has direct access to that wider world.
The solution is not to avoid LLMs. It is to connect them to authoritative information deliberately. Give the model the relevant specification. Retrieve the correct revision of the manual. Provide the actual alarm sequence. Then ask it to reason over that evidence.
Engineering documentation is an especially strong application
Consider a commissioning report containing 200 observations. Turning those notes into a structured handover document is repetitive but requires preserving technical meaning. An LLM can perform the first transformation quickly. The engineer can then check equipment names, dates, software versions and outstanding actions.
This kind of work creates a useful balance: the machine does the language transformation, while the engineer owns the technical truth.
A note on proprietary information
Companies should decide explicitly which engineering information can be sent to an external model service. Source code, recipes, customer information and security details may have restrictions. The convenience of a public AI interface should never bypass an organisation’s information-security rules.
Where an LLM becomes genuinely useful
The strongest applications combine language with structured engineering information. A model that can see an alarm timeline, a machine state diagram and the relevant procedure can help an engineer investigate much faster than a model that receives only a generic question.
The quality of the surrounding information therefore matters as much as model selection. Better context usually produces a larger practical improvement than endlessly changing the prompt wording.
What should remain human-reviewed
Anything that changes a production system, an engineering specification, a validated record or a control strategy should pass through the normal approval path. LLM assistance can accelerate preparation and review. It should not quietly replace accountability.
Use LLMs as a second engineer
A productive workflow is to ask the model to challenge the engineer’s assumptions, identify missing test cases and suggest alternative interpretations. This changes the interaction from “write this for me” to “review my engineering reasoning.” The latter often produces more defensible results because the human remains the author of the technical decision.
What improves as models improve
Better models will reduce some of the mechanical limitations: longer context, stronger reasoning, better code generation and more reliable tool use. They will not remove the need for source control, testing and engineering ownership.
The durable advantage therefore belongs to engineers who know how to turn a model into part of a controlled workflow rather than treating the model itself as the workflow.
LLMs are strongest when the input is already structured
The more precise the surrounding information, the less the model has to guess. A tag dictionary, approved terminology, machine state list and relevant specification can transform a vague question into a well-defined engineering task. This is why information architecture is quietly becoming part of AI engineering.
Use retrieval instead of hoping the model remembers
An industrial assistant should retrieve documents, tickets, drawings and standards from controlled sources. The model can then work over the retrieved material and point the user back to the evidence. This pattern is much more defensible than asking the model to answer from general knowledge.
Watch the economics of context
Large prompts are not free. Sending entire manuals or complete PLC projects to a model for every question creates unnecessary cost and may expose information that the task does not require. Good retrieval selects only the relevant context.
Engineering judgement remains the differentiator
Two engineers may receive the same model output and make different decisions because they understand the machine differently. That is not a flaw in the process. It is a reminder that AI should support engineering judgement instead of pretending to replace it.