The barrier to building software has collapsed. The barrier to owning it has not moved an inch.
Every operations and supply chain leader is now being asked the same question: everyone can build - so what do we do about it? I recently worked through that question in practice - designing an AI and automation enablement model for a global operations organisation. What follows is the initial model that was deployed, what survived the room, and why I am convinced that segmentation - not enthusiasm, not lockdown - is the only position that worked best in my supply chain context.
I. The shift already happened - but results are mixed
Gartner predicted citizen developers would outnumber professional developers four to one at large enterprises. The target year drifted - the outcome did not. Forrester counts roughly 16.2 million citizen developers in 2026, growing 38% a year, against 28.7 million professionals. The low-code market sits at $44.5bn this year. And AI poured fuel on all of it: 84% of developers use or plan to use AI tools, and "vibe coding" was Collins Dictionary's Word of the Year.
But there is also another angle to such optimism, have a look at this:
- The same survey of 49,000 developers: 77% say vibe coding plays no part in their professional work.
- METR's randomised trial: experienced developers were 19% slower with AI assistance - while believing they were 20% faster.
- GitClear, across 623 million code changes: copy/paste climbing to 15.7% of all changes, refactoring down roughly 70%.
The tools converged on everyone. The builders did not converge on anything.
II. The incident record is an operating-model record
38 million records exposed through default permissions on citizen-built portals. 16,000 COVID cases dropped because a legacy spreadsheet format ran out at row 65,536. A production database deleted by an AI agent during an explicit code freeze - which then fabricated 4,000 fake users to cover the gap. Roughly 170 AI-built apps shipped with row-level security missing or inverted.
Not one of these is a model failure. Every one is an operating model failure - permissions nobody reviewed, formats nobody questioned, agents nobody separated from production, apps nobody owned.
A demand planner automating her own weekly report and a team shipping a tool that writes to customer data are not the same case. Same tools now. Different builders. Different blast radius.
III. What I deployed instead of a programme
The model draws on my recent experience with a global operations organisation - complex supply chain, 100+ supply chain team members, mixed operating model of centralised and decentralised decision-making, global business services across several regions, every time zone across three continents.
When the question landed - how do we activate an AI and automation culture across supply chain? - the first thing I refused to do was launch a single programme for everyone.
What I launched is an intersection.
Top-down brings sponsorship, sanctioned platforms, funding and light governance. Bottom-up brings frontline ideas, experiments and volunteer champions. Capability is delivered only where the two meet. My hypothesis was that in case you run top-down alone - you will get shelfware with a change-management deck. Run bottom-up alone and you get shadow IT with enthusiasm.
Three pillars carry the bottom-up half:
- A forum, not calls. Asynchronous, seeded with real internal wins, searchable. Calls clash across time zones. A library of recorded demos does not.
- A sandbox. Try safely before anything scales - and experiments never touch production data. By construction, not by policy. That single control would have prevented the most publicised AI-agent incident of the past year.
- An organic community. Champions opt in. Volunteers are believers. Assignees are administrators.
Four roles keep it running: champions surface ideas and run first pilots; sponsors unblock, fund and give air-cover; technical resources build what gets prioritised; a small cross-entity forum gates. The gate enables - it does not approve everything.
IV. One gate, four steps - and guardrails tiered by blast radius
- Submit: any colleague, anywhere, two minutes, no template.
- Triage: a reuse-versus-build decision - adopt what already exists, inside and outside the group, before building anything new.
- Pilot: sandbox, champion-led, weeks not months - with the baseline captured before the pilot starts.
- Scale: into the use-case library, reused across entities instead of reinvented in each one.
And underneath it all, the tiering:
- Experimental - personal automations and prototypes. Free rein in the sandbox, disposable by design.
- Departmental - team tools with real data. Sanctioned platforms, named owners, review dates.
- Critical - anything touching customer data, financial reporting or live execution. Professional co-ownership and security review. No exceptions.
One more commitment, and it was the one the room tested hardest: measure, do not estimate. No headline impact is claimed until a pilot produces a defensible figure. The fastest way to kill an automation culture is a benefits number the leadership team dismantles in one meeting.
V. AI-assisted consolidation: ideas do not consolidate themselves
Every community of practice has the same quiet failure mode. Ideas stay local, unstructured and unreplicated. One entity solves a problem elegantly; another rebuilds the same solution a year later, worse. The average enterprise runs 897 applications and integrates 29% of them - sprawl is what happens when creation outruns consolidation.
So the model carries an AI layer: a collaboration agent doing the consolidation work nobody ever finds time for.
- Capture: unfiltered ideas, in whatever shape they arrive.
- Develop: the agent structures them - problem, approach, effort, owner.
- Standardise: auto-documentation into one format every entity can read.
- Repository: a central, searchable hub - the use-case library lives here.
- Scale: a replication engine that matches documented wins against sibling processes elsewhere.
Note what the agent does not do. It does not generate the ideas - people do, where the work happens. The agent removes the friction between an idea existing and an idea being reusable. That is the whole job.
And it is the part I would defend hardest. The model behind the agent is a commodity - swap it next quarter and nothing changes. The capture-structure-match-replicate pipeline around it, filled with your processes and your wins, is the asset that compounds.
Creation is now cheap. Consolidation is the scarce skill - and it is the one worth automating first.
VI. The change management framework I focused on
Fifteen-plus years of supply chain transformations across consumer goods, pharma, commodities and industrial manufacturing taught me one picture that rarely failed for initiatives like this: every change runs as two pyramids at once.
Mandate travels down and thins with every layer - what reaches the frontline without energy behind it is compliance: ticked boxes, shelfware, quiet resistance.
Energy travels up and thins with every level - what reaches leadership without sponsorship becomes workarounds: shadow IT, local heroics, wins nobody replicates.
Adoption lives only in the overlap. The intersection model above is not a programme design; it is a machine for widening that overlap.
There is a name for why the overlap is the only place change survives, and I first met it during my PhD research when reading works by W. Ross Ashby's, especially his Law of Requisite Variety.
Only variety can absorb variety - a regulator survives only if it can match the range of states of the system it regulates. A single change policy for every builder, every entity and every time zone is a one-state regulator pointed at a thousand-state system.
Cybernetics predicted the failure modes in 1956: the mandate pyramid over-constrains what it cannot distinguish, the energy pyramid routes around what it cannot influence. Segmentation is not a governance preference. It is the minimum variety the system demands.
Culture is not rolled out. It is grown at the overlap - and this overlap is engineered.
The simplification
In my opinion you often do not need a citizen developer strategy. You need a sorting question - and the discipline to answer it.
Who is building. What does it touch. Who owns it. Three answers, three tiers, one gate. The rest is culture - and culture you grow, you do not roll it out.
The spreadsheet taught operations teams to build forty years ago. It also taught us what ungoverned building costs - one row limit at a time. This wave is bigger. So is the upside, if you sort before you scale.