There is a moment every engineer hits when they are deep in a commissioning job and the logic is not quite right. You have been staring at the same ladder for hours. You tweak a rung, run it again, same problem. You tweak another, run it again. Three days in, the equipment still is not working the way you want it to.

I have lived that moment for most of my career. Lately my day looks different. I describe what I need, walk away to do the I/O checks, come back, and it is built. I test it. Usually one thing to adjust. I say so, in plain language. It is adjusted. I keep moving.

That is not a hypothetical. That is how I am commissioning real projects right now with JasperX, the platform behind JasperMate.

The question is not whether AI is changing industrial programming. It already has. The question is whether you are ready to change with it.

The old mental model is breaking

For decades, the value of an industrial programmer was in their logic. The cleverness of it. The tightness of the ladder. The fact that they understood, rung by rung, exactly what the machine was doing and why.

In my experience, that mental model is now a liability.

Not because the logic matters less. Because you can get better logic, faster, without writing it yourself. The engineers who understand this are compressing commissioning time, running more projects, and getting to FAT sooner. The engineers who do not are spending days on something that should take an afternoon.

The shift is not technical. It is psychological.

You are not a programmer anymore. You are an architect.

Here is the reframe I keep coming back to: you were never really a programmer. You were always an architect who had no choice but to write your own logic.

Now you have a choice.

The job of an architect is to define the structure. In industrial terms, that means:

  • Tag hierarchy and naming conventions. How is the data organised? What structure do your tags follow? How will other systems make sense of what you are publishing?
  • MQTT data flow. What gets sent where, at what rate, in what shape? Who consumes it?
  • Functional description. What should this PID loop do? What are the sequence steps? What are the interlocks? What happens under each fault condition?
  • Interconnectivity. How does this subsystem connect to the rest of the plant? What happens upstream and downstream?

That is the work now. Define those things clearly, and the AI does the build.

Not kind-of does it. Does it. You test the result, you flag what needs adjusting, you describe the change, and it is done.

The hardest part: letting go of the how, without letting go of the sign-off

This is where most of us get stuck. It was the hardest adjustment for me.

We are trained to understand a system completely before we trust it. Ninety-nine percent certainty is not enough. We want to trace every tag, walk every rung, and check what happens when the flow switch sticks, before we sign off. It is why we are good at what we do. And it is exactly what makes this uncomfortable.

Because working this way means you stop reading the logic rung by rung. You read what changed instead.

Here is what I mean. When I ask the AI to build something, it shows me the change: the tags it created, the connections it configured, the outputs it will drive. I read that. I do not read the implementation underneath it. I can ask it questions about any of it, and it answers. Before anything deploys, it runs tests, in a simulated environment with the real values from the plant. I can ask for tests of my own, reject a result and ask for more, and read every result. And nothing reaches the live system until I approve the deploy.

That is what makes letting go of the how defensible. You are not trusting a black box. You are moving your attention from the rung to the change, from the change to the tests, and keeping the sign-off.

It still feels like losing control. What is actually happening is that you are gaining altitude. You are operating at the level of the system, not the level of the rung. You are out at the field terminals doing the I/O checks while the logic gets built. You are working out how the subsystems talk to each other while the build takes care of itself.

Key idea: You are not less in control. You are in control of the things that actually matter: the specification, the test, and the approval.

What this looks like on a real project

Say we want to extend an existing packing machine with a new infeed conveyor. The packing machine has its own Siemens S7 PLC and nobody is going to reprogram it. The conveyor has a motor, two sensors, and a light. We put a small controller with its own I/O beside the machine, and over the chat I give the instruction:

"We have a packing machine with a Siemens S7-1200 at 192.168.0.10. Connect to it and read Ready, Running, Fault and the parts counter from DB10. The hopper low switch is on your input 1 and the package present sensor at the infeed is on input 2. The conveyor is on output 1 and a stack light on output 2. Run the conveyor when the machine is Ready and the hopper is low, and there is no package already sitting at the infeed. Stop it immediately if the machine faults. Light on while the conveyor runs."

What comes back is the tags, the S7 connector with the DB10 reads, and the logic, with a summary of what it built and why. Then I ask for an operator page with the machine state, today's count and the conveyor, and it builds the HMI page. When it comes to writing the logic that drives the conveyor and the light, that goes through the deploy gate: the change is highlighted and it asks for my approval. The PLC is read, never written.

My approach: keep the functional description as a text tag inside the controller. Every new chat is pointed at that document, and the AI checks the naming convention, the descriptions and the rest of the standard against it before it builds.

I do not read the logic rung by rung anymore. I discuss how things should work, read what changed, read the tests, adjust in plain language, and move on.

On real jobs, with real equipment and a deadline, commissioning and FAT time has come down.

Why this matters for IIoT specifically

Industrial IoT sits in an interesting position. It is OT in its environment, IT in its tools. SCADA engineers have long occupied a strange middle ground: doing genuine software work but not identifying as software developers.

That ambiguity is about to resolve itself, and not in the direction of more coding.

The future IIoT engineer thinks at the level of data flows, tag hierarchies, and how systems connect. They understand what data needs to be published, in what shape, consumed by whom. They define the rules. The AI builds the logic.

This is not deskilling. It is a different kind of expertise, and arguably a more valuable one. The engineer who can specify precisely what a system needs to do, structure that specification clearly, and evaluate whether the result meets it is exactly what AI-assisted industrial tooling needs in order to work.

Engineers who are not controls-focused, electricians managing more complex systems, project engineers who need automation without a dedicated controls team: these are the people who benefit most immediately. The barrier has dropped.

Where to start

You do not need to overhaul your practice overnight. Here is where I would start:

  1. Specify before you build. Before you open the programming software, write down what the system needs to do in plain language. Inputs, outputs, sequence steps, fault conditions. That document becomes your brief.
  2. Write your naming convention down once and reference it every time. If you have a tag standard, make it a document and point every request at it. Consistency compounds quickly across a project.
  3. Read the change, test the behaviour. Resist the urge to walk every change of what was built. Read the summary of what changed, define what a passing test looks like, ask for the tests you want including the faults, and move on if they pass. Approve the deploy yourself.
  4. Keep the safety functions hardwired. E-stops, isolators, overloads, drive protection and guarding stay in the wiring, exactly as they do today. AI-built logic is process control, not a safety function.
  5. Give yourself three sessions to adjust. Your briefs will tighten. Your descriptions will improve. The first few attempts feel slow. They will not stay that way.

The bigger picture

The engineers who adapt earliest to this shift will not just be more productive in the short term. They will have a head start on a genuinely new professional identity: the industrial system architect.

Not a programmer. Someone who understands the full shape of an industrial system, its data structure, its interconnectivity, its functional requirements, and knows how to specify that clearly enough for an AI to build, and how to test and approve what comes back.

That is the skill that scales. That is where the value is moving.

Bottom line: If you are still trying to understand every rung of logic you did not write, the question is not whether you will have to change. It is whether you will change on your own terms or be pushed.