Something genuinely new has happened. A finance manager who has never written a line of code can describe a reconciliation process to an AI tool on Friday and have something working by Sunday evening. Not a slide, not a mockup — a thing that runs, reads the spreadsheet, applies the rules and produces the answer. Six years ago that was a six-week project with a budget line.
The reaction to this splits along a tediously predictable line. One camp treats it as the end of software engineering as a profession. The other camp — usually the engineers — looks at the output, finds no error handling, no tests and a database password sitting in plain text, and concludes that nothing important has changed.
Both are wrong, and in the same way. They are both arguing about whether the weekend app counts as real software. It does. That was never the interesting question.
The interesting question is what happens in month four, when three other people have started using it, when someone in the finance team has stopped doing the manual check because the tool does it now, and when the number it produces goes into a report that goes to a board. Nothing about the software changed on the day that happened. Everything about what it owes the business did.
The trust burden belongs to the dependency, not the code
This is the part that gets missed, so it is worth stating plainly: production readiness is not a property of a codebase. It is a property of a relationship between a system and the people who rely on it.
Exactly the same fifty lines of code can be entirely appropriate in one context and reckless in another. A script that pulls a report for one analyst who eyeballs the output every morning needs almost nothing. That same script, wired into a customer-facing process where nobody eyeballs anything, needs authentication, logging, error handling, an owner, a rollback path and someone who can explain its behaviour to a regulator.
The code did not become worse. The stakes moved.
This reframing matters because it removes the insult from the conversation. When an engineer says a citizen-built tool is "not production ready", what they usually mean — and often fail to say — is not you built this badly. It is the business has started leaning on this, and the things that make leaning safe have not been built yet. Those are entirely different statements, and only one of them makes people want to keep talking to you.
Three altitudes, three sets of questions
It helps to be concrete about the levels, because most organisations have all three running at once and treat them identically — either waving everything through or subjecting a personal spreadsheet macro to an architecture review board.
The middle column is where most of the difficulty actually lives. Weekend apps are obvious. Enterprise systems are obvious. The department tool — the thing three teams now use, that nobody formally owns, that has become load-bearing without anyone deciding it should — is the one that surprises people, and it is where most of the unpleasant discoveries happen.
What the demo cannot tell you
Take a concrete case. A manager builds a leave-request assistant over a weekend. Staff message it, it answers questions about policy, it captures requests. In the demo, it is impressive. It answers correctly, it is polite, it saves the HR team a genuinely tedious job.
Now the business wants to make it the official route for leave requests. The questions that arrive have almost nothing to do with whether it works:
- Who can see whose requests? Can a team member ask about a colleague's leave balance and get an answer?
- Where does the conversation history live, and for how long?
- If it tells someone they have fourteen days when they have four, who is accountable for that?
- Is the approval recorded anywhere HR can produce it eighteen months later, in a dispute?
- Does it write to the actual HR system, or does someone re-key it — and if the re-keying is skipped, how would anyone know?
- What happens when it is down on the last day of the leave cycle?
- Who fixes it when the manager who built it moves to another company?
Every one of those is answerable. None of them are hard, individually. But answering all of them is roughly six times the work of building the thing that impressed everyone in the demo — and that ratio is the single most important number in this entire conversation. It has not changed. AI made the numerator much cheaper and left the denominator almost exactly where it was.
Why this gets harder, not easier, as AI improves
The obvious response is that models keep improving, so eventually they will handle the production concerns too. Some of that is true. Models are already reasonable at generating error handling, writing tests and flagging obvious security problems when asked.
But look again at the list above. "Who is accountable when it gives the wrong answer" is not a code-generation problem. Neither is "how long may we keep this data", or "does this fit the systems we already run", or "is this workflow the one we actually want to make permanent". These are decisions about risk, ownership and organisational intent. They require somebody with authority to be wrong.
Meanwhile the volume of software goes up. When five people in a department can each produce three working tools a quarter, the organisation is not dealing with one governance question a year. It is dealing with sixty. The per-item cost of judgement has not fallen, and the number of items has multiplied.
That is the actual shape of the problem, and it is why this series exists. Not because AI-built software is bad, but because there is suddenly a great deal more software arriving at the door marked can we depend on this? — and the people who answer that question are the same people, in the same numbers, with the same hours in the day.
Where this series goes
The rest of the series works through the model in the title. Citizens build: why the people inside a workflow are the right people to describe it, and what their prototypes are actually worth. Agents execute: what AI agents genuinely do in delivery, and where they stop. Experts govern: why engineering judgement gets more valuable rather than less. Then the operating model that puts the three together, the anti-pattern that ruins it, a practical trust checklist, the platform work that makes it scale, and what all of it means for public-sector service delivery.
The through-line is simple enough to state in one sentence, and we will keep returning to it: AI lowered the cost of creating software, and left the cost of trusting it exactly where it was.
How CloudNala can help
We spend a lot of our time on the promotion question — an organisation has something built quickly that now matters, and needs to know what it would take to depend on it safely. That work is usually less dramatic than people expect: classify the risk, name an owner, work out what data is really moving, decide which controls are proportionate, and be honest about which tools should simply be left where they are. The goal is never to disqualify what people have built. It is to make the dependency deliberate rather than accidental.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za