Instead of slowing down the AI Engineering Adaption
Ask anyone in our industry how fast OT / grid operational software should adopt AI coding, and you get the same answer: carefully, slowly, after everyone else. The grid is critical infrastructure. Mistakes have physical consequences. Let the SaaS world run the AI coding experiment first.
I understand the reaction. I totally understand this instinct. Having spent more than 25 years in operational systems for utilities, I really share the respect for what can go wrong. But I think the conclusion is wrong.
Grid operational software should adopt AI-assisted engineering faster than commercial software, not slower. Not because the risks are smaller. Because we have something most software teams don’t have: an independent (and deterministic ?) way to prove and verify whether the code is right.
Generating Code is solved
Coding agents now plan, specify, write, test and fix code in a loop until the tests pass. They produce far more code than any team can read. The speed of generating code is almost unlimited. It is no longer how fast code is written. It is how fast a team can prove the code is correct.
That changes the question from “Is AI coding safe enough for the grid?” to “Who can verify AI-written code most effectively, cheaply and most reliably?”
Asked that way, the grid looks very different.
Commercial Software has no Referee
Take a typical business application: a pricing engine, a checkout flow, a CRM or logistic workflow. What is the correct behaviour? Whatever the product manager meant, whatever the customer expected, and the last release happened to do. The truth lives in people’s heads and in tickets.
So when an agent writes the spec, the code and also writes the tests, all comes from the same understanding. If the agent misread the intent, the tests confirm the misreading. Everything is green. And everything is wrong.
Serious teams in payments / finance or healthcare fight this with heavy process. Most teams in business or commercial applications don’t. And many of those are now discovering that fluent AI-written code hides its mistakes well.
Because commercial software, in most cases, has no independent referee.
The Grid has a Referee called Physics
Grid Operational Software answers to Kirchhoff. Not to a product manager. Nor to clients’ expectations. Voltages, flows and losses follow laws that do not care who wrote the specification or code. Or the test cases.
That gives us what testers call an oracle: an independent source of truth to check results against.
In practice, that oracle is (easily) available:
Power-flow and network simulation. Tools like pandapower, OpenDSS and HELICS tell us objectively whether our AI generated code produces a physically plausible result.
Standardised data models. CIM and CGMES profiles can be validated by machines. A model that violates its profile fails, whoever wrote the code that produced it.
Recorded field data. Years of SCADA telemetry, alarms and events can be replayed against new code. There should be also enough data for the ugly days: storms, bad data, communication losses.
Operating limits. Thermal ratings, voltage bands and protection settings are explicit numbers. Not opinions. Not assumptions.
An agent that misunderstands a switching sequence can maybe fool its own unit tests. But it cannot fool a power-flow calculation. Every generated code that touches grid logic can run and be validated against simulated networks and replayed field data. Before a person looks at it. That is verification most software teams for commercial applications can only dream of.
And exactly this is the interesting or funny point. Our industry (meaning energy / utilities) treats our physics as the reason to be slow. It is actually our advantage. We can afford more AI-written code because we can check it much better. Based on physics.
Faster, but not careless
Faster does not mean careless. Commercial software is different from Grid Operational Software. Business applications are different from mission critical solutions.
Do you see what is not on the list? Trustworthiness of AI-generated code. There is no such thing like AI-written code is less trustworthy for grid operational software. It is exactly as trustworthy. As long it passes all the checks and verifications. Our job is to make those checks stronger than anyone else’s.
What about Vibe Coding
Vibe coding, meaning building software by describing what you want and accepting code you never read throughly by testing its behavior, is great for a commercial prototype. Near OT it has one place: exploration, with synthetic data, thrown away afterwards.
We vibe-code to explore. We engineer to ship. We engineer to orchestrate the grid.
The Line or Boundary that must not move
The discussion changes when the software itself contains AI. When we build software for the AI-native Grid. Solutions such as an agent that analyses alarms, forecasts load and DER output, and recommends actions.
In a commercial product, a wrong AI answer is a bad answer. In grid operational software, it can become a blackout.
This is where the cognition/control boundary matters. Cognition may be wrong; it must never act alone. Control must be deterministic and accountable. Between them sits a path that does not change, however good the models get:
The AI agent analyses and proposes.
A deterministic guard checks the proposal against limits, power flow, interlocks and policy, using trusted grid state rather than the agent’s own picture of the grid.
An operator approves or rejects.
The existing, certified SCADA or ADMS command path executes.
The agent never holds a control credential. Autonomy is earned in steps. Along the Journey of Trust: shadow mode, then advice, then action with approval, then bounded action within a narrow envelope. Each step up requires evidence. And a serious surprise moves the system one step down.
The same physics that verifies AI-written code also verifies AI decisions. The guard is, in the end, the oracle again.
Seven Questions for your Software Vendors
Most utilities buy their operational software rather than write it. Your vendors’ code is increasingly written by AI. Whether their sales reps and sales decks mention it or not. As discussed, that is not a problem in itself. The question is whether their verification kept pace. These questions help find out:
Which parts of your product are written with AI coding agents, and how do you mark AI-written changes?
Who reviews AI-written code before it is merged, and can an agent ever merge on its own?
How do you test grid logic against simulated networks and recorded field data before release?
What stops an agent from weakening or deleting a test to make its code pass?
How do you show that your tests actually catch bugs, not just pass?
Where does our data go when your engineers or your product use an AI model, and in which region?
If your product contains AI, what sits between its recommendations and a control action on our network?
Your vendor should be able to answer all seven without hesitation. Hesitation itself is an answer too.
Faster, because we can check
The grid industry is right in discussing the risk about AI-assisted coding. But the grid industry should focus more discussing where the real difficulty lies.
Writing code is no longer the hard part. Proving it correct is. And on that measure, grid operational software starts ahead: physics, machine-checkable standards, decades of recorded operations and explicit limits.
So the case for waiting is weak. Why would you? The utilities and vendors that move first will not be the ones that trust AI most. They will be the ones that verify best: simulation before review, people deciding what gets merged, and a guard between every AI recommendation and the network.
I don’t think the question is whether AI should write grid software. It is more who builds the verification to make it safe, and how soon.
What would it take for you and your organisation to trust AI-written code in operations? Would love to hear your thoughts and ideas!
Disclaimer: This article was published on the AI-native Power Grid Newsletter on Substack, but refreshed and updated for the Energy Central Community.