A PLC runs a factory line. When an AI writes that control program, "the code looks right" is not a deliverable — the program has to compile against a real project, behave correctly in a real-time runtime, fail safely when something abnormal happens, and stay readable to the electrician on the floor. That is the gap most AI coding tools never cross, and it is exactly what a new research framework called SemaPLC is built to close.
Developed by a team at Shanghai Jiao Tong University with the Sema research group, SemaPLC does something deliberately unglamorous: it moves the entire PLC engineering loop — compile, deploy, run, verify, simulate — into the browser, and gates the AI agent on that loop instead of on its own confidence. The result is a shift from "AI can generate PLC code" to "AI can deliver PLC code that passes engineering checks." Along the way, it demonstrates a finding that matters far beyond factory automation: when a verification loop does the judging, small models can hold their own against much larger ones.
Why PLCs are AI coding's hardest case
LLMs have gotten surprisingly good at drafting PLC programs from natural language. Describe a motor start-stop sequence, a tank level controller, or a four-floor elevator controller, and a model will produce plausible Structured Text (ST) code under the IEC 61131-3 standard. That part works.
The hard part is everything after. Unlike a web service, a PLC program physically operates production lines, valves, elevators, and safety interlocks. It lives inside a pre-existing project with shared variables, timing constraints, and specific hardware interfaces. Code that compiles in isolation can fail to integrate; code that integrates can misbehave at runtime; behavior that looks right in normal operation can be wrong exactly when a fault occurs. In industrial automation, "looks correct" is not a quality bar — it is the beginning of the problem.
Inside SemaPLC: the agent becomes an engineering loop
SemaPLC's architecture is straightforward in concept and demanding in execution. The AI agent is decoupled from the PLC toolchain, which is exposed as a suite of engineering tools: compilation, deployment and run, variable read/write (including forcing), trace recording, behavior verification, and process simulation generation. Everything runs in a browser-based WebIDE where an engineer can enter requirements, inspect generated code, read ladder diagrams, and monitor variables in a single window.
The decisive design choice is verification gating. The agent does not declare a task complete when it believes the output is sufficient. It completes only when external checks confirm correctness: the code meets the specification, compiles, and behaves correctly in a live runtime environment. The model proposes; the toolchain disposes.
The results give the design teeth. On 117 standalone POU (Program Organization Unit) tasks matched to existing benchmarks, SemaPLC achieved the highest strict verification pass rate across all seven models tested, averaging 72.6% — roughly nine points above leading baselines such as Agents4PLC and AutoPLC. On a harder track of 65 project-context tasks, where generated logic must compile and run inside a real PLC project, it led in integrated compilation, static behavior, and dynamic behavior.
That last category is the one worth staring at. The paper's most instructive finding is the static-versus-dynamic gap: baseline approaches typically score around 70% on static analysis, then collapse to 20–30% when the same code is executed in a real-time environment. SemaPLC held an average 52.2% dynamic reliability — because its gate checks runtime behavior, not just whether the code parses. Dynamic runtime verification, the authors argue, is the most discriminating measure of whether generated control code is genuinely reliable.
The pattern: verification-gated coding
Seen from a distance, SemaPLC is one concrete instance of a broader pattern. Mainstream AI coding so far has been roughly "autocomplete at scale": the model generates, a human reviews, and — in the best setups — a CI pipeline runs tests. For ordinary software, tests are a proxy for correctness. For control logic, the proxy is not enough; the gate has to be the real runtime, comparing execution traces of generated logic against reference logic.
Think of it as the difference between a confident copilot and a flight checklist. A copilot's confidence is not what gets a plane down safely; the checklist is. Verification-gated agents treat the checklist as the source of truth, and the model as a proposal engine that can be swapped out. That is also why the "small model" result is not a paradox: when an external loop does the checking, model size stops being the decisive variable. A smaller model with a verification loop can reach pass rates that a larger model without one cannot — and at a fraction of the cost.
What this signals for the industry
Industrial automation has been one of the last holdouts for AI coding, for an obvious reason: the cost of failure is physical. A hallucinated function in a web app is a bug; a hallucinated interlock in a safety circuit is an incident. Verification-gated agents change the risk equation, which is what makes the pattern important, not the PLC domain itself.
The same logic generalizes to embedded systems, avionics, medical devices, and financial reconciliation — anywhere generated code must be proven, not just plausible. The bottleneck in AI-assisted engineering is shifting from generation quality to verification infrastructure: who builds the loop that can test AI output against reality, cheaply and continuously. That is a moat problem, and it is open to tooling companies as much as model labs. Chip design has already produced its first Level 5 AI engineer to pass engineering-grade sign-off, and the same logic is spreading to more hard-engineering domains.
There is also a democratization angle. If a verification loop lets small, cheap models pass engineering-grade checks, then mid-size integrators and factory teams without frontier-model budgets get access to AI-assisted engineering too. The same diagnosis applies to robotics mass production stuck at the 10,000-unit wall: the missing piece is verification infrastructure, not the model. The field standard also improves: benchmarks that report dynamic pass rates, rather than static scores, give buyers a metric that actually predicts field performance.
What to do with this
- Automation engineers: natural-language drafting of ST code is ready to try, but never merge AI output without compile checks, runtime trace verification, and simulation against abnormal scenarios. Treat "generated" as a draft, "verified" as the deliverable.
- Platform teams: build verification gates — compile, runtime trace, simulation — as first-class tools, not afterthoughts. The model is swappable; the loop is the moat.
- Procurement: when evaluating AI coding tools for industrial use, ask for dynamic verification pass rates on real projects. Demo videos are not evidence.
- Researchers and tinkerers: the SemaPLC paper (arXiv 2608.18565) and its benchmark are worth reading; browser-based PLC simulation also works as a fast, safe training ground for engineers learning control logic - part of the same simulation infrastructure that Veeda is building for robot training.
The takeaway is simple: the next stage of AI coding is not about smarter generation. It is about closing the loop between what a model proposes and what reality accepts. SemaPLC is an early, well-measured proof that the loop — not the model — is where the leverage now lives.
