If building becomes cheap, when does an experiment become something the organisation is prepared to own?

AI is making it much easier to build things.

That should be good news for experimentation.

When the cost of producing a prototype falls, more people can test ideas, put something in front of users and discover whether an assumption survives contact with reality.

The barrier to learning can fall with the barrier to building.

But building something and owning something are different commitments.

A prototype can be temporary. It can have a deliberately small audience. Its data can be constrained. Its failure can be tolerable. It can be stopped tomorrow without anybody depending on it.

A service cannot rely on those assumptions.

Once people depend on something, different questions become important.

Who owns it? Who supports it? What happens when it fails? What data does it use? What can it access? How is it secured? How is change controlled? How much does it cost to run? What happens if a supplier disappears? Who decides when it should be retired?

Those questions are not arguments against experimentation.

They are the difference between experimentation and operation.

Permission to experiment is not the same as permission to operate.

That distinction becomes more important as software becomes abundant.

When building was expensive, the cost of creating something acted as an accidental control. Relatively few ideas made it far enough to become software in the first place.

If AI removes much of that friction, organisations need a more deliberate boundary.

The answer should not be to recreate the old friction at the start.

If every small, reversible experiment has to satisfy the requirements of a production service before anybody can learn from it, much of the value of cheaper experimentation disappears.

Instead, the path should be easy at the beginning and clearer at the point where the nature of the commitment changes.

An experiment might have a limited audience, synthetic or tightly controlled data, bounded permissions, a short life and an explicit owner.

If it proves useful and people begin to depend on it, the rules change.

That is the point at which questions of service ownership, resilience, security, support, accessibility, cost, data and operational accountability become unavoidable.

This is closely connected to the economics of certainty.

Cheaper building allows organisations to learn before making a large commitment. Proportionate governance should make that learning easier, not harder.

But cheaper experimentation does not make production consequences disappear.

It makes the transition between the two more important.

There is also a connection to the organisational harness.

A good harness can make responsible experimentation easier by providing reusable identity, permissions, observability, evaluation, cost controls and safe ways to connect to organisational systems.

The safe path becomes easier because some of the controls no longer have to be invented by every team.

That creates a useful separation.

Experiment freely within clear boundaries.

Cross a deliberate threshold before asking the organisation or its users to depend on what you built.

As software becomes easier to create, building may become less of a commitment.

Owning still isn’t.