If AI drafts the ladder logic, what's left of the PLC/controls engineer once code is free?

The shift

Producing plausible control logic — ladder rungs, structured text, function blocks, HMI screens — goes from scarce (an engineer's hours, gated by knowing the syntax and the standard patterns) to abundant and near-free. But commissioning that logic against a real, unforgiving machine stays scarce: the model can write a rung it can't test, and a wrong rung on live hardware is a blown fuse, a wrecked fixture, or a person hurt — not a red mark in a test runner.

The axioms

• The controls engineer's value is in authoring the logic, because writing correct ladder/ST for a given sequence is scarce skill-and-time.
• Volume and speed of code produced is a reasonable proxy for the engineer's output, because writing was the slow step.
• Someone must prove the logic against the physical machine before it runs in production, because the gap between code that reads correctly and code that behaves correctly on real hardware is only closable by test against that hardware.
• Someone must own the safety case and sign off that the line is safe to run, because a bad actuation has physical, irreversible consequences and a regulator/insurer needs a named human behind it.
• The "where code meets machine" judgment — timing, I/O mapping, failure modes, what a sensor actually reads under load — comes from experience with real plant, because that context isn't written down anywhere the way logic patterns are.
• When a line goes down, a named person is liable for lost production and for restarting it safely, because the cost is immediate, physical, and lands on the plant.
• Novel integration — a machine nobody has automated this way, a retrofit, a first-of-its-kind cell — is resolved by judgment because there's no proven pattern to copy.

Invalid axioms

1. The controls engineer's value is in authoring the logic. This rested on writing correct ladder/ST being a scarce skill-and-time bottleneck — you paid for the hours it took someone fluent in the platform to translate a sequence-of-operations into rungs. The model does that translation competently for standard sequences and across vendor dialects (Rockwell, Siemens, Beckhoff) that used to each demand their own specialist. The habit-trap: shops still bill and staff by logic-authoring hours, quote projects on rung count or program size, and treat "can write it fast in this platform" as the differentiating skill — pricing the step that collapsed.
2. Code volume and speed is a proxy for output. Speed of first-draft was the constraint, so more-code-faster read as more-productive. Now the draft is the cheap part and the proxy measures the wrong thing entirely — a fast, large, plausible program is exactly what the model produces before anyone has touched a machine. The habit-trap: estimating and reviewing by lines/rungs/screens rewards generating more untested logic, when the remaining work is subtracting and proving, not adding.

Unchanged axioms

1. Someone must prove the logic against the physical machine. The model has no live context — actual I/O wiring, real sensor behavior under load, scan-time timing, mechanical slop, what the drive does at the edge of its range. It writes confident logic it cannot execute or observe, and confidently-wrong here trips a fuse or crashes a fixture, not a test suite. Commissioning — running it against the real machine, watching it, catching the rung that's right on paper and wrong in steel — stays scarce and human. This is the load-bearing survivor: the shift moves the engineer's job from writing the logic to proving it.
2. Someone must own the safety case and sign off. A model cannot hold a professional stamp, cannot be named on a risk assessment, cannot be answerable to a regulator or insurer after an incident. Signing that a line is safe to run — and standing behind it — is accountability, and accountability didn't get cheaper because drafting did.
3. The "where code meets machine" judgment stays scarce. Knowing that a photo-eye lies when the part is shiny, that this conveyor coasts, that this E-stop circuit has a quirk — that context lives in hands-on plant experience, not in the corpus the model trained on. It's exactly what the model lacks and can't infer from a spec.
4. When a line goes down, a named person is liable and must restart it safely. Downtime cost is immediate and physical. Someone has to diagnose live, decide whether it's safe to bypass, and carry the consequence of a wrong restart — a physical-world, high-stakes call the model can advise on but not own.
5. Novel integration needs judgment with no pattern to copy. A first-of-its-kind cell or an odd retrofit is where a model trained on existing programs has the least to match against — and where it's least likely to know it's out of distribution while sounding just as fluent.

New axioms

1. Who is accountable when AI-authored logic causes a physical incident? When a rung the model wrote — reviewed quickly, commissioned under schedule pressure — energizes something it shouldn't and someone gets hurt, the liability chain has a new, unsettled link. The engineer who signed off, the vendor whose model wrote it, the shop that priced out real commissioning time: nobody has drawn that line, and "the AI wrote it" is not a defense a plant or a court accepts today.
2. How do you verify control logic at machine speed and at machine stakes? Reading a rung tells you it's plausible; only running it against hardware tells you it's correct — and you can't unit-test a hydraulic press. When logic is cheap to generate in volume, verification against a real (or high-fidelity simulated/digital-twin) machine becomes the bottleneck, and the industry has no cheap, safe way to prove a rung short of commissioning it. Whether simulation and digital twins can close enough of that gap to matter is the fast-moving call here — good twins shrink how much must be proven on live steel, but the last mile against the real machine, and the sign-off behind it, doesn't simulate away.
3. Where does the "code meets machine" judgment come from once nobody drafts by hand? The context that made senior engineers trustworthy was built by writing logic and then watching it fail on real machines. If juniors start from AI drafts, they may commission plenty but author little — and the reps that built commissioning intuition, and the ability to smell a bad rung before it runs, may not accumulate the same way.

Where it breaks

Shops still price and staff by logic-authoring hours (INVALID) while the actual scarce work — and the actual liability — moved to commissioning and safety sign-off (STILL HOLDS). So projects get quoted on cheap, fast, AI-generated code and underfund the one step that catches the rung that wrecks the machine (NEW): the estimate rewards volume of untested logic exactly where the risk concentrated. And the engineer who signs the safety case is now accountable for logic they didn't write and may have only skimmed (STILL HOLDS vs. NEW) — authorship and accountability have split on the shop floor, and "the AI drafted it, I approved it fast" is a liability posture nobody has actually tested until the first incident forces it.

ai-axioms.vercel.app/axioms/engineering/plc-controls-engineer-ai-axioms