There is a lot of noise around artificial intelligence replacing engineers, rewriting industries and making entire skill sets obsolete overnight.
Industrial automation tells a different story.
Can ChatGPT program a PLC? Yes. Can it replace an automation engineer? Not even close.
That gap between writing code and understanding industrial processes is where Large Language Models (LLMs) are genuinely changing industrial automation.
Whether you use ChatGPT, Claude, Gemini, GitHub Copilot, or developer-focused assistants such as Claude Code, Cursor or Aider, AI has become another engineering tool. The important question is no longer whether automation engineers should use AI, but how to use it effectively and safely.
For teams developing with Arduino PLCs, ESP32 PLCs and Raspberry Pi PLCs, the impact is already visible.
Which AI assistants are engineers actually using?
Today's automation engineers rarely rely on a single AI assistant. General-purpose models such as ChatGPT, Claude and Gemini are widely used to explain industrial protocols, review documentation, generate code examples and translate between programming languages. Development-focused assistants such as GitHub Copilot, Claude Code, Cursor and Aider integrate directly into the development environment. Each assistant has different strengths, but they all dramatically reduce the time spent on repetitive engineering work.
What changes
The entry barrier to PLC programming is dropping
Industrial automation has faced a talent shortage for years. The number of engineers familiar with IEC 61131 environments, proprietary IDEs and vendor-specific ecosystems has never kept up with demand. LLMs do not eliminate this problem, but they change the equation. Engineers already comfortable with Python, C++, Arduino, ESP32 or Raspberry Pi can become productive in industrial automation much faster than before.
This effect is especially noticeable on Arduino PLCs, ESP32 PLCs and Raspberry Pi PLCs, where development relies on technologies heavily represented in AI training data. Languages such as C++, Python and JavaScript have enormous public ecosystems, so assistants like ChatGPT, Claude or GitHub Copilot produce more reliable code than they do for niche proprietary PLC environments.
Repetitive programming becomes dramatically faster
Most industrial projects include a large amount of repetitive work: Modbus TCP clients, Modbus RTU masters, MQTT publishers, OPC UA communication, CANopen integration, EtherNet/IP examples, REST API clients, JSON parsing, SQLite data logging, Node-RED flows and basic PLC diagnostics.
These tasks consume a surprising amount of engineering time. An LLM can generate an MQTT client with TLS, a Modbus TCP polling routine or an OPC UA publisher in seconds. The engineer still validates and tests the implementation, but the starting point is much further ahead.
Documentation is no longer optional
Industrial automation has always struggled with documentation. The engineer who develops the machine often becomes the only person capable of maintaining it. LLMs change the economics completely. Generating readable explanations, commenting PLC logic, producing maintenance guides or creating commissioning procedures now takes minutes instead of hours.
Learning new protocols becomes much faster
Learning technologies such as Modbus, MQTT, CANopen, EtherNet/IP, BACnet or OPC UA used to require weeks of experimentation. Today an LLM acts as a technical companion throughout the learning process. It explains documentation, compares implementations and answers questions while the engineer builds the system. It does not replace learning. It significantly accelerates it.
What does not change
Understanding the industrial process
An LLM does not know that the level sensor inside Tank 3 slowly drifts after forty minutes. It does not know that stopping the conveyor during a production cycle destroys the product. That knowledge belongs to process engineers, machine builders, maintenance teams and system integrators.
AI generates code. Engineers understand consequences.
Safety and certification
Nothing changes here. Functional Safety. SIL. Performance Level. EN ISO 13849. IEC 61511. Machine safety still requires certified hardware, validated processes and documented verification. No LLM shortcut exists.
Testing on real hardware
Simulation remains simulation. Industrial installations introduce electrical noise, communication delays, timing issues and sensor tolerances that cannot be predicted from documentation alone. Every implementation must still be validated on the real machine.
Architecture decisions
Choosing between edge computing and cloud processing. Designing redundancy. Selecting communication topologies. These are engineering decisions based on experience and constraints. LLMs can inform those decisions. They cannot make the decision.
Where LLMs still fail
LLMs remain imperfect engineering assistants. They frequently invent libraries that do not exist, hallucinate PLC registers, misinterpret industrial timing constraints, ignore electrical limitations, suggest unsafe implementations, mix incompatible protocol versions and reference outdated documentation.
The best way to think about an LLM is as an extremely fast junior engineer. Everything still requires engineering review before deployment.
Who benefits the most?
This shift particularly benefits OEM machine manufacturers, industrial system integrators, control engineers managing multiple projects and teams deploying Arduino PLCs, ESP32 PLC platforms or Raspberry Pi PLC solutions. Open ecosystems benefit the most because the underlying languages and libraries are extensively represented in modern AI models.
Who should pay attention?
The engineers most at risk are not those who use AI. They are those whose only competitive advantage is writing the same boilerplate code repeatedly inside the same proprietary environment. The industry is not replacing engineers. It is rewarding engineers who adapt faster.
The real competitive advantage
The real competitive advantage is no longer writing boilerplate code faster. It is understanding industrial processes, designing robust system architectures, validating installations, ensuring functional safety, commissioning equipment and solving problems that AI cannot observe. LLMs reduce the time spent reaching good engineering decisions. They do not make those decisions.
Frequently Asked Questions
Can ChatGPT program PLCs?
Yes. It can generate Structured Text, Arduino C++, Python, communication routines and documentation for many industrial automation tasks. Every implementation should be reviewed and validated before deployment.
Can Claude generate Modbus code?
Yes. Claude performs particularly well when generating Modbus TCP, Modbus RTU and MQTT examples for Arduino PLCs, ESP32 PLCs and Raspberry Pi PLCs because these ecosystems are strongly represented in its training data.
Can AI replace PLC programmers?
No. AI accelerates programming, documentation and debugging. It does not replace process knowledge, commissioning, validation, safety engineering or field experience.
Which AI assistant is best for industrial automation?
There is no universal answer. ChatGPT, Claude and Gemini are excellent general-purpose engineering assistants. GitHub Copilot excels inside development environments. Claude Code, Cursor and Aider are increasingly popular among software developers working on larger industrial projects.
Final thoughts
The engineers who benefit most from AI are not those who trust every answer. They are the ones who know enough to question it. Industrial automation has always rewarded engineering judgement over shortcuts. LLMs do not change that. They simply allow good engineers to spend less time writing repetitive code and more time solving real industrial problems.
At Industrial Shields, we believe open platforms are naturally aligned with AI-assisted development. Our Arduino PLCs, ESP32 PLCs and Raspberry Pi PLCs are built on technologies such as C++, Python and open industrial protocols that modern AI assistants understand exceptionally well. The result is not smarter hardware. It is faster engineering.
