When a new tool lands in one part of a system, the first place to look for its effect is not where it landed. It is the next stage downstream.
Coding assistants arrived in the editor, so most organisations trained developers. That was a reasonable first move. It also produced an outcome that anyone who has studied flow in a delivery system could have predicted: code got faster, and the time it saved reappeared as queues in review, testing and release.
Kalahari Assurance is fictional, and its systems and figures are illustrative. Kalahari's group IT function, introduced in Part 1, measured one typical change before and after a year of coding assistant use. The coding stage shrank from about three and a half days to one. The whole change went from ten days to nine. Review grew from one and a half days to two and a half, and testing from two to two and a half.
Nobody had done anything wrong. Developers produced more change, faster, and the rest of the system had not been prepared to absorb it. Reviewers faced larger pull requests written in an unfamiliar style. Testers faced more change per sprint and agent-generated tests they did not trust. Release managers faced more deployments with the same approval process.
CloudNala's view is that AI training is a delivery-system intervention, and it should be designed like one.
Six stages, six different effects
A useful way to see this is to walk a change through the six stages it actually passes through, and ask at each one: what is an agent now producing here, and who has to judge it?
Intent. Product owners and analysts increasingly use models to draft problem statements, user stories and business cases. The risk is fluent intent that has not been tested against the people who will use the service. The skill needed is not prompting. It is knowing what a good outcome statement contains and spotting when a draft has invented one.
Specify. Agents draft acceptance criteria, data contracts and non-functional requirements. The anatomy of a useful specification does not change because a model wrote the first version, but the reviewer now has to check precision as well as intent. Part 3 covers this in depth.
Build. The stage most training already covers. Even here, the gap is usually not prompting. It is harness design: the repository instructions, checks and boundaries that let an agent work safely, described in Guides, Guards, Checks and Sensors.
Verify. Agents generate tests, and the tests pass. Kalahari's fraud-referral incident in Part 1 shows the trap: tests generated from the implementation verify the implementation, not the intent. Testers need to learn evaluation design, independent oracles and how to read an agent-written suite critically.
Release. Release notes, change records and risk assessments are now drafted by models. Approvers need to know which parts of that material are evidence and which are summary.
Operate. Runbooks and incident summaries are increasingly agent-assisted. Operations teams need to know when an agent's diagnosis can be trusted and when it must be confirmed.
What changes in the training design
Once you look at the whole path, three design changes follow.
Train pairs and teams, not individuals
A module on reviewing agent-written code is more useful when the reviewer and the author take it together, using one of their own recent pull requests. The skill being built is a conversation between two roles, so practise the conversation. Kalahari runs most modules as team sessions of four to eight people drawn from adjacent stages: an analyst and a tester on specifications, a developer and a reviewer on pull requests, a release manager and an operations lead on change records.
Train the stage that absorbs the change first
Kalahari's measurement made the priority obvious. Review and testing were where the queue built up, so those stages got capability investment before any further developer training. Reviewers learned to ask for smaller agent changes and to check the harness evidence before reading the diff. Testers learned to write a small set of intent-derived checks before the agent wrote its own tests. Within two quarters the review stage was back to about one and a half days.
This is ordinary flow thinking. The bottleneck is where the next unit of investment pays back most.
Change the system, not only the skill
Some stages cannot be fixed by training at all. If every agent-produced change still needs the same manual approval, release will always queue. The answer there is a policy decision: which changes, with which evidence, can be approved by a delegated owner or an automated gate? That decision belongs to the people who own release risk, and training them is how you make it possible for them to make it.
A practical sequence
Kalahari's head of engineering used a simple sequence that any organisation can repeat:
| Step | Question | Output |
|---|---|---|
| 1. Measure one typical change | Where does the elapsed time go, stage by stage? | A before and after time profile |
| 2. Find the absorbing stage | Where did the saving reappear as queue? | The next training priority |
| 3. Train the adjacent roles together | What judgement do they now need to share? | A team module tied to a real work product |
| 4. Change the policy that holds the queue | Which approval or handover is the constraint? | A decision by the risk owner |
| 5. Re-measure | Did the end-to-end time and the defect rate move? | Evidence for the next round |
The illustrative figures matter less than the habit. Measure the whole path, invest where the queue is, and judge the programme by end-to-end outcomes, not by how many developers attended.
Why this matters more in South Africa
There is a local reason to train the system rather than only the individual. Experienced engineers, architects and testers in South Africa are scarce and mobile. Many organisations lose senior people to remote work for offshore employers, to emigration or to better-funded competitors, often with a month's notice.
When capability lives in individuals, every resignation takes some of it away. The developer who worked out how to get reliable output from an agent on the claims codebase takes that knowledge with them unless it was written into the repository instructions, the harness checks and the team's review practice. The tester who learnt to distrust agent-generated suites takes that instinct with them unless it became a standard step in the test approach.
Training the delivery system turns individual discoveries into shared artefacts: standards, templates, checks and working agreements that remain when people leave. Kalahari now asks one question at the end of every team module: what did we learn today that should be written into the system, so that the next person does not have to learn it the same way? The answers feed the guild pipeline described in Part 6.
This does not make people less important. It makes the organisation less fragile when good people move on, which in this market they will.
The developer still matters
None of this means developer training was wasted. Developers using agents need depth in harness engineering, decomposition, testing and cost discipline, and the individual path remains the right way to build it. The point is narrower: developer skill is necessary and not sufficient. A team of excellent agent-assisted developers feeding an unchanged review, test and release process will produce more change, not better delivery.
Next: Part 3, What every role needs to know about specifications. All parts are on the series page.
How CloudNala can help
We help delivery leaders measure where time and defects actually sit across the path of a change, identify the stage that is absorbing the effect of AI tools, and design team-based training and policy changes for that stage first. The work produces a stage-by-stage profile, a prioritised capability plan and the decisions risk owners need to make.
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 Capability Programme or write to us at consult@cloudnala.co.za