Before I wrote my first n8n workflow, I spent eight years at Siemens working on industrial automation systems: PLC programming, SCADA systems, power infrastructure, and industrial safety. In that world, a system failure is not a bug report. It is a potential safety hazard.
That experience shaped how I approach software. Today I build Laravel applications and the AI workflows around them at VividSol, including our own products such as LaunchLancer and Invitation Arts, and the tools could hardly be more different. The habits carried over almost unchanged. These are the ones that matter most.
Commissioning, not "it ran once"
In industrial projects, a system is not finished when the code compiles. It goes through a factory acceptance test, then a site acceptance test, then commissioning on the real plant, with signed checklists at every stage. Every input is checked, every output is forced and observed, and every interlock is proven to trip.
In software I apply the same idea at a smaller scale. A feature is done when it has been proven in the real environment, not when it works on my machine. For a payment integration, that means a rehearsal against stand-ins for the bank, a check that proves the live connection without charging anything, and then the smallest real payment the bank accepts, refunded afterwards. It is commissioning, adapted to the web.
I/O lists become integration inventories
Every industrial project has an I/O list: every sensor, every actuator, its address, its range, and what happens when it fails. Nobody starts programming without it.
The software equivalent is an inventory of integrations. For every system an application talks to, I want to know the authentication method, who owns the account, the rate limits, how it reports errors, and what our system does when it is down. Most integration incidents I have seen trace back to a question nobody wrote an answer to.
Alarm management becomes alerts people read
Control rooms learned the hard way that an alarm flood is as dangerous as no alarms, because operators stop reading them. Good alarm design means each alarm is actionable, has a clear owner, and appears once per root cause.
Software alerting fails the same way. An error channel full of noise trains everyone to mute it. Every alert I set up has to answer three questions: what broke, where to look, and who acts. My n8n error workflows send exactly that, with a link to the failed execution, as I describe in Designing Production-Grade n8n Workflows. If an alert never leads to action, I remove it.
Operators need screens, not log files
In a plant, operators run the process through an HMI built for their decisions: the right values, in the right place, with the right context. Nobody expects them to read raw PLC memory.
Software teams often forget this. The person handling a customer's "I paid but nothing happened" message needs a payment log in the admin panel showing every step of that payment, not access to the server logs. The person running an MCP server needs a dashboard of tool calls and their errors. Building the operator's screen is part of building the system.
Management of change
Plants control changes formally: what changes, why, what could go wrong, how to undo it, and who approved it. A setpoint changed casually on a running plant is how incidents start.
In software this becomes reviewed pull requests, migrations, and a deploy process that can roll back. A good deploy script refuses to run on a server where files were edited by hand, records a rollback point before every deploy, and restores it automatically if a step fails. Editing production directly is the software version of changing a setpoint without telling anyone.
Determinism, and what to do without it
A PLC executes the same program in the same scan cycle, every cycle. Given the same inputs, it does the same thing. That predictability is the foundation of industrial reliability.
Language models do not offer it. The same input can produce a different output. My response is to keep the predictable parts predictable: fixed workflow logic around the model, validated inputs and outputs, and the model placed only where language has to be interpreted. I wrote more about that in Workflow First, Agent Second, and about safety specifically in What PLC Safety Interlocks Taught Me About AI Agent Guardrails.
Systems-thinking
Industrial automation taught me that systems-thinking is the foundation of reliable engineering. Every component affects every other component, and you cannot optimize one piece in isolation. A faster pump that starves the next stage of the process is not an improvement.
The same is true of software. A faster API client that hits a rate limit, an AI step that saves a minute but creates an hour of cleanup, or a deploy shortcut that breaks a neighboring site on a shared server: each one looks like progress until you look at the whole system.
My take
The bridge from industrial to digital automation is shorter than most people think. Both require understanding complex systems, designing for failure before it happens, proving things in the real environment, and building for the person who has to operate the system at 3 AM. The tools changed completely when I moved from PLCs to Laravel and AI workflows. The engineering mindset did not need to change at all.