The word "agent" has been applied to so many things that it has almost stopped carrying information. In a software delivery context it means something reasonably specific, and the distinction is worth being precise about: a chatbot answers, an agent acts.
Ask a chatbot how to add a contact form to a website and it explains how. Ask an agent and it finds the frontend component, adds the form, wires up validation, creates the API endpoint, writes tests, runs them, notices two are failing, fixes the cause, updates the documentation and opens a pull request. Then it stops and waits.
That last sentence is the entire subject of this article, and it tends to get lost in the excitement about the ones before it.
What is genuinely different
It is worth being honest about the scale of the change, because both the hype and the backlash obscure it.
Agents are now reliably good at a category of work that used to consume a large fraction of a developer's week: reading unfamiliar code to work out where something lives, making a mechanical change consistently across many files, writing the test that should obviously exist, producing the documentation nobody wanted to write, and translating between formats. This is not trivial work and it is not low-value work. It is simply work where the correct answer is largely determined by the context, and determining answers from context is what these systems do.
What follows from that is a real change in throughput. A team that previously produced a certain volume of change per sprint can produce considerably more. The interesting consequences are all downstream of that fact.
Speed moves the bottleneck; it does not remove it
Here is the thing that catches organisations out. If your delivery process was already the limiting factor — a two-week review queue, a manual release process, an environment that takes three days to provision — then making the code arrive faster does approximately nothing for the business. You have simply built a larger queue.
Worse, a larger queue degrades review quality. A reviewer who receives four pull requests a week reads them. A reviewer who receives twenty skims them, and skimming is how plausible-looking, subtly wrong changes get approved. Agent-generated code is especially good at looking plausible, because producing plausible text is the underlying capability.
So the first honest question about agents in delivery is not "which tool should we use". It is: if we doubled the volume of change arriving at review tomorrow, what would break first? Almost every team can answer that immediately, and almost nobody likes the answer.
Where the agent stops
The diagram above splits the pipeline in two for a reason. The top row is where agents operate and where they are getting rapidly better. The bottom row is where the organisation decides whether a change is allowed to affect a customer, and it is not accelerating at anything like the same rate.
That boundary — the agent produces a proposal, a person and a set of automated gates decide its fate — is the single most important design decision in agent-assisted delivery. Not because agents are untrustworthy in some mystical sense, but for the same reason no engineer merges their own change to a payment system without a second pair of eyes. The reviewer is not there because the author is incompetent. They are there because authorship and approval being the same act is how bad things reach production.
The right-hand column is not a temporary list waiting for better models. Every item on it is somebody accepting a consequence, and accepting a consequence requires being answerable for it. An agent can produce an excellent migration script. It cannot be the entity that accepted the risk of running that script against real customer records, because there is nothing there to hold responsible afterwards.
The guardrails have to be in the pipeline
The most common mistake we see is guardrails expressed as instructions. The prompt says: never touch the production configuration, always use the shared logging library, do not add new dependencies without approval.
This works most of the time, which is the problem. A prompt instruction is a strong suggestion to a probabilistic system. It is not a control. The equivalent question for any team adopting agents is: if the model ignored this instruction entirely, what would stop it?
Real controls look like this. The agent runs with credentials scoped to a single repository, so it cannot touch production configuration. New dependencies fail a policy check in CI, so an unapproved one never merges regardless of what the agent believed. Secrets live somewhere the agent's execution environment cannot reach. The branch protection rule requires a human approval, enforced by the platform, not by good intentions.
This is not new thinking. It is ordinary least-privilege engineering, applied to a new kind of actor. Teams that already have a disciplined pipeline find agent adoption relatively straightforward, because the constraints are already there and the agent simply becomes another contributor subject to them. Teams without one discover that they have been relying on everyone being sensible — which held while the contributors were all humans who could be spoken to.
We have written elsewhere about the harness a coding agent needs and about why specification matters more, not less, when generation is cheap.
What to actually do with this
A reasonable adoption path, in order:
Fix the review and release path first. If it is slow now, agents make it worse. This is unglamorous and it is the highest-leverage thing on the list.
Give the agent a narrow, well-fenced repository to work in. Read-only where possible to begin with. Watch what it does for a few weeks before widening anything.
Make the automated gates real. Tests that actually fail the build, dependency and secret scanning, policy checks on infrastructure changes. These are what let you accept a higher volume of change without proportionally more human reading.
Keep the human approval where the consequence is. Not on every change — on the changes that touch data, money, identity or anything customer-facing. Reviewer attention is now your scarcest resource; spend it where being wrong is expensive.
Log what the agent did and what it cost. Both for the incident you will eventually investigate, and because agent spend is genuinely easy to lose track of.
How CloudNala can help
Most of our agent-delivery work turns out to be pipeline work. Teams arrive wanting to introduce coding agents and leave having also fixed the review path, the environment provisioning and the policy checks — because those were the actual constraint, and the agent simply made it visible. We help design where the agent's authority ends, what the automated gates have to catch, and which approvals stay human, so that a step change in output volume becomes a step change in delivered value rather than a longer queue.
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