Approach

Utilities should not try to build everything themselves. Commercial systems, vendors, and proven platforms are often the right answer, especially for regulated, commoditized, or operationally critical functions.

But some problems are too domain-specific, too exploratory, or too entangled with local knowledge to outsource completely. Digital twins, data-access tooling, decision support, and AI-assisted workflows often need internal software competence so the organization can inspect, adapt, and own the capability.

I use AI agents and coding tools as leverage, not as a substitute for judgment. They are useful because they compress implementation cycles: scaffolding interfaces, testing ideas, refactoring code, generating documentation, and exploring unfamiliar technical territory faster.

The value still depends on the person steering the work. Domain knowledge, architecture, validation, privacy, governance, and taste determine whether fast output becomes useful software or just a convincing prototype.

For operational work, I prefer explicit software models wherever possible: typed APIs, visible assumptions, testable calculations, source metadata, versioned logic, and clear user workflows.

AI can help interpret, summarize, generate, and accelerate, but the important operational knowledge should not disappear into an uninspectable model. Good systems make the reasoning easier to challenge.

A prototype can prove that a capability should exist. A product has to answer harder questions: who owns it, how it is deployed, how it is validated, how changes are reviewed, what data it can use, and how people know when not to trust it.

That is why I treat documentation, internal SDLC, access control, data quality, testing, and operational adoption as product work rather than administrative overhead.