For a long time, building a computer system required at least some understanding of how it worked.
You had to set up a development environment, grasp a few architectural concepts, work with a database, write code, manage access rights, and eventually deploy the whole thing. That technical barrier was often unnecessarily high. It restricted digital creation to a relatively small group of people and could turn a modest business application into a months-long project.
Low-code and no-code began to lower that barrier. Artificial intelligence is now rapidly eroding it.
That is probably very good news.
Provided we do not confuse ease of creation with simplicity of what is being created.
Complexity Has Not Disappeared. We Have Hidden It.
A business user can now automate a process with Power Automate, create an application with Power Apps, or build an agent in Copilot Studio without mastering the underlying technologies.
Microsoft is taking this a step further with Copilot Skills in SharePoint. A procedure expressed in natural language can become a reusable Copilot skill, stored as a simple Markdown file. By default, a user with edit permissions on the site can create such a skill, while a user with read permissions can use it. Current capabilities remain limited to those available to Copilot in SharePoint.
Taken in isolation, none of this is particularly alarming. It is, in fact, the logical outcome of several decades of computing: making previously inaccessible technologies easier to use.
But while their interfaces become simpler, the systems behind them are moving in precisely the opposite direction.
A modern company relies on cloud services, dozens or hundreds of SaaS products, federated identities, APIs, connectors, B2B access, low-code platforms and, increasingly, agents capable of drawing on several of these resources at once.
Our dependence on this ecosystem has become considerable. An IT failure can halt production, prevent invoicing, disrupt a hospital or bring a public administration to a standstill.
We therefore face a curious inversion: the more indispensable and complex our systems become, the less understanding is required to act upon them.
We may be approaching a point where building a system becomes easier than understanding the system we have just built.
When Legitimate Permissions Produce a Capability That Is Not
For drafting a document or creating a room-booking application, the consequences are limited.
But the same ease of creation increasingly makes it possible to build an automation that reads customer data, queries a CRM, updates Jira and takes action in an ERP.
Each of those operations may be perfectly legitimate. The user has the necessary permissions in every system.
The problem emerges from their composition.
Information security has historically devoted considerable attention to determining who can access what. It must now address an additional question: what happens to a user’s capabilities when all their permissions can be mobilised, correlated and executed automatically by a machine?
No additional privilege is required to increase someone’s power of action dramatically.
This is one of the changes introduced by agents: risk no longer lies solely in access, but in what the combination of entirely legitimate access rights can now accomplish.
From Tuesday’s Experiment to Friday’s Critical System
Low-code popularised the notion of the “citizen developer”. The idea is compelling: allow the people who genuinely understand a business process to solve their own problems instead of turning every requirement into an IT project.
Abandoning that benefit would make little sense.
But someone assembling a few components through a graphical interface may not realise that they are creating an application on which an entire team will soon depend. Someone asking an agent to analyse documents and update several systems may be equally unaware of the trust boundaries they have just created.
Tuesday’s little experiment can become Friday’s critical system.
The phenomenon already existed with Excel and Access. What has changed is its speed, reach and ability to cross the boundaries of the information system.
The major technology vendors are perfectly aware of this.
Microsoft has long documented managed environments, data policies, application lifecycle management and mechanisms designed to govern citizen development.
Democratising creation has therefore not eliminated expertise. It has changed where that expertise intervenes.
Production remains a boundary.
A Boundary We Already Know How to Draw Elsewhere
Almost everyone uses another complex and potentially dangerous infrastructure every day without understanding its inner workings: electricity.
Yet democratising its use has never meant allowing everyone unrestricted access to every part of an electrical installation.
We are free to plug an appliance into a socket. Other interventions require qualified professionals. Some installations must be inspected. Connection to the grid is subject to additional requirements, and some parts of the infrastructure remain accessible only to its operator.
Nobody concludes from this that electricity has not been sufficiently democratised.
We have simply accepted a principle: the freedom to use a technology does not entail the freedom to modify, without oversight, an infrastructure whose consequences extend beyond its user.
Curiously, digital systems have largely escaped this logic.
Buying Does Not Remove the Need to Understand
Some organisations have adopted an apparently simple answer to the problem: stop building. Low-code is restricted, internal development discouraged, and “buy before build” sometimes becomes doctrine.
The risk does not disappear. It merely changes address.
Buying SaaS means entrusting part of your systems and data to a vendor, sometimes to that vendor’s own subcontractors, while accepting new identities, dependencies and trust boundaries.
Polished marketing, certifications and security questionnaires do not guarantee sound architecture or operational practices. A small, properly governed internal application may present less risk than a SaaS product whose architecture and supply chain the buyer barely understands.
Either way, someone is building the system.
The question is under what requirements, with what oversight, and with what responsibility.
Regulation Is Belatedly Catching Up With Software
For a long time, a substantial share of software risk was transferred to the buyer. It was the customer’s responsibility to choose the right product, configure it properly, integrate it safely, monitor it and control how it was used.
Public authorities are beginning to challenge that balance.
The European Cyber Resilience Act imposes cybersecurity obligations on manufacturers of products with digital elements, covering their design, development and the handling of vulnerabilities throughout their lifecycle. Conformity-assessment procedures also apply according to the category of product. Act
The United Kingdom is moving in a similar direction with its Software Security Code of Practice, which notably emphasises secure by design and secure by default.
The principle seems almost banal: those who build a digital product also bear responsibility for its security.
Yet it has taken software becoming ubiquitous infrastructure for us to begin embedding that idea seriously into rules and regulation.
And this realisation is arriving precisely as the major platforms move into a new phase. They no longer merely provide software. They provide everyone with the means to create it.
We Provide the Matches. Please Do Not Burn the House Down.
This is where a curious asymmetry appears.
Technology vendors understand the risks perfectly well. Their own documentation discusses development and production environments, data policies, access controls, auditing, lifecycle management and review before publication.
They know that an application created in a few hours can become business-critical. They know that a connector creates new paths along which data can travel. They know that an agent capable of taking action is fundamentally different from an assistant capable of answering a question.
At the same time, their commercial proposition increasingly tends towards radical simplicity: create, automate, connect, simply describe what you want to achieve.
Then comes the governance documentation, which essentially says: we provide the matches; we know they can burn the house down; please make sure you establish an appropriate policy on the use of matches.
The analogy is deliberately exaggerated. The asymmetry it exposes is much less so.
The more a vendor makes technical understanding unnecessary for creating a system, the harder it becomes to argue that managing the consequences remains almost entirely the customer’s responsibility.
The shared-responsibility model, now familiar from cloud computing, may therefore need to extend to a new layer: shared responsibility for the creation of digital capabilities.
What If the Real Barrier Belongs at the Production Boundary?
A personal lab should remain free. An individual productivity application does not require an architecture committee. Artificially restoring the difficulty of building things would be a spectacular step backwards.
But the situation changes when something writes to an ERP, processes sensitive data, crosses organisational boundaries, manipulates privileged identities or becomes essential to the work of hundreds of people.
At that point, whether it was written in Python, assembled in Power Apps or described to an agent in natural language is largely irrelevant.
Its capabilities and the consequences of failure should determine the level of control.
We could therefore preserve almost complete freedom to experiment, while progressively introducing requirements as the blast radius grows: a governed environment, an identified owner, logging, review by a qualified person, segregation of duties and, for the most critical systems, formal approval before publication.
This is not a licence to code.
It is simply recognising a distinction that we already apply to many other technologies: the right to experiment is not the right to expose others to the consequences of that experiment.
Expertise May Never Have Been Merely a Means of Production
For years, you had to know how to build in order to build.
Artificial intelligence is breaking that relationship. It can remove some of the thousands of hours once required to produce a result.
But experience did more than make that result possible. It also helped someone recognise a fragile architecture, a dangerous dependency, an excessive privilege or the apparently insignificant anomaly that tells an experienced practitioner that something is probably wrong.
AI can reduce the hours required to produce.
It does not erase the hours that were required to learn how to understand the consequences.
We have long regarded technical expertise as a barrier that prevented people from creating. We may now be discovering that, sometimes, it was also a barrier that prevented people from creating just anything.
The democratisation of digital creation is probably desirable. There is little reason to artificially rebuild the obstacles that low-code and artificial intelligence are finally removing.
But neither are we obliged to remove, along with them, the boundary between experimentation and production.
Regulators are beginning to apply this reasoning to digital products placed on the market. Some large organisations already apply it to citizen development. The technology vendors themselves possess many of the mechanisms required to govern what they simultaneously encourage us to create.
Perhaps we simply need to draw the logical conclusion:
the lower the technical barrier to creation becomes, the more important the barrier protecting others from the consequences of that creation becomes.
Electricity eventually learned to make that distinction.
As our digital systems become simultaneously more indispensable, more complex and easier to modify, perhaps it is time for IT to do the same.
To discuss this: get in touch.