Reliable Software Is Built for Failure

AI is shortening the distance between an idea and working code. It can trace unfamiliar systems, produce implementations and help construct tests at a pace that changes the economics of software development.

That speed raises the value of disciplined testing. The important question is not how quickly code was written, but whether its behaviour is explicit, independently checked and predictable when dependencies fail. In the AI era, contracts, failure simulations and release evidence matter more than ever.

Start with a testable contract

Software is easier to trust when the boundary of the job is explicit.

That might be an API schema, a tenant-isolation rule, a commissioning manifest or a control-programme contract. The important part is that the expected behaviour can be checked independently of the implementation.

For a multi-tenant service, that includes organisation-scoped records and tests around the boundaries between customers. For an edge gateway, it includes the shape of telemetry, command authority and what must remain available locally. For a controls engine, it includes declared inputs, outputs, timing and resource limits.

The contract turns “build this feature” into questions a test can answer. Can one organisation see another's data? Does a command reach only the intended gateway? Does a programme stay within its execution budget? What happens when an input disappears?

People and AI agents can help write the implementation and the tests. The contract has to remain the independent reference.

Test in layers

Small automated tests check rules quickly. Contract tests keep services aligned on the shape and meaning of data. Browser tests exercise the workflow a user completes. Simulation covers behaviour that would be slow or unsafe to create on live plant, while physical rigs exercise the boundary between software and a controller.

Together, those layers cover rules, interfaces, workflows, controls behaviour and field integration. No single green test suite proves all of them. Simulation environments and physical rigs belong alongside ordinary tests so each change moves through the engineering path that matches its risk.

Simulate failure before failure happens

The happy path is where software demonstrates a feature. Reliability is decided elsewhere.

Networks disappear. Processes restart. Device variants differ from the schedule. A field bus becomes slow. A write is rejected. Two records that looked like the same customer turn out not to be.

These conditions should be created deliberately before release. Kill a process during a write. Delay or duplicate a message. Remove a sensor. Return malformed data. Interrupt the network, then restore it. Each simulation should define what must remain true, how the system recovers and what an operator will see.

Chaos testing is useful when it is controlled and repeatable. The aim is not random damage. It is evidence that the system preserves its boundaries under stress: data is not silently lost, local operation continues where required, unsafe writes stay blocked and recovery does not depend on somebody noticing an invisible failure.

An edge gateway should buffer data through a connectivity gap. A commissioning simulation should include a restore path and verify it by readback. Controls scenarios should cover failed sensors, lost communications and safety interlocks. Suggested customer-data matches should remain reviewable when the evidence is uncertain.

Failure is not fully designed until the operator can tell what happened and what to do next.

Keep results attached to the change

Every change should produce a reviewable result that names what ran, against which artefact, in which environment and with what outcome. Persistent commissioning actions should also record the intended change and the restoration or readback. Deployments should connect the released version to the service carrying the work.

The result may be a test report, a signed programme bundle, a commissioning record or a live-status entry. Keeping it attached to the change makes the work straightforward to review: a person can inspect the code, the contract, the test and the release decision in one place.

Authority stays explicit

Not all actions are equal.

Reading a repository is different from deploying a service. Simulating a control programme is different from admitting it to a gateway. Planning a commissioning run is different from storing a device configuration.

Higher-impact steps need narrower authority. Some require a signed artefact, a fresh manifest or an owner acknowledgement. AI does not change that distinction; it makes a clear boundary even more important.

Faster feedback, same responsibility

Working with AI agents can shorten the loop between an idea and evidence about whether it works.

They can turn a control sequence into a first programme, a product decision into a tested implementation, or a large set of operational records into a reviewable migration. Engineers can spend more time defining the boundary, designing failure cases and judging the result.

The tools will become more capable. The engineering standard should become more explicit at the same time.

Reliable software is built by testing what should happen, forcing what should not happen and proving that the system remains understandable through both.