The question is not “should we let people build things”. They already are, and stopping them means losing the good part. The question is what the company requires before it relies on what gets built.
It starts as a good story. Someone in operations, or sales, or finance, who has never written software, sits down with an AI coding tool over a weekend and builds the thing the team has wanted for years. A tracker. A quoting tool. A portal. It works. Within a month the team depends on it.
Then the questions start, usually from outside. A customer asks where their data is held. The accountant asks why a total is off. The builder goes on holiday and something breaks. Nobody else knows where it runs, what it holds, or how to fix it.
What the tools did and did not do
The AI tool made the application. It did not make the hosting decision, choose who has the keys, set up a backup, test the refund case, review who can see what, watch the figures, or write the handover. Those are not coding tasks. They are the infrastructure around the app, and they are the part that decides whether the company has an asset or a liability.
An experienced engineer does that homework by habit. An inexperienced builder does not know it exists, and the tool will not tell them.
What to require
The same things the company would require of a supplier:
- Where does it run, and who can get in?
- What happens to the data, and has a restore been tried?
- Has someone other than the builder tested it against what the business asked for?
- Has anyone reviewed it for security before it touched real data?
- Is anything watching it?
- Could someone else keep it running from written material?
Those six things are a week or two of part-time work for a capable builder. They are also the difference between a prototype and a system. Until they are done, the thing is a prototype, however much the team likes it, and it should be treated as one.
How to say yes
Say yes with a condition. The builder does the homework, using a checklist the company has agreed on, and shows the results before the app is relied on. Someone with more experience, inside or outside the company, spends half a day reviewing the security answers and the tests. The company owns the accounts. A second person can make a change.
That is not bureaucracy. It is the cheapest insurance the company will buy this year, and it turns the enthusiastic builder into someone who now knows how systems are kept running, which is worth more to the company than the app.
The checklist is here: The infrastructure around the app. It is written for the builder and the leader to use together.