Open any South African job board and search for "AI". You will find AI engineers who never train a model, machine learning engineers who mostly write integration code, AI architects who are really product managers, and prompt engineers whose real job is checking whether a support assistant gives correct answers. The same title means different work at different companies, and sometimes at the same company.
That matters because a title is what organisations hire against, budget for and promote into. If the title is unreliable, every one of those decisions is built on sand. Candidates cannot tell what the job is. Hiring panels interview for the wrong thing. Managers cannot tell whether a role is filled, overloaded or missing.
CloudNala's view is that an AI job title is a label, not a definition. The role is defined by its verbs, the work it performs, and by the work products it leaves behind for someone else to check. Read roles that way and most of the confusion disappears, because verbs and work products change far more slowly than titles do.
This series applies that idea from four angles. This first part sets out the method. Part 2 applies it to the roles you already have, Part 3 builds learning paths around it, and Part 4 turns it into an interview process.
Sabie Systems is fictional, and its systems and figures are illustrative. Sabie is a Pretoria software and data services company of about 140 people. It builds line-of-business systems and data platforms for mid-sized clients, and in the last year it has added an AI assistant to two of its products. Its head of engineering recently counted eleven open job ads containing the word "AI". Nobody, including the people who wrote them, could explain how they differed.
Why AI titles cannot be trusted yet
Titles settle when an industry agrees on what a job involves. That has not happened for most AI roles, and there are good reasons it has not.
The work is new and still moving. A role defined around a particular framework or model family two years ago describes different work today. Titles also carry signalling value: "AI engineer" attracts more applicants and commands a different salary band than "integration developer", so there is a constant pull to attach the label to work that has changed only slightly. Recruiters and vendors have their own reasons to use the most marketable term.
None of this is anyone behaving badly. It simply means that, for now, no AI title should be read as an industry standard, including the ones in this article. Where we use a title below, we use it as Sabie's job ads used it, to show how the method works, not to propose a definition.
The forward deployed engineer article makes a similar point about one particular title: it is an operating model before it is a job. This series generalises that idea to every AI role.
Six verbs that describe AI work
Instead of starting from the title, start from what the person will actually do. Almost all AI-related work falls into six verbs. They are not exotic. Most of them describe engineering and product work in general. What AI changes is the balance between them.
Frame. Decide what problem is being solved, for whom, what good looks like and what must not happen. Work product: a problem statement, a specification, a decision record.
Build. Create a component that did not exist: a model, a prompt-and-contract pair, a retrieval pipeline, an agent, a tool. Work product: code and configuration that pass review.
Integrate. Connect AI components to the systems, data and identities the business already has, safely. Work product: interfaces, tool contracts, access rules, deployment changes.
Evaluate. Establish whether the system does what it should, with evidence. Work product: test sets, rubrics, evaluation runs, failure analyses.
Operate. Keep it running, affordable and observable after launch. Work product: dashboards, alerts, runbooks, incident records, cost reports.
Govern. Decide what is permitted, check that it stays permitted, and hold the record. Work product: policies that map to controls, approvals, audit evidence.
There is a seventh verb that runs through all of these: explain. Every role has to explain its work to someone who did not do it. We treat it as a shared capability rather than a role, and come back to it in Part 3.
Decoding Sabie's eleven ads
Sabie's head of engineering took each of the eleven ads and asked two questions of every responsibility listed: which verb is this, and what would the person hand over to show it was done? The matrix below is the result for the nine distinct titles in the ads.
Several things became obvious once the ads were read this way.
Two ads with different titles described the same job. An "AI engineer" ad and an "agent engineer" ad both asked for someone to connect a language model to Sabie's ticketing and billing systems, write the tool definitions and deploy the result. Integrate was core in both, and both expected build work. They merged into one role.
One title described two jobs. The two "AI engineer" ads disagreed. One was mostly integrate and operate: connecting hosted models to products and running them. The other was mostly build and evaluate: fine-tuning and testing a classification model on Sabie's own data, which is closer to the ML engineer row. The matrix shows the first reading. Same title, different person.
The "prompt engineer" ad was an evaluation role. Read closely, most of its responsibilities were writing test questions for the support assistant, checking the answers against product documentation, and reporting where the assistant was wrong. That is evaluate, with some frame. Sabie renamed it, and the applications it attracted changed with the name.
Operate and govern were thin. Only one title had operate as a core verb, and only two had govern, one of them the architect role, whose ad was mostly about framing. Yet Sabie had two AI features in production and was about to add a third. Somebody was doing that work, informally and on top of another job.
Sabie ended with five roles instead of eleven ads. The titles it chose matter less than the fact that each one now has a short list of core verbs, a list of work products, and a named reviewer for each work product.
From verbs to work products
A verb is still a little abstract to hire or train against. The next step is to name the work product each verb leaves behind, and the evidence a reviewer would look at to judge it.
| Verb | Typical work product | Evidence a reviewer can inspect |
|---|---|---|
| Frame | Problem statement, specification | Is the user named, the outcome measurable, the boundary stated? |
| Build | A component in a pull request | Does it pass review and tests, and is the change explained? |
| Integrate | Tool contract, access rule | Least privilege, failure handling, an owner for the interface |
| Evaluate | Test set, rubric, evaluation run | Coverage of real cases, agreement with human judgement, a trend |
| Operate | Runbook, dashboard, incident record | Could someone else run it at night from what is written? |
| Govern | Control register, approval record | Does each policy statement map to a control and evidence? |
The right-hand column is what makes the method useful. A role profile that lists verbs and work products tells a candidate what they will produce, tells an interviewer what to test, and tells a manager how to tell whether the role is working. A title tells you none of those things.
The work-products article in the capability series uses the same principle for measuring teams. Here we apply it to individual roles.
What the verb test reveals
Running the test across a whole organisation, not only its job ads, tends to reveal three patterns.
Missing verbs. Evaluate and operate are the verbs most often done by nobody in particular. They are less visible than build, and they only become urgent after something goes wrong. If no role has evaluate as a core verb, nobody is accountable for knowing whether the AI is right.
Overloaded roles. One person with all six verbs as core is not a unicorn hire. It is a single point of failure. That is common in small teams and acceptable for a pilot. It stops being acceptable once a system has real users, because the person who builds a change should not be the only person who evaluates and approves it.
Roles that only explain. Some roles talk about AI, run awareness sessions and write strategy, but leave no work product another person could check. Explaining is valuable, but a role whose only verb is explain is hard to justify and hard to measure.
Using the method beyond hiring
The same reading works anywhere roles are discussed.
Organisation design. Map the verbs to people for each AI system you run. Any verb with no name against it is a gap, and any name against every verb is a risk.
Vendors and contractors. Ask a supplier which verbs their team will perform and which work products they will hand over. "We provide AI engineers" says nothing. "We build and integrate; you evaluate and operate; here is the handover pack" is a contract you can manage.
Career paths. People can grow by adding verbs, or by going deeper in one. Both are legitimate. The maturity article shows how that looks at organisational level.
Existing roles. Most of the people who will do AI work already work for you, under titles like developer, tester and analyst. Part 2 applies the method to them.
Start this week
- Collect every AI-related job ad and role profile you have, open or filled. Do not edit them yet.
- Tag each responsibility with one of the six verbs and write the work product next to it. Anything you cannot tag is probably a vague aspiration and can go.
- Build your own version of the matrix for the systems you run. Circle any verb with no owner, and any person who owns them all.
Next: Part 2, Engineering roles are defined by outcomes, not tools. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations plan AI capability around the work, not the titles. We map the AI systems you run or plan to the six verbs, identify missing and overloaded roles, and rewrite role profiles around work products and reviewers, so that hiring, training and supplier contracts all describe the same thing. We do not sell recruitment or training packages, so our recommendations are about what your organisation actually needs.
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