The Software Development Skills Gap in Industrial Automation

I've worked on both sides of the fence. I've written ladder logic for pharmaceutical bioreactors and C# web applications for steel manufacturing. I've debugged PLC programs at 2 AM on a factory floor and deployed Django applications to AWS. That dual perspective isn't common in industrial automation, and that's a problem.

The industry is experiencing a massive skills gap, but it's not the one most people think. It's not a shortage of controls engineers who can wire a sensor or configure a drive. It's a shortage of people who can bridge controls expertise with software development fundamentals. And it's growing.

The skill set moved

Ten years ago, an automation engineer needed ladder logic fluency, panel wiring and instrumentation, P&ID reading, basic HMI configuration, and PID loop tuning. That skill set got you 90% of projects.

Today the same engineer also needs object-oriented programming, databases and SQL, version control, networking and cybersecurity fundamentals, containers, and cloud integration. This isn't a nice-to-have. It's table stakes, because the platforms made it so:

• FactoryTalk Optix uses C# NetLogic for custom HMI behavior. There's no escape hatch: you write code or you live with basic functionality.
• Ignition runs Python for everything from database queries to custom integrations. Developers who think they can avoid scripting hit a wall fast.
• OPC UA replaced proprietary protocols with one that demands security certificates, network architecture, and TCP/IP. Those are IT skills, not traditional controls.
• MES and ERP integrations mean your automation system talks to SQL databases, REST APIs, and MQTT brokers. You're not moving bits in a PLC anymore; you're managing data pipelines.
• Remote monitoring and cloud connectivity put edge computing and secure tunnel architecture on the automation engineer's desk, because those can't be handed off to IT anymore.

Training hasn't caught up

I have a Master's in Advanced Manufacturing from Colorado School of Mines, a great program where I learned robotics, lean manufacturing, and machine learning. Then I got hired to work on pharmaceutical SCADA systems and discovered what the coursework never touched: how to structure a C# application for maintainability. Git workflows for PLC and HMI code. SQL indexing strategies for historian queries. Debugging runtime NetLogic exceptions. Those skills came from side projects, late nights on Stack Overflow, and making mistakes on real projects.

That's the standard shape of automation training: strong on vendor software, wiring, control theory, and safety systems (all of which matter), and nearly silent on software architecture, database design, API design, and version control.

The gap runs both directions

I've mentored controls engineers and worked alongside software developers on hybrid projects, and the pattern is consistent.

Controls engineers struggle with object-oriented thinking (they think in sequences and state machines), git based version control (rather than check in check out), database schema design (they think in tags, not tables), asynchronous programming, and abstraction, because ladder logic is sequential.

Software developers struggle with real-time constraints (a web developer thinks 200 ms is fast; automation needs less than 10), physical I/O and hardware limitations, industrial protocols, safety interlocks, and the reality that a code crash can shut down production.

Neither group alone can deliver a modern automation system.

What convergence looks like on the ground

"IT/OT convergence" is a buzzword. Here's the ground truth, from one real deployment shape: Optix HMIs for a packaging line, with recipes stored in SQL Server rather than the PLC, automatic shift reports, MES integration for production counts, web-client remote monitoring, and role-based access synced with Active Directory.

Delivering that takes controls knowledge (tag mapping, alarm configuration, PLC communication), software skills (schema design, REST APIs, LDAP integration), and IT skills (server administration, firewall rules, network security). One person needs all of it, or a controls engineer and a developer working closely enough to speak each other's language.

Hiring one or the other doesn't work

Job postings still read: "Controls Engineer needed for Optix HMI project. 5+ years PLC programming, FactoryTalk View, panel design." That engineer will get the basics working and then hit walls that are software-engineering walls: How do I structure NetLogic for reuse? How do I parameterize queries so I'm not shipping an injection hole? How do I handle async database calls without freezing the UI? How do I implement real error handling and logging?

Hiring "just a software developer" fails symmetrically: they build elegant systems that miss real-time constraints, and treat "restart the server" as a recovery strategy in a plant where the server restarting is the outage.

For companies staring at this, three things actually work. Cross-train and pair the two groups on real projects; learning by doing is fastest. Run architecture reviews with both sides of the DMZ at the table, early, so network issues aren't discovered at commissioning. And establish shared standards: version control for PLC and HMI code, naming conventions that work in code and in tags, security policies that don't break plant operations.

The engineer who codes, and the new coworker

In ten years there won't be "controls engineers" and "software developers" on automation projects. There will be automation engineers who code: people who start from controls fundamentals (because you can't fake real-time), pick up software practice (because the platforms demand it), and understand the infrastructure their systems live on. The transition is already visible in every platform decision Rockwell, Siemens, and Inductive Automation have made this decade.

But while the industry works on closing that gap one engineer at a time, a third actor has arrived on the project. AI agents write fluent C#, Python, and SQL. They know Git cold. They never skip the boring parts. They have, in other words, exactly the half of the skill set this industry has been missing, and none of the other half. An agent has never stood at a panel during a factory acceptance test. It has never watched a valve. It doesn't know, in any way that counts, that a bad write opens one.

So the skills gap inverts. For human engineers, the missing half was software. For AI, the missing half is controls judgment, and that judgment can't live in the agent's experience, because the agent has none. It has to live in the tools we hand it.

Where AI in controls actually gets designed

Put the three on one diagram and the useful part is the overlap.

Controls engineering alone knows what the process can tolerate, but rarely builds tooling an agent can drive. Software development alone can build a clean API and a test suite, but doesn't know that a write to the wrong tag moves a valve. AI alone writes plausible code with no sense of either.

Designing AI for controls happens in the middle, and most of it is software architecture applied with controls judgment:

• Typed tools, not open access. The agent gets a narrow set of operations an engineer would recognize (read a routine, propose a rung, test it), not a raw connection to the controller.
• Staging the plant can trust. Emulators like Logix Echo and the Optix emulator do the job a staging server does in software: the change runs there first.
• Authority from the engineering artifact. What the agent may write comes from the controller's own program, not from a config file someone forgets to update.
• State you can see. Every change shows up where engineers already look, like Studio 5000's pending, testing and assembled edits, so a person can stop it at any step.
• Version control and an audit trail. Every change is recorded, diffable and reversible, the same discipline software applies to code.

None of that is AI research. It's software architecture and development practice, applied by someone who has stood at the panel. That's why this skills gap matters more now, not less: the people who can design AI tooling for controls are the same people this industry has been short of all along.

That's the tooling I've been building. In my next post, I'll show an MCP server making real online edits while the engineer watches in Studio 5000, with each change tested and assembled the way controls engineers already do it.

If you're hiring for this mix, cross-training a controls team, or asking whether AI can safely touch your control system, I want to hear about it.

Contact ASQI →

ASQI builds AI-assisted engineering tooling for industrial automation, and delivers Optix and Ignition projects and training.