Generative Development for Trustworthy Operations at Scale
Vibe coding is cool. Engineers can turn an idea into a working interface quickly, put it in front of colleagues and show what is possible. A problem that was difficult to explain suddenly has something people can see and use.
The harder part is wiring it into the operation.
That interface needs live data from the right assets, with the right meaning. It needs permission to request actions, rules for what happens when a connection fails, and a way for another engineer to maintain it. Across tens of thousands of assets, those requirements become a substantial part of the solution.
Generative development should be the primary way engineers build operational software. To make that practical, it needs to help engineers build the connections, context and operational services beneath the interface. Trustworthiness must be part of that development process.
At XMPro, we use generative development to configure an established operational platform. The backend is parametric: its behavior is defined through explicit settings and connections within an engineered architecture spanning information technology and operational technology.
A solution consultant can configure that backend manually using our no-code and low-code tools. A generative assistant works from a description of the requirement. Both use the same components and execution environment. Engineers can inspect, edit, test and maintain the resulting configuration through existing tools. They can move between manual and generative work as needed.
Engineers can follow how a configured filter, calculation or integration processes data. Generative configuration preserves the deterministic, explainable nature of that parameter-driven backend. Using AI inside the running solution remains a separate engineering decision, with its own evaluation and controls.
Parametric Context Graph in XMPro Operational Context Engine (OCE) where AI builds the quer filters that you can inspect, review, and change to make the outcome explicit
Existing component tests provide evidence about how those components behave. Engineers then check the component choices, parameters and connections against the operating requirement, and test the assembled solution in its intended conditions.
XMPro is a platform engineers build on and run on.
Junior engineers can develop simpler solutions under supervision, learning how requirements become configurations and how those configurations behave. Experienced engineers can spend more time on complex problems involving several systems, with less effort spent on repetitive configuration. More people can contribute to the organization’s digital capability.
Generative tools reduce the effort of producing a first version. Engineering work includes defining the operating requirement, judging the result and maintaining it as conditions change. Those responsibilities continue after the first successful demonstration.
We pursue higher quality and lower costs through reuse and testing. The assistant should first look for an approved component, connector or template suited to the requirement. The next engineer needs to understand how the solution works and how to change it.
Understanding what a change will affect is part of that work. An assistant can help engineers inspect a configuration, trace its connections and identify what needs testing. Establishing the effect on the physical operation still requires operating evidence, testing or a validated model.
Neil Richardson and I recently returned to an iceberg visual I created through my work in the Digital Twin Consortium. It explains how much of an operational solution sits beyond what the customer sees.
The visible experience includes the application, its recommendations and the actions people or connected systems take. Below it are the decisions, approvals and processes that coordinate that work. Those depend on context: what the data means, which assets it describes, how they relate and what operating state they are in. Underneath is the data connected to the operation.
Our use of generative development extends through the iceberg, down to data and context. We use it to help configure data pipelines and construct the context that makes their output useful within the platform’s architecture.
What is below the waterline is what kills AI and Agentic Operations at scale
We used generative configuration to handle the complexity of a partner-led project in a large oil and gas facility. Large volumes of data needed connections, mappings and specific processing rules. Doing that manually would have required a team of experienced engineers, as it has on previous projects.
A coding assistant in a customer deployment produced block configurations for 51 Data Streams, the flows that connect and process operational data. The tool also assembles the flows and connects the blocks. Engineers review the generated configuration and run the tests, retaining responsibility for validation.
Generative tools could help build and run repeatable checks on the mappings and rules. This test harness would compare outputs with expected results defined and reviewed by engineers.
During initial setup, our Operational Context Engine (OCE) uses generative techniques to help construct context from source information, including the meaning and relationships that applications depend on. Engineering review checks whether that structure represents the operation correctly.
Our Visual Studio Code (VS Code) extensions are designed to let engineers use an approved coding assistant to generate and inspect configurations, make manual edits and prepare changes for controlled deployment. A generated front end connects to live data and permitted actions through supported platform services. The platform and configuration approach are already in use.
The wider market is also moving beyond screen generation. Public documentation for industrial pipeline tooling and platform development tools describes natural-language pipeline creation and generated applications and data models.
Consider a generated maintenance application. Its screen shows equipment condition and lets a supervisor request work. It needs the correct asset’s readings, units, timestamps and operating limits. A lost connection must be visible. A request for work must follow the authorized process, with enough information to explain why it was raised.
Across tens of thousands of assets, data must keep flowing when nobody has the application open. Several applications may need the same information. Connections, processing and access controls should be reusable services, with capacity and recovery tested against the expected workload.
Generative Configuration of XMPro DataStreams (data pipelines and workflows)
Trustworthiness has to become something engineers can test. The Industrial Internet Consortium described five characteristics: safety, security, reliability, resilience and privacy. They apply across every layer of the iceberg. IIC Trustworthiness Framework
Safety means avoiding unacceptable risk of harm to people, including harm arising from damage to equipment or the environment. A generated solution needs defined operating limits and checks before its recommendations or actions can affect the operation. Security means protecting systems and data from unauthorized access, alteration or disruption. Generated applications must use approved connections and enforce permissions for reading data, changing configurations and requesting actions. Reliability means performing the required function consistently under specified conditions over time. A data pipeline needs to process the correct measurements within its timing requirements throughout the expected operating period. Resilience means maintaining an acceptable service when conditions are disrupted, and recovering appropriately. If a source disconnects, the solution should make the loss visible, handle stale data and recover without duplicating operational actions. Privacy concerns people’s control over how information about them is collected, used and shared. Worker identities, locations and activity records need defined purposes, access and retention limits, including when used by a generative assistant.
The rigor should match the consequence. More users, sensitive data, connections to core systems or authority to request plant actions all warrant closer review. Define the required permissions, tests and approvals at the start, and revisit them when the use changes.
Verification checks that the configuration does what was specified. Validation checks that it solves the operating problem it was built for. A configuration can run without errors and still use the wrong measurement or recommend the wrong action.
We draw on verification and validation principles from Department of Defense Instruction (DoDI) 5000.61, which covers models, simulations and their associated data. We apply those principles to generated configurations, with an accountable owner reviewing the evidence before approving their use. DoDI 5000.61
The Digital Twin Consortium’s Security and Trustworthiness Working Group developed a trust vector approach for expressing requirements and capabilities across all five characteristics. It lets engineers compare what a particular use requires with what a system can demonstrate, keeping each characteristic visible in the assessment. DTC trust vector paper
For a generated Data Stream, I would use this to organize the evidence from verification and validation. Checks on access permissions would support the security assessment; tests of connection loss and recovery would support resilience. Engineers could see where the evidence meets the requirement and where work remains before approval. Changes to the configuration or operating conditions would prompt a review of the affected evidence.
A trustworthiness profile makes gaps visible across all five characteristics. For a generated operational solution, verification and validation provide the evidence behind the profile. The requirements depend on the intended use.
The same expectations apply whether a consultant sets the parameters manually or an assistant generates them. The tests and their results need to remain available to whoever maintains the solution.
The organization decides who may build, approve and deploy a solution, and what that solution may see and do. Its running services must enforce those permissions for every application, including a custom front end. Writing a restriction into a prompt does not establish that control.
When evaluating a generative development tool, ask an engineer to demonstrate a change after the first version works. Inspect the differences, interrupt a data source, attempt an action outside the user’s permissions, and have another engineer maintain the result. Check the version history and what you can take with you if you change tools.
An engineer may start by vibe-coding an interface. The operational solution needs the rest of the iceberg: live data, meaningful context, coordinated actions and services that keep working at scale. Making generative development the primary approach means giving engineers a faster way to build and support that whole solution, with the evidence and controls needed to trust it in daily operation.
Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. Drawing on 30+ years of experience in industrial automation, he helps organizations implement practical AI solutions that deliver measurable business outcomes while ensuring responsible AI deployment at scale.
He is the lead author of the Industrial AI Agent Manifesto, published by the Digital Twin Consortium in February 2026, a governance framework for trustworthy autonomous operations.
Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.
Read more on MAGS at The Digital Engineer
How this was made: I worked with Claude to check sources, draft from my direction and edit, and with Codex to review the argument and evidence. I do not publish anything I have not rewritten myself.
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 28 October 2026.
