When Sabie Systems rolled out coding agents to its delivery teams, the first question in every team meeting was the same one, asked in different ways: is my job changing? Developers wanted to know whether they were now reviewers. Testers wanted to know whether test cases still needed them. Analysts had heard that agents could write user stories. Nobody got a straight answer, because the answers were all about tools.
Tool answers go out of date fast. The agent a team uses this quarter may not be the one it uses next year, and the boundary between what the tool can draft and what a person must do moves every few months. If a role is described by the tools it uses, the description is wrong almost as soon as it is written.
CloudNala's view is that an engineering role is defined by the outcome it is accountable for. AI changes which activities produce that outcome and adds new evidence the role must provide. It does not change who is accountable. Describe roles that way and the answer to "is my job changing?" becomes specific and stable.
Part 1 of this series decoded new AI titles into verbs and work products. This part applies the same reading to the roles you already have, which is where most AI work will actually happen.
Sabie Systems is fictional, and its systems and figures are illustrative. Sabie is a Pretoria software and data services company of about 140 people, roughly 60 of them in delivery teams. Each team has developers, a tester, a business analyst and a product owner, and shares architects and an operations group.
Tools change monthly. Outcomes change slowly.
Ask a developer what they are for and you will often hear "writing code". That was never quite true. A developer is accountable for a working, safe change to a system: one that does what was asked, does not break what was there, and can be maintained. Writing code was the main activity that produced that outcome. It was never the outcome itself.
Once the outcome is named, AI's effect becomes easier to describe. Some activities that used to produce the outcome can now be drafted by an agent. Some new activities are needed because the agent exists. The outcome, and the person accountable for it, stay where they were.
This is not just reassurance. It has practical consequences for role profiles, performance reviews and training budgets, because all of them should be written against the outcome rather than the activity.
Role by role: what stays, what moves, what is newly owed
The delivery-system training article walks a change through its stages and asks who judges each piece of agent output. This part looks at the same shift from the other side: what each role profile should now say. Here is how Sabie described its six existing delivery roles once it asked the question this way.
Developer. The outcome is a working, safe change. First drafts of code, boilerplate, tests for straightforward paths and refactors can now come from an agent. What is newly owed is the review and test record: evidence that the developer read and understood the change, checked it against the specification and ran it. A developer who merges agent output they cannot explain has not done the job, however fast it was.
Tester. The outcome is justified confidence that a release is safe. An agent can draft test cases from a specification in minutes. What is newly owed is evidence that the tests cover the risk, not just the happy path, and that failed tests keep their evidence. The Release on Evidence series covers that side in detail. A tester's judgement about where the risk lies becomes more valuable, not less, when test volume is cheap.
Architect. The outcome is sound decisions about structure, trade-offs and change. Agents can write option papers, compare approaches and draft diagrams. What is newly owed is the decision itself, with its trade-offs and reasons recorded, and a check that what was built still matches what was decided. An architect who forwards an agent's option paper without a recommendation has delegated the one thing they were there for.
Business analyst. The outcome is that the team solves the right problem. Agents can turn meeting notes into draft user stories. What is newly owed is acceptance criteria someone can test, and a record of which assumptions were checked with the business. The specifications article explains why vague requirements cost more when agents implement them literally.
Operations. The outcome is a service that runs. Agents can summarise logs, cluster alerts and draft incident timelines. What is newly owed is a runbook someone else can follow, and evidence for the actions taken during an incident. An operations agent should start read-only; the authority ladder article covers how it earns more.
Product owner. The outcome is value delivered to users. Agents can draft backlog items and summarise feedback. What is newly owed is the acceptance decision: a named person saying "this is what we wanted" and recording why, rather than letting merged code stand in for acceptance.
The pattern repeats in every row. The left column does not change. The middle column grows as tools improve. The right column is new, and it is where most teams have a gap.
Accountability does not move
The most important line in the diagram is the one that does not appear: there is no row where accountability moves to the agent.
An agent can draft a change and a second agent can review it. Neither can accept the change on the organisation's behalf, because neither can be held to account for it. The team structures article in the spec-driven development series sets out a full RACI for this. The short version is that every material change needs a named person who accepted it, and a record of what they relied on when they did.
This is also where experienced people become more valuable. Judging whether a plausible change is actually right takes the experience that the experts govern article describes. When drafting is cheap, judgement is the scarce input.
Rewrite the role profile around the outcome
Sabie rewrote each role profile in four short sections. The template is simple enough to use for any role.
- Outcome. One sentence: what this role is accountable for, written so that it would still be true if the tools changed completely.
- Core verbs. From Part 1: which of frame, build, integrate, evaluate, operate and govern this role is hired for.
- Decisions owned. The decisions only this role makes, such as accepting a change, approving a test strategy or signing off a release.
- Evidence produced. The work products another person can inspect to see the role is being done well.
Tools appear nowhere in the profile. They belong in team standards and the governed toolchain, which change on a different cycle. The toolchain article covers how to manage that separately.
Performance conversations then change shape. Instead of "how much did you use the agent?", the question becomes "show me the evidence for the outcomes you own". Usage is a signal at best. The AI consumption article explains why usage figures can say very little about value.
Where roles blur, and why that is fine
Some teams worry that if agents can draft tests, the line between developer and tester disappears. In small teams it often does, and that can be fine. What must not blur is the separation between the person who produced a change and the person who accepts it, for changes that matter.
A useful rule is to let activities blur freely and keep decisions sharp. A developer can write tests, an analyst can prototype, a tester can fix a small defect. But the profile should say clearly who accepts a change, who accepts a release and who accepts a risk. If two roles both believe they own a decision, or neither does, fix that before you change anything else.
Start this week
- Write a one-sentence outcome for each role in one team. Test each sentence by asking whether it would still be true if every tool changed.
- Fill in the three columns (outcome, activities agents may now draft, evidence now owed) for that team. Share it with the team and ask what is wrong.
- Pick the weakest cell in the right-hand column, usually review records or acceptance decisions, and agree one change to how that evidence is produced from next sprint.
Next: Part 3, Learning paths by role, not by tool. All parts are on the series page.
How CloudNala can help
CloudNala works with delivery leaders to rewrite role profiles around outcomes, decisions and evidence, so that adopting coding agents does not leave accountability unclear. We review how changes are currently accepted, identify where evidence is missing, and agree a practical set of role profiles and team standards with the people who will use them.
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 Capability Planning Session or write to us at consult@cloudnala.co.za