This is probably a controversial thing to say to a room full of control engineers, so let me say it plainly: I think the graphical programming environment, the paradigm that almost every Advanced Process Control (APC) platform is built on, has quietly become the biggest constraint on how we build and maintain control solutions. Not the algorithms. Not the maths. The way we author them.
I want to make the case for moving on. But I also want to be honest about what that costs, because the alternative is not free.
Where the wiring diagram came from
Graphical programming is older than most of the people using it. Ladder logic dates back to around 1968, designed so that engineers who understood relay panels could program a PLC without learning to code. It was a brilliant piece of human-factors engineering, and it worked precisely because it was constrained. A PLC solving a well-bounded sequencing problem is exactly the kind of narrow domain where a visual notation shines.
Modern APC platforms inherited that lineage. Most are, at heart, dataflow engines: you wire blocks together on a canvas, signals flow from source to sink, and the picture is the program. For a simple loop it reads beautifully. The trouble is what happens when the problem stops being simple.
Why visual programming never took over general software
This isn't just my opinion from the plant floor. The failure of visual programming languages to displace text-based code in mainstream software engineering is one of the better-documented findings in computer science, and the reasons map almost perfectly onto APC.
Burnett and colleagues named the "scaling-up problem" back in 1995: "making visual programming languages suitable for solving large programming problems often seems to require the very complexities VPLs try to remove or simplify." Visual languages make easy things easier and hard things much harder. As logic grows, the canvas becomes a sprawl of overlapping connectors where an experienced engineer spends real time just tracing where a signal goes. Text, by contrast, is dense and information-rich; it scrolls, it nests, it searches.
There's even a rule of thumb for it, the Deutsch limit: "you can't have more than 50 visual primitives on the screen at the same time." Green's Cognitive Dimensions framework gives this teeth with the idea of viscosity, meaning how much effort a small change takes. In text, renaming something is find-and-replace. On a canvas, a small structural change can mean rerouting wires and rearranging blocks before you've changed any behaviour at all. And the evidence isn't kind to the visual side: surveyed professional programmers are the group most skeptical of its benefits, and a controlled study found "no benefits resulting from LabVIEW's visual notations for conditional logic" against text.
None of this means visual programming is bad. It means it's specialised. It earns its keep in PLC and DCS programming, in business-process modelling, in simulation tools like Simulink. These are bounded domains where the visual metaphor matches the problem. General-purpose engineering was never one of those domains, and large, evolving APC solutions increasingly aren't either.
The limits show up as missing tooling
Here is the part that bites in day-to-day work. When your program is a picture, you forfeit the entire ecosystem that the rest of the software world takes for granted.
Version control is the clearest example. Most platforms store the configuration in a proprietary binary or opaque format that standard version control tools, like Git, can't meaningfully read. You lose diffs, you lose merges, you lose branching. Move a block two pixels and the file changes even though the logic didn't. If you want to support a large fleet of controllers, the absence of real version control stops being an inconvenience and becomes a structural problem.
Testing is just as thin. Mature unit-testing and CI tooling effectively don't exist for these platforms. Verifying a change usually means running the solution and watching it behave. That makes upgrades slow and risky, so teams avoid them, which is exactly how you end up running interpreters and libraries that are years behind.
Most platforms do offer an escape hatch: a scripting block or custom code block. And I'll be candid: in practice you often get the worst of both worlds. You're writing text inside a constrained host, with a weak editor, poor debugging, an older language runtime or worse a proprietary language, and none of the modern practices the wider software world relies on. You've left the visual paradigm without arriving anywhere better.
The ground has genuinely shifted
I wouldn't be writing this five or ten years ago, because the alternative wasn't realistic yet. A few things changed that.
Open communication standards finally landed in industrial control. OPC-UA was ratified in 2008 but only really started penetrating the market around 2018; MQTT with Sparkplug B has followed. For the first time, getting data in and out cleanly doesn't depend on a single vendor's stack or even a single operating system.
At the same time, the open-source numerical ecosystem became something no single company could hope to match. NumPy, pandas, scikit-learn and their relatives are higher quality than anything most of us could build in-house, and there are serious control-specific libraries now too, such as do-mpc from TU Dortmund and GEKKO from Brigham Young for nonlinear and model-predictive control. And languages like Python have matured into a credible, well-supported home for all of it.
Put those shifts together and the decisive move becomes obvious: build the platform itself out of text and open-source components. That one choice changes your relationship to the wider software world. Instead of waiting for a vendor to expose each new capability, you inherit the ecosystem's momentum directly. Two consequences follow, and they are what the rest of this piece is about. The first is that you can ride the extraordinary pace of AI development rather than watch it from behind glass. The second is that you gain deployment options a Windows-bound graphical tool simply cannot offer.
Where AI fits, and where it must not
Start with AI, because the moment the platform is text on top of open source, the whole trajectory of AI tooling becomes available to it, with no vendor bridge required. But it's worth being precise about what that does and doesn't mean, because "AI in control" is doing a lot of work in conference talks right now, and most of it quietly conflates two very different things.
The first is putting a large language model (LLM) directly in the control loop, letting it move setpoints or manipulate final control elements in real time. I'm deeply cautious here, for three reasons. The first is simply where it runs: most operating sites don't have ultra-reliable internet, and a controller that depends on a round-trip to a cloud-hosted LLM is a controller that fails when the link does. The second is cybersecurity: every external dependency you add to a control path is another attack surface on equipment that moves real mass and energy. The third is the deepest. LLMs are not deterministic, and determinism is a non-negotiable requirement at the lower levels of APC. A regulatory or supervisory layer must do the same thing given the same inputs, every time, or you cannot reason about its safety or stability. An LLM that might respond differently on two identical cycles has no business there.
But notice where that argument stops. Non-determinism is only a liability where determinism is required. At the top of the stack, discovering and formulating the high-level recipe that the deterministic layers then execute, variability isn't a flaw; it's the whole point. Exploring a space of possible operating strategies is exactly the kind of task where you want a system that can surprise you. The trick is architectural: keep the creative, non-deterministic LLM in engineering and strategy, and keep the deterministic control logic in the loop.
Which brings me to where agentic engineering genuinely earns its place today: not in the loop, but in building what goes into it.
Rapid development. The cycle from idea to working controller collapses. The engineer describes intent; the agent does the mechanical heavy lifting.
Higher quality, not just higher speed. This is the part people miss. The APC engineer sets the goals and the guardrails, and the agent implements them along with all the artifacts we know we should produce but rarely do (unit tests, user documentation, change history), kept in sync because generating them is no longer the bottleneck. The discipline that was always "optional" becomes cheap enough to be the default.
Control-model development at a different pace. Pair a capable agent with the open-source numerical ecosystem and building a high-quality control model becomes genuinely fast. The agent fluently wires together the same libraries an expert would reach for, but in a fraction of the time.
And because control models become cheap to build, you build several. Once the cost of producing a candidate control model drops far enough, it's feasible to generate a handful and keep the best, rather than betting everything on the first one that works. That's a qualitatively different way to engineer control.
The through-line back to the rest of this argument is simple: none of it works from inside a wiring diagram. Agentic tools assume a text substrate. A proprietary graphical environment can't tap into them unless the vendor builds the bridge, and that's far from trivial. A text-based solution gets that entire trajectory more or less for free.
Deployment is where it really pays off
The second consequence is operational, and it's the one I'd most want a sceptical colleague to notice. It also falls straight out of the platform choice, and it comes from containerisation.
Once a controller is text and code rather than a canvas tied to one Windows application, you can package it, the logic, the runtime and the exact library versions, into a container with Docker. What runs on the engineer's laptop is bit-for-bit what runs on the plant, which quietly kills a whole category of "works on my machine" failures. Rebuilding a node becomes pulling an image, not reinstalling and reconfiguring an application by hand.
From there it scales. Tools like Azure IoT Edge (and equivalents) let you push and manage containerised workloads across many sites, with central monitoring and staged rollout. Every one of those deployments runs on the site's own hardware. In Azure's vocabulary that hardware is "the edge", but nothing leaves the plant: the containers, the control logic and the data all stay on-premises. Orchestration handles restarts and health. Crucially, you also gain real deployment options: Windows or Linux, on whatever hardware suits the site, whereas the major APC platforms are essentially Windows-only. That flexibility is hard to overstate when you're trying to run control at scale rather than one bespoke installation at a time.
Notice that neither of these, the AI trajectory or this deployment flexibility, is a feature anyone set out to build. They are dividends. They fall out of a single decision: to make the platform text on top of open source rather than a wiring diagram. A graphical environment forecloses both, and no amount of vendor roadmap closes that gap, because the gap is the paradigm itself.
I'm not going to pretend it's free
If I only sold the upside I'd be doing the same thing I'm criticising. The text-based approach has real costs, and they're worth stating plainly.
Customer confidence is the big one. A recognised commercial platform offers a feeling of security: a large vendor standing behind it. Telling a customer the solution is "our code" is a harder conversation, even though the reality is subtler. The control logic is text either way, and any serious platform already needs people who can read it.
Skills. Competent programmers in a mainstream language are not hard to find. Competent programmers who also understand APC and minerals processing are rarer, but that scarcity exists no matter which platform you choose.
Engineering discipline shifts onto you. Exception handling, timing, and especially overruns become your responsibility. An unhandled exception or an algorithm that doesn't finish in its window has to fail safe: heartbeat logic reverts the loop to regulatory control. That's manageable, but it's deliberate engineering, not a checkbox. Commercial platforms don't necessarily protect you better here, but they do make it someone else's design problem.
Large deployments need architecture. A single-threaded program won't run an entire plant. You break the solution into independent services that communicate. Honestly, that's what you do with a large graphical solution too, just with different seams. Flexibility buys you power and hands you complexity in the same breath.
And some things are simply better left alone. Protocol bridging and drivers, such as OPC-DA gateways, are notoriously hard to get right across all the edge cases. Mature commercial connectivity tools exist for a reason; rebuilding them in-house would be a mistake.
The point isn't the language. It's the paradigm.
If there's one thing I'd want to land, it's this: this isn't really an argument for one language over another. It's an argument about whether our programs should be pictures or text.
The open-source, text-based way of working has already swept through corporate IT. Process control has held out longer, and for good reasons. Conservatism in a discipline that keeps plants safe is a feature, not a bug. But the conditions that justified the graphical status quo are eroding, and the cost of staying is starting to outweigh the comfort.
A modern APC platform, to my mind, should be built on open standards, support proper version control, make a sane software development lifecycle easy rather than heroic, lend itself to AI-assisted engineering, and let you adapt quickly. Almost none of that is reachable from inside a wiring diagram.
I don't expect everyone to agree, and I'd genuinely like to hear from people who think the canvas still wins. But after enough hours tracing connectors that a single line of code would have made obvious, I know which way I'm betting.
References: Burnett, M. M., Baker, M. J., Bohus, C., Carlson, P., Yang, S., & van Zee, P. (1995), "Scaling Up Visual Programming Languages," IEEE Computer 28(3), 45-54; Whitley, K. N., & Blackwell, A. F. (1997), "Visual Programming: The Outlook from Academia and Industry," Proc. 7th Workshop on Empirical Studies of Programmers, 180-208; Green, T. R. G., & Petre, M. (1992), "When Visual Programs Are Harder to Read than Textual Programs," Proc. ECCE 6, 167-180; the "Deutsch limit" is attributed to L. Peter Deutsch (coined by Fred Lakin); Noone, M., & Mooney, A. (2018), "Visual and Textual Programming Languages: A Systematic Review of the Literature," Journal of Computers in Education 5, 149-174; Johnston, W. M., Hanna, J. R. P., & Millar, R. J. (2004), "Advances in Dataflow Programming Languages," ACM Computing Surveys 36(1).
