Over the past two years, assistants built on language models have become a fixed part of development toolchains, and anyone writing industrial software has noticed. The useful question isn't whether AI will "change automation" — it's a more practical one, about day-to-day work. What does it actually speed up, what does it not touch at all, and which skills remain indispensable for a plant to start up and keep running.
The short answer: AI is an effective tool on the software side, less useful the closer you get to the field, and essentially useless the moment someone has to put their hands on a machine. The detail is worth going into, because the boundary isn't vague — it sits at a fairly precise point.
Where it genuinely helps: the software side
The clearest gain is on code that lives outside the PLC: supervision, services, databases, integrations, maintenance scripts, internal tools. Typically:
- Understanding someone else's code — inherited projects, undocumented libraries, applications whose original author is long gone. Having a module explained before touching it saves real hours.
- Writing the repetitive parts — protocol parsers, format conversions, test harnesses, queries, logging routines.
- Working through logs and traces — filtering thousands of lines, correlating events, narrowing down the window in which something happened.
- Producing documentation — functional descriptions derived from code, comments, translations, operator manuals.
- Searching large documentation sets — finding which part of a 900-page manual holds the answer, with the verification then done against the manual itself.
On PLC logic the advantage shrinks considerably. IEC 61131-3 languages are far less represented in the data these models are trained on, and more importantly the meaning of a function block depends on how the machine is wired, not on the text of the program. A model can help write a scaling function or read back a sequence in ST; it cannot know that a given sensor is mounted the wrong way round.
Diagnostics: it generates hypotheses, not confirmations
In troubleshooting the contribution is real, but it needs framing. Describe a symptom well and you quickly get an ordered list of possible causes, including ones you hadn't considered. It's most useful on technology you haven't touched in a while, or outside your usual area.
What no model can do is close the loop. A hypothesis is confirmed by a measurement: a trend, a controlled force, a test point, a cable followed to its end. And choosing which test to run first — the one that costs least and discriminates most — is precisely the skill built in the field.
Commissioning is not a software test
This is where the boundary becomes sharp. Start-up isn't checking that a program compiles or that logic is formally correct — it's checking that a physical machine behaves as intended. That means verifying I/O point by point, checking motor rotation direction, calibrating sensors and thresholds, running sequences dry before running them loaded, provoking alarms to see whether they actually trip, testing the emergency stop and the recovery after a power loss.
It's also the part that produces no text. A limit switch working at the very end of its travel, a vibration that wasn't there before, a connector that only makes contact when warm, a valve slower than its datasheet says: this information is gathered by looking, listening and measuring. It exists in no file, so it exists for no model.
The knowledge that isn't in the code
On existing plants, much of the work is reconstructing reality. The wiring diagram no longer matches, the terminal strip was renumbered years ago, there are blocks nobody documented, and there are shop-floor practices written down nowhere that nonetheless determine how the line is actually run.
On top of that sits a kind of judgement that resists formalisation: telling whether an alarm indicates a fault or is the normal consequence of a particular cycle; knowing how long a line can be stopped before the stoppage becomes a department-level problem; knowing which tests can be run in production and which wait for the weekend; knowing when to stop and ask. These are calls built on real plants, where mistakes have real consequences.
Functional safety: a separate matter
A clear distinction is needed between using AI as a working tool and putting a model inside the machine. The first concerns whoever does the engineering; the second changes the nature of the product and the rules that apply to it.
The Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027 and replaces Directive 2006/42/EC, lists in Annex I Part A safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions. The categories in that part of the annex are subject to conformity assessment procedures involving a notified body. In parallel, Regulation (EU) 2024/1689 (the AI Act) classifies as high-risk those AI systems that are safety components of products covered by the Union harmonisation legislation listed in its Annex I, with obligations phased in over time.
In practice: putting machine learning inside a safety function is not a free technical choice, and it has to be assessed with the regulatory texts at hand. Using an assistant to write supervision code is an entirely different matter and doesn't change the machine's classification. What doesn't change in either case is who answers for what gets put into service.
How to use it without getting hurt
- Use it where mistakes surface immediately and cost little. Code testable off the plant, scripts, documentation, log analysis. Not on logic that goes straight into a machine without a test.
- Don't paste what you couldn't rewrite yourself. Whoever puts code into a machine must have read and understood it line by line: in a plant there is no painless rollback.
- Always verify against the vendor manual. Library functions, parameters, firmware-dependent behaviour: on these points a model's output is a lead to be checked, never a source.
- Watch what you share. Customer code, diagrams, IP addresses, credentials and process data end up on an external service. The same rules apply as to any cloud service, and there is often a contract that makes them binding.
- Test in simulation first. A bench or a simulator catches part of the errors at almost no cost. It doesn't replace commissioning; it shortens it.
Mistakes to avoid
- Treating a job as finished when the code compiles. The long part of a project is rarely writing the program.
- Asking a model to "fix" safety logic. Safety functions are designed and verified against the applicable standards, not by trial and error.
- Handing diagnostics to someone who couldn't verify the answer. Without verification, a plausible answer and a correct one are indistinguishable.
- Confusing writing speed with start-up speed. Commissioning takes as long as it always did.
- Cutting the technical team on the strength of a productivity gain nobody has measured on their own actual work.
In short
AI raises the productivity of people who already know what they're doing, and it doesn't lower the level of skill this trade requires. An experienced technician using these tools closes the software part sooner and arrives on site better prepared. Someone without the fundamentals gets plausible code instead — which in a plant is worse than a program that won't compile, because the error doesn't show up in the office but in production, once the machine starts moving.
The work is what it always was: understand the process, read the plant, test, measure, sign off. The tools change; the trade doesn't.
How we can help
We develop and commission automation software — PLC, HMI, SCADA, custom applications and integrations — following the work from analysis through to testing on site. The tools we use during development exist to reach commissioning sooner and in better shape, because that's still where it's decided whether a plant works.
Have an automation project, a retrofit, or software that needs sorting out?
Get in touch for a technical assessment, with timings and commissioning arrangements agreed before we start.