A team gets access to coding agents. Within a month the engineers report that features which used to take a week of coding now take a day or two. Leadership hears the number and makes a reasonable inference: delivery should be three or four times faster. Six months later the release calendar looks almost the same, review queues are longer, and the team is arguing about whose job it is to read all the code the agents produced.
Nothing about that story means the agents failed. The coding step really did get faster. What failed was the assumption that coding was the step holding delivery back.
This series is about what an AI-native delivery lifecycle actually is. Our position is simple. AI-native delivery is not conventional delivery with faster code generation. It starts with business intent, turns intent into inspectable architecture and an executable specification, lets agents work inside defined controls, decides acceptance on evidence, and uses what happens in production to drive the next cycle. Compressing one step of the old process does none of that.
We follow one fictional organisation throughout. Seapoint Payments is fictional, and its systems and figures are illustrative. Seapoint is a Cape Town payments company with about 160 staff. It lets small online merchants accept card and instant EFT payments. Its merchant onboarding squad (a product owner, an analyst, a shared architect, four engineers, a tester and an operations lead) owns the journey from a merchant's application to their first payout. Median onboarding takes six working days, and the business wants two.
What happened when Seapoint's coding got faster
Seapoint's first agent-assisted change was to automate bank-account verification during onboarding: check that the account a merchant gives for payouts belongs to the registered business, and decide what happens when the answer is a full match, a partial match or no match.
Before agents, a change of that size took the squad around 28 working days from first conversation to settled release. With coding agents, the coding stage dropped from nine days to two. The total dropped to 23.
Look at where the days went. Clarifying what "partial match" should mean took as long as it always had, because it needed the risk lead, the product owner and the sponsor bank's requirements in one conversation. Agreeing the design took as long as it always had. Testing and review grew, because two days of agent output arrived as one large batch of change, and the tester and reviewers had to work out what it was trying to do before they could judge whether it did it.
This pattern is common enough to treat as a rule. When you compress one step of a pipeline, the constraint moves to the steps around it. The code is no longer the first hard problem; deciding precisely what the code should do, and proving that it does, now is.
Three things faster coding cannot repair
Weak intent
If nobody can state the outcome the change should produce, who it is for and how success will be measured, an agent will build something plausible. Plausible is the most expensive kind of wrong, because it survives a demo. Seapoint's original request said "automate bank verification". The real intent, found two weeks in, was "get legitimate merchants to their first payout within two days without increasing payout fraud". Those two statements lead to different designs.
Ambiguous requirements
A human engineer who meets an ambiguity usually asks. An agent usually resolves it, silently, with whatever seems most likely. The faster the agent, the more ambiguities get resolved per day without anyone noticing. Ambiguity used to cost a meeting. It now costs a batch of code built on a guess.
Unmanaged evidence and operations
A green build says the code compiles and the tests pass. It does not say the tests check the right thing, that the change behaves correctly in production, or that anyone has decided the residual risk is acceptable. If the evidence model was weak before agents, generating code faster simply produces unverified change faster.
What "AI-native" changes instead
An AI-native lifecycle does not discard the disciplines of good delivery. It reorders where effort goes and makes some artefacts carry more weight than they used to.
Intent becomes an engineering artefact. The outcome, users, constraints, assumptions and success measures are written down before tools or architecture are chosen, because they are what every later step is checked against. We covered how intent cascades from company purpose to a line of code in Intent architecture; here the point is that intent is no longer a slide. It is an input agents read.
Architecture becomes inspectable. Agents need boundaries they can follow and checks that fail when they do not. A diagram in a wiki is not a boundary. A dependency rule that fails the build is.
The specification becomes the control surface. A precise specification with testable acceptance criteria is what tells an agent what to change, what not to touch and when it is done. Anatomy of a useful specification covers the contents. Part 2 of this series covers the governance: versions, owners and what happens when the specification changes underneath work in progress.
Agents work inside a harness. Instructions, tools, permissions, tests and review gates surround the agent so that its speed turns into controlled delivery rather than uncontrolled change. Part 4 extends our earlier guides, guards, checks and sensors framework into a full control system.
Acceptance is decided on evidence. Not on the agent's report that it is done, and not on a reviewer's impression of a large diff. Parts 5 and 6 separate execution from the authority to accept it.
Production feeds the next cycle. What users do, what fails, what it costs and where operators intervene are inputs to the next round of intent and specification. Part 7 makes that concrete.
The loop, at Seapoint
Here is how the same verification change ran once Seapoint treated delivery as a loop rather than a pipeline with a faster middle.
| Step | Artefact | Who owns it | What changed from before |
|---|---|---|---|
| Intent | One page: outcome, users, constraints, success measures | Product owner | Written first, reviewed by risk before any design |
| Architecture | Context view plus two dependency rules | Architect | Rules enforced by a build check, not by memory |
| Specification | ONB-012 with six acceptance criteria | Analyst and tester | Versioned in the repository, read by agents directly |
| Execution | Agent tasks in a sandbox | Engineers | Smaller tasks, each tied to acceptance criteria |
| Evidence | Test results, check output, review notes | Tester | Collected per acceptance criterion, not per pull request |
| Acceptance | A named decision | Product owner and risk lead | Separate from merging code |
| Production | Funnel, tickets, latency, payout holds | Operations lead | Reviewed weekly and routed back to intent or spec |
The second change of similar size through this loop took 17 working days. The coding stage was still about two days. The saving came from the stages that had looked untouchable: clarification was faster because the intent page existed before the first meeting, and review was faster because the evidence arrived organised by acceptance criterion instead of as one large diff. The numbers are illustrative, but the shape is the point. The gain came from redesigning the loop, not from the model.
Where the new costs appear
It would be dishonest to present this as free. An AI-native loop moves cost as well as removing it.
Upfront writing goes up. Intent pages, specifications and acceptance criteria take real effort from people who were previously allowed to stay vague. This is often the change teams resist most, because it feels like bureaucracy until the first time it prevents a week of rework.
Review becomes the scarce resource. If agents can produce more change than people can responsibly review, the queue simply moves. The answer is not to review less carefully. It is to make changes smaller, make evidence better organised, and spend human attention only where machines cannot decide.
The harness needs an owner. Rules, checks, instructions and templates age. Someone has to maintain them, or they drift into the kind of contradictory guidance that makes agents worse, not better.
Technical debt accumulates differently. When code is cheap to produce it is also cheap to duplicate. Our piece on technology homeostasis covers why keeping a system fit now needs deliberate effort.
A quick test for your own programme
Ask five questions about your current use of coding agents.
- Can someone show the written intent and success measures for the last three agent-built changes?
- Do agents read the specification directly from a versioned source, or from whatever a person pasted into a chat?
- Which architecture rules would fail a build if an agent broke them?
- For the last release, can you show evidence per acceptance criterion and a named acceptance decision?
- What did production teach you last month, and which artefact changed as a result?
If most answers are "no" or "we would have to look", your organisation has adopted coding agents. It has not yet adopted an AI-native lifecycle. That is not a failure. It is the normal starting position, and the rest of this series is a route from there.
Where this series goes
This series deliberately builds on work we have already published rather than restating it. The Spec-Driven Development series covers specifications in depth. The Coding Agent Harness series covers the controls around agents. The Modernising the Software Delivery System series argues, in Don't migrate the tool, that the delivery system matters more than the tool. Here we join those pieces into one loop.
Part 2 starts with the artefact that now carries the most weight: the specification, and why it has become the main control surface for agent work.
Next: Part 2, The specification is the control surface. All parts are on the series page.
How CloudNala can help
We help delivery teams move from "we use coding agents" to an AI-native delivery loop. That usually starts with a short assessment of one product team: where intent, specifications, architecture rules, evidence and acceptance currently live, and which of them agents can actually read. From there we design a pilot on one real change, with the harness, evidence model and acceptance authority set up before the agents start, so the team can compare the loop against its existing process with its own numbers.
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