In CASE 2.0: The Promise and the Peril of Democratised Development I argued that the discipline gap opened up by AI coding tools is structural, and I closed by saying the responsibility sits with the person holding the keyboard. That was only half the answer. The other half sits with the organisation.
Because the person holding the keyboard is no longer a developer. Take an example. A field services coordinator builds a tool for scoping and quoting on site. It screens the job for eligibility, walks through equipment selection against a product catalogue, produces a quote with pricing and customer details, and generates a formatted summary to paste into the job management system. It is a single HTML file with the business rules generated by AI. No server, no login, no network. Open it in a browser in someone's driveway and it just works.
The problem is what happens next. In most organisations there is no route to turn something like that into a supported system. The example is illustrative, but the pattern is not. It is running right now in finance, operations, clinical services, and field delivery, in organisations of every size.
What Has Actually Changed
For thirty years the constraint on digital innovation inside a business was supply. Someone had an idea, wrote a business case, joined a queue, and waited for a project. Most ideas died in the queue, and the ones that survived arrived eighteen months later solving a problem that had moved on.
That constraint is gone. Anyone with deep domain knowledge and a few evenings can now produce a working application. It will not be production ready, but it will work, and it will often fit the job better than the system it replaces.
The domain knowledge is the part that matters. The hardest problem in software has never been writing the code. It is understanding the work well enough to know what to build, and that understanding sits with the people doing the job, not with the people who were previously the only ones able to build. What those people lacked was execution. AI gave them execution. It cannot give a development team twenty years of doing the work.
So the queue moved. It used to be a queue to get something built. Now it is a queue to get it live.
The Gap Between Working and Production Ready
Something that works is not the same as something an organisation can run. The gap is not in the code, which is the part AI now handles well. It is everything around the code.
Identity and access, so the right people see the right records. Data residency and backup, so the information sits somewhere lawful and survives a bad day. Secrets management, so credentials are not sitting in a config file. Logging and audit, so you can answer what happened and when. Privacy assessment, if there is personal information involved, which is more often than people expect. A support model, so there is someone to call when it breaks at 4pm on a Friday. A lifecycle, so it gets patched, and eventually retired.
Innovators are not ignoring this. In my experience they are acutely aware that they do not know what they do not know, and they want to do the right thing. They just have no idea who to ask, and no confidence that asking will produce anything other than a no.
Look Closer and It Gets Harder
Start with what the innovator got right, because this is the part the shadow IT narrative always misses. The tool holds nothing after the session ends. No downloads, no cookies, no telemetry, no data leaving the device. That is a better privacy posture than plenty of procured systems I have reviewed, and it was a deliberate choice by someone who thought carefully about handling customer information.
Now look at what that same choice costs. Because nothing is retained and nothing is transmitted, there is no record of what was quoted, on what basis, or by which version of the rules. The design that protects privacy also removes the audit trail. Those two requirements are in genuine tension, and resolving them is an architecture decision. It is not the kind of thing you would expect a coordinator to work through alone, and it does not have an obvious right answer.
Then there is distribution. The tool spreads by copy. Someone emails it, someone else saves it to a shared drive, and within a few months there are several builds in circulation with no way to tell which is which. When a product is discontinued or a price changes, there is no update path and no recall path. Every stale copy in the field keeps quoting last year's catalogue.
The catalogue is the other structural problem. Product options, selection logic, and pricing are written into the HTML itself, repeated in several places rather than held once as data. So changing one product means editing the same information in multiple spots, with nothing to verify it was done consistently. Configuration that changes monthly has ended up baked into code that changes rarely.
Nothing integrates either. The output gets copied and pasted into the system of record, which means the tool is invisible to every other system in the organisation and every paste is a chance to get it wrong.
And then the part that makes it serious, which will look different depending on your sector. Here it is a commitment to a customer, made on the basis of rules nobody has reviewed, with no way to reconstruct what the tool said or why. Put the same design in a clinical setting, where the output is a recommendation for a patient and the justification text is authored by the tool, and you are one adverse event away from a question you cannot answer. In a regulated setting there is a further question worth asking early rather than after rollout: does a tool that recommends and justifies a course of action fall inside a regulatory boundary, and what does that mean for how it is governed?
None of this is exotic. It is ordinary configuration management, integration design, and assurance. But it is a completely different conversation from the one the innovator has had so far, and there is no reasonable expectation they would arrive at it unassisted. What they built solves a real problem. What they need is someone to walk it the rest of the way.
How Organisations Get This Wrong
The usual answer is no. Policy prohibits business-built applications, so the innovation continues anyway, in a personal cloud account, on a personal card, outside any register. The organisation has not stopped the risk. It has only stopped being able to see it.
The rarer answer is yes without a pathway, and it normally happens because someone senior enough pushed it through. IT accepts the tool, inherits a codebase with no documentation and no tests, and carries it indefinitely. That experience is exactly what hardens the no for everyone who comes after.
Then there is the version of this that people notice most. Boards are pushing AI initiatives hard at the moment, and those arrive with sponsorship, budget, and a tolerance for unknowns that would be unthinkable if the same idea came from a coordinator with a working prototype. So the tool built by the person doing the work gets refused, while a pilot carrying materially the same questions about data, assurance, and support gets fast-tracked, sometimes in the same quarter. People notice. What they take from it is that the rule depends on who is asking rather than on the risk. That is the point at which the policy stops working, because nobody follows a rule they have watched other people skip.
All of this comes from the same root cause. There is no defined route from prototype to production, so every request becomes an argument about principle, or a question of who is asking, rather than a process with steps.
Build the Pathway
The vocabulary for this is fragmented. Gartner talks about fusion teams and business technologists, the low-code world talks about citizen development and centres of excellence, platform engineering talks about paved roads and golden paths. My preferred term is plainer, and it is the one clients understand immediately: a Path to Production.
There is a reason the naming matters. IT calls all of this governance, and in most businesses that word has a bad name. It means a committee, a delay, and a decision made by people who cannot see the work they are making it about.
That bad name is partly deserved, though not because the people doing governance lack skill. It is a design problem. Controls written once for everything, then applied at a distance from the work, will often make no sense to the person doing that work, and people route around controls that make no sense to them. A pathway is a different proposition. It is not a gate someone stands at, it is a route someone walks you down, and the checks happen along the way rather than at the end.
A Path to Production is a published, funded route that takes a business-built tool from working prototype to supported system. It has five parts.
A front door. One place to raise it, one form, one owner, and a commitment to respond within days rather than quarters. Most of what arrives will not need a project. It needs a decision.
Triage and sizing. Not everything gets the same treatment. A tool used by one team, with no personal information, that would be an inconvenience rather than a crisis if it stopped, does not need the same rigour as something touching customer or client records. We use T-shirt sizing on intake for exactly this reason: it determines the architecture pathway and the governance treatment in a single step, and it means the small things move fast so the large things get proper attention.
A sandbox with real guardrails. A place innovators are actively encouraged to build, with synthetic data, standard patterns, and preconfigured identity and hosting. The guardrails are there so that what gets built is closer to production ready by default, which shortens the last mile considerably.
A landing zone and an uplift step. Somewhere for the tool to run properly, and a defined piece of work to get it there: security review, privacy assessment where relevant, access model, backup, logging, documentation, handover. This is usually a few weeks of specialist effort, not a program. But it has to be funded and staffed, or the pathway is theory.
A support and retirement model. Who owns it, who fixes it, what the service expectation is, and what happens when the person who built it leaves. Agree this before go-live, not after.
Funding Is the Part That Usually Kills It
Every organisation I have worked with that has failed at this has failed on funding, not on capability.
The innovation arrives in March. The capital cycle closed in November. The uplift needs twenty thousand dollars, a couple of weeks of an architect, and some cloud engineering support to get it hosted, deployed, and reviewed properly. There is no line item for it, so it waits twelve months and dies.
The fix is not complicated. Set aside a small annual pool for exactly this purpose, with a low approval threshold and a fast decision, delegated to the digital steering committee or equivalent. Fund the pathway, not each idea. Measure it on how many tools reach production and what they saved, so you have the numbers when the pool comes up for renewal.
Be clear about what declining to fund it actually buys you. It does not stop the tool being used. It only stops it being made safe. The tool goes into service regardless, because it solves a problem someone has today and the alternative is going back to the old manual process. All the funding decision settles is whether it goes into service assessed or unassessed.
What This Asks of IT
This is a genuine shift, and it is worth being honest that it is uncomfortable. IT moves from being the builder to being the platform and the assurance. Less writing the application, more providing the paved road, reviewing what comes down it, and running it once it lands.
That is not a diminished role. It is a higher-leverage one. An IT function that enables fifty business-built tools a year, safely, delivers more value than one that delivers three projects. But it has to be resourced for it, which means naming the function in the operating model, writing it into position descriptions, and counting it in how performance is measured. If IT is still measured on project delivery alone, this becomes work people do on top of their real job, and the pathway will exist on paper only.
Be realistic about the queue this is joining. There is the planned portfolio, which is committed and funded. There is the unplanned work that turns up anyway: the outage, the audit finding, the vendor forcing an upgrade, the acquisition nobody saw coming. That second queue is what the team is actually spending its week on, and it always wins, because it is urgent. Business-built tools sit behind both. A team scrambling to absorb unplanned work will never reach a third queue no matter how good the intent, which is why the capacity for this has to be set aside deliberately.
Where to Start
Before designing any of this, find out how much of it you already have. You cannot size a pathway until you know what is coming down it, and in my experience the discovery is what makes the case anyway.
Ask team leaders directly what their people are using that IT did not give them, and make it explicit that nobody is in trouble for answering. Without that, you get silence and a false sense of security. With it, most organisations find considerably more than leadership expected.
Then put a simple register in place so you can see it. Pick one tool that is already delivering value and walk it through to production properly, treating that as the pilot for the pathway rather than a one-off. Write down what you learned and publish it as the route. Fund it modestly and see what comes.
The organisations that get this right over the next two years will have a compounding advantage, because they will be capturing improvement ideas from the people closest to the work and turning them into supported systems in weeks. The ones that get it wrong get two outcomes. Some of the innovation goes underground and keeps running unregistered, unsupported, and unassessed, until one of them turns into a breach notification. The rest simply stops, because people who are told no twice do not come back a third time, and the improvement they would have made is never built and never missed.
The capability is already in the building. All you are deciding is whether it reaches production, leaks out the side, or quietly stops.
The piece I promised at the end of CASE 2.0, on structuring a CLAUDE.md as a governance instrument, is still coming. This one had to go first. The guardrails an individual puts around their own work only matter if the organisation has somewhere for that work to go.
Shaun Crouch is the founder of Pragmatix, a Brisbane-based digital business consultancy. His career spans programming, solution architecture, and enterprise architecture across healthcare, government, and financial services. Pragmatix helps organisations build the governance and delivery pathways that let business-led innovation reach production safely.
Pragmatic Agentic AI, Shaun's free eBook on building autonomous AI systems pragmatically, is available at pragmatix.com.au/agentic-ai. The Pragmatix Advisory Portal at portal.pragmatix.com.au provides access to expert AI advisors for governance, cyber security, and solution architecture.