AI can now write PLC code — so what do engineers rely on?
CODESYS and Intel are exploring AI-assisted PLC programming via MCP, letting AI interact directly with the development environment—moving from writing code to sharing engineering work. Repetitive programming is most compressible, but industrial control's difficulty isn't producing code; it's handling abnormal signals, action conflicts, safe states and field validation. Future differentiation isn't

AI is starting to write PLC programs – are automation engineers' jobs still secure?
On October 7, the industrial technology media outlet Design News reported that CODESYS is exploring AI-assisted PLC programming with Intel. Through an AI interface, engineers can involve AI in control program development. CODESYS also plans to demonstrate how to use AI to develop a refrigerator control function module.
What is more noteworthy is that this is not simply plugging a code generator into a chat box, but enabling AI to interact directly with the CODESYS development environment through an MCP interface.
This means AI is moving from "helping you write a few lines of code" to "helping you complete part of the engineering development work."
So the question arises: are PLC engineers about to be replaced?
The real change may be exactly the opposite.
01What Is Most Easily Compressed Is Highly Repetitive, Clearly Ruled Programming Work
First, what is most easily compressed by AI is highly repetitive programming work with clear rules.
For example, generating routine function blocks, supplementing variable declarations, explaining existing programs, writing comments, creating test cases, and even generating part of the program based on clear control requirements.
This work used to require engineers to spend time completing; now there is an opportunity to hand it over to AI for assistance.
But don't forget, what is often hardest on the industrial site is not writing the program.
After a machine starts, what if the sensor signal is abnormal? When several actions occur simultaneously, how do you avoid conflicts? After an emergency stop, how do you ensure the system enters a safe state? If process conditions change, does the original control logic still hold?
These problems are not solved just because the code compiles successfully.
02AI Can Write Programs, but It Cannot Prove the Machine Can Run Safely
AI can help you write programs, but the fact that the program has been written does not prove that the machine can run safely.
This is where industrial control is very different from ordinary software development.
So what deserves more attention is not whether AI can write ladder diagrams or structured text, but whether it can truly enter the complete control engineering process:
Understanding requirements, generating programs, compile checking, simulation testing, on-site verification, and finally review and deployment by an engineer with the appropriate authority.
Of course, there is still a long way to go. Compiling successfully does not equal logical correctness, and passing simulation does not mean all on-site risks have been ruled out.
But the trend is already worth taking seriously.
03The Most Dangerous Engineer Going Forward Is One Who Can Only Write Programs but Does Not Understand Why the Machine Runs the Way It Does
In the past, the efficiency of an automation engineer largely depended on how fast he could write code, how many instructions he was familiar with, and how many program templates he had accumulated.
In the future, these capabilities will still matter, but may no longer constitute the main difference.
What truly sets people apart is:
Can you translate process requirements into correct control logic,can you identify abnormal operating conditions,can you verify AI-generated programs,and can you quickly find the real cause when equipment has a problem.
To put it bluntly:
Going forward, the most dangerous engineer is not one who cannot use AI, but one who can only write programs and does not understand why the equipment runs the way it does.
04For Industrial Software Companies, This Change Is Also Important
If AI can reduce part of the programming and testing costs, the competition in future automation projects may no longer just be about who writes code faster, but about who better understands processes and the site, and who can turn experience into reusable control modules and engineering methods.
So what truly deserves attention about AI entering PLC programming is not whether machines will take away engineers' jobs.
But rather, when writing code becomes easier and easier, where exactly should we reinvest engineers' time?
This question may be more important than how many lines of code AI can write.