AI can write PLC code. That is not the difficult part.
Given a reasonably clear description, a modern language model can generate Structured Text, ladder-style logic, variable declarations and supporting comments. The syntax may even be correct.
The harder problem is deciding whether the generated program represents the intended machine behaviour.
A PLC program is not just a piece of code. It is an executable representation of a physical system with states, interlocks, feedback signals, failure modes and operator expectations. AI can help produce the text. It cannot remove the need to understand the machine.
Good use: scaffolding
One of the strongest use cases is repetitive scaffolding. Generate a function block template for a family of valves. Create a state-machine skeleton. Draft alarm messages from a structured specification. Convert a signal list into a variable declaration block.
This can save real engineering time because the model is not making the core design decision. It is reducing typing and formatting work.
Good use: explanation
Legacy PLC software can be difficult to understand, especially when documentation is weak. An LLM can walk through a program, explain variable flow and identify sections that deserve manual review.
This is particularly useful when combined with the engineer’s knowledge of the machine. The model provides a second representation of the logic; the engineer checks it against physical behaviour.
Where the line becomes important
Safety-related logic, motion limits, machine interlocks and process protections should not be accepted simply because a generated program “looks right.” These functions require the same engineering verification they always required.
The same applies to changes that affect validated production processes. The presence of an AI tool does not change the organisation’s responsibilities around change control and testing.
Version control becomes even more important
AI-assisted development increases the speed at which code can be produced. That makes disciplined version control more valuable, not less.
Commit messages, review records, test evidence and clear ownership should remain part of the workflow. When an AI-generated change causes a problem three months later, the organisation needs to understand what changed and why.
A practical workflow
- Define the machine behaviour in engineering terms first.
- Give the model only the relevant constraints and interfaces.
- Generate a draft or small section.
- Review it against the state model and I/O list.
- Compile and test in a controlled environment.
- Use the normal commissioning and change-control process.
This is slower than accepting everything the model produces, but that is the wrong comparison. The goal is faster engineering without reducing engineering quality.
The most useful AI skill for PLC engineers
It is the ability to decide which parts of a control problem are textual and repetitive and which parts require actual engineering judgement. That distinction allows AI to remove low-value work while leaving the critical decisions exactly where they belong.
Why generated code can look better than it is
LLMs produce code that is stylistically convincing. Variables are named sensibly, comments look professional and the control flow often appears plausible. That presentation quality can create a dangerous psychological shortcut: the reviewer starts looking for syntax errors and stops questioning the machine behaviour.
Review should therefore begin with the state model. What should happen from power-up to normal production? Which transitions are allowed? What happens after a timeout, sensor failure or operator interruption? Only after that should the generated code be compared against the expected behaviour.
Test cases are the real specification
A good prompt may describe the intended behaviour, but a test sequence makes it concrete. Create tests for normal cycles, missing feedback, repeated faults, manual mode, restart after interruption and boundary conditions.
AI can help generate candidate test cases, which is useful because it can expose scenarios that a developer may have forgotten. The final test set should still be owned by the engineering team.
Use AI for code transformation carefully
Converting repetitive logic from one format to another can be efficient, but translation is not verification. A generated conversion should be compiled, simulated where possible and checked against the original behaviour. This is particularly important when vendor-specific semantics differ.
Documentation is an ideal companion use case
The same model that drafts a function block can explain its assumptions, list I/O dependencies and create a review checklist. That supporting documentation often provides more value than the raw code generation because it helps another engineer understand what was intended.
One practical rule
Never let the speed of code generation become the speed of approval. Generation can be fast. Review and verification should remain proportional to the consequence of the change.
A useful division of responsibility
Let the model propose syntax, examples, refactoring ideas and test cases. Let the engineer define the machine state, safety boundaries, acceptance criteria and final implementation. That division makes the tool productive without confusing authorship with responsibility.
Keep the prompt close to the specification
For reliable results, provide the exact interface, expected states and constraints rather than asking for generic “best practice” code. The closer the request is to the engineering specification, the less room the model has to fill missing details with assumptions.
Review generated code as if another engineer wrote it
The safest mindset is neither blind trust nor automatic rejection. Treat the generated program as a junior engineer’s proposal: potentially useful, potentially wrong, always subject to the same technical review and test discipline as any other implementation.
Prompt quality follows specification quality
Engineers sometimes try to solve code-generation problems by writing increasingly elaborate prompts. In practice, a clear machine specification usually produces a larger improvement. Define states, transitions, interlocks, fault responses and interfaces first; the AI can then translate that structure into code more reliably.
AI can review logic from several angles
A useful workflow is to ask the model to look for unreachable states, missing transitions, duplicated logic, suspicious timer handling and inconsistent naming. Each observation is then checked by an engineer. The model becomes a review aid rather than the final authority.
Simulation is the natural second step
When a generated sequence is plausible, test it against simulated I/O or a controlled test environment. Scenario-based testing is especially valuable for resets, power loss, sensor dropout and unexpected operator intervention.
Do not optimise for code volume
Generating hundreds of lines in one response feels productive but can make review harder. Smaller, well-bounded changes are easier to understand, compile and test. The engineering unit should remain the function or behaviour being changed, not the amount of text the model can generate.