Once a team has learned to build with agents, a second temptation follows: build AI into everything. If an agent can write the code, perhaps a model should make the decisions too. Perhaps every rule should become a prompt, every workflow an agent, every form an assistant.
That conclusion confuses two different things. An AI-native delivery loop uses AI to build software well. Whether the software should use AI at a given step is a separate design question, and the honest answer is usually "not here". A rule that can be written down and tested exactly is better as code: cheaper, faster, predictable, auditable and free of drift. Ordinary automation handles structured, repetitive work perfectly well. AI earns its place where input is variable and judgement is cheap to get wrong, or where it prepares material for a person who decides.
Our position, to close this series: AI-native does not mean AI everywhere. It means using AI deliberately, in delivery and in the product, where it beats the alternatives, and nowhere else.
Seapoint Payments is fictional, and its systems and figures are illustrative. By now Seapoint's onboarding squad builds with agents inside a harness, from a living specification, with acceptance decided on evidence and production signals routed back each week. This part looks at the onboarding product itself, and where AI ended up inside it.
Four questions, in order
Seapoint's architect used a short decision sequence for every step of the onboarding flow.
Can the rule be written down and tested exactly? Hold payouts on a partial match unless the sole-proprietor exception applies. Release after a person confirms the account. Those are rules. They belong in code with tests, not in a prompt. A model asked to apply them might be right most of the time, which for a payout control is the same as being wrong.
Is the input structured and are the steps fixed? Sending status emails, creating a review task, calling the verification service, updating the onboarding status. Ordinary automation does this reliably and cheaply. Adding a model adds cost, latency and a new way to fail.
Does the step need accountable judgement or authority? Approving a high-risk merchant, releasing held funds, deciding that an exception is acceptable. A person decides. AI may help them prepare, for instance by summarising the evidence, but the decision is theirs. Part 5 covered why.
Is the input variable, unstructured language or documents? Here AI can genuinely help, with checks around it, a fallback when it fails and a person on the exceptions.
Where AI landed at Seapoint
After working through the flow, AI appeared in two places.
- Reading merchant documents. Company registration documents and bank letters arrive as scans and photos in many formats. A model extracts the registered name, registration number and directors' names into a structured record. The extraction is then checked deterministically against the official registry lookup and the verification result. Mismatches go to a person. The model never decides anything on its own; its output is a candidate that code and people confirm.
- Drafting explanations of risk flags. When an application is flagged, a model drafts a plain-language summary of why for the risk analyst, citing the specific checks that failed. The analyst reads it, decides and can edit what is sent to the merchant. The draft saves time. The decision stays human.
Everything else in onboarding, the rules, the routing, the status changes, the notifications and the payout controls, is ordinary code and automation, built quickly by agents and tested deterministically.
Two questions that place the work
A second lens helps when a step does not fall neatly into the sequence above: how variable is the input, and how costly is a wrong answer?
Where input is messy and mistakes are cheap, AI can do the work. Where input is messy and mistakes are expensive, AI proposes and a person or a rule confirms. Where input is predictable, ordinary automation or tested code wins regardless of cost, because there is nothing for a model to add except uncertainty.
Why "less AI" is often the stronger design
Cost. Every model call costs money and, for organisations budgeting in rand for services priced in dollars, carries currency exposure. A rule in code costs effectively nothing per execution. Our Why Do We Keep Paying for AI? series covers the commercial side in depth.
Predictability. Deterministic code gives the same answer every time. That matters for audit, for testing, and for explaining a decision to a customer or regulator.
Latency. A rule evaluates in microseconds. A model call takes hundreds of milliseconds to seconds.
Change control. A rule changes when someone changes the code, under review. A model's behaviour can change when the provider updates it.
Testability. Exact rules can be tested exhaustively at their boundaries. Model behaviour needs evaluation datasets and statistical judgement, which are worth building only where the model is earning its place.
None of this is an argument against AI. It is an argument for spending AI where it creates value that code cannot. Our article on when to use Jev, and when not to makes a similar point about typed decision models: knowing when not to use a tool is part of using it well.
The series in one page
| Part | Argument |
|---|---|
| 1 | Faster coding does not make delivery faster; redesigning the loop does |
| 2 | The specification is now the control surface and needs versioning, owners and change propagation |
| 3 | One owned, living specification beats a chain of restated documents |
| 4 | The harness is a control system: layers, cheapest control first, three dimensions, a steering loop |
| 5 | Execution can be delegated to agents; acceptance authority cannot |
| 6 | AI code review is a filter that improves what reaches people, not a sign-off |
| 7 | Production behaviour has to change the artefacts agents read |
| 8 | AI-native delivery does not mean AI in every step of the product |
Where to start
If you take one thing from this series into Monday, make it this: pick one product team and one real change, and run it through the whole loop. Write the intent first. Put the specification where agents read it. Harness the agent. Separate merging from acceptance. Route what production tells you back to the artefact that caused it. And when someone proposes putting a model into the product, work through the four questions before agreeing.
All parts are on the series page. Start again from Part 1, AI-native delivery is not faster delivery.
How CloudNala can help
We help teams decide where AI belongs in a product and where it does not: walking through a real workflow step by step, separating rules that should be code from steps where AI adds value, and designing the checks, fallbacks and human decisions around the places AI is used. We also help teams pilot the full AI-native delivery loop on one change, so they can judge it on their own evidence.
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.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za