Start from the decisions, not the technologies

Most AI job adverts open with a list of tools. That is a reasonable way to describe a build task and a poor way to staff a programme, because the tools change faster than the decisions and the decisions are what go wrong. An AI system that fails rarely fails because the wrong library was chosen. It fails because nobody could say what a good answer looked like, or because the data meant something different from what everyone assumed, or because no one owned the decision to switch it off.

Six decisions sit underneath any AI system worth building:

What to build, and what to leave alone.
Whether the data can carry it.
Whether the output is actually right.
Whether the system may act on its own.
Whether anyone will use it.
How the thing is put together.

Only the last of those is a programming question. Staff the first five and the sixth becomes a manageable procurement or engineering problem. Staff only the sixth, which is the common pattern, and you have a working demonstration nobody trusts.

The nine roles

Not all nine are hires. Several are people you already employ, given the time and the authority to do the work properly, and on a single project most are part-time: the accountable owner may spend a day a month on it, the subject expert a day a week. The column that matters most for recruitment is the last one.

Nine roles on an AI project, what each one decides, and whether the role requires writing code
Role	What it decides	Writes code
Accountable owner	Whether the thing is built at all, and whether it stays switched on	No
Subject expert	What a good answer looks like, and which plausible answers are wrong	No
Business analyst	What the organisation actually means, and which definition holds where systems disagree	No
Service designer	How the work reaches people, and whether they trust it enough to use it	No
Source system owners	What the records mean, who may see them, and what may be done with them	No
Data engineer	How data moves, and where definitions are enforced	Yes
AI engineer	How the model, the retrieval, and the checks fit together	Yes
Data scientist	How a predictive model is trained, measured, and retired	Yes
Software engineer	How the agent and its tools are built and bounded	Yes

Accountable owner: Senior enough to stop it. This is a named person, not a committee, and in almost every case it is someone you already employ rather than someone you hire.
Subject expert: The person who can read an output and say that it is confident and incorrect. Without one, evaluation collapses into checking that the system replied.
Business analyst: The role that turns three departments answering "how many active customers?" three different ways into one written definition with an owner. Elicitation and facilitation are the skills, and the deliverable is agreement in writing, which an engineer then enforces. Rarely hired for AI specifically, and the reason the definitional work either happens or stalls.
Service designer: Rollout, training, and the change work, as well as the interface. Adoption is a job somebody holds, not something that follows from launching, and the difference between a launched system and a used one usually sits here.
Source system owners: Already in post, running the systems the AI will draw on. Their existing data decisions bind everything downstream, which is why they are consulted early rather than informed late.
Data engineer: The scarcest of these hires and the one most often made last. Pipelines, warehouses, and the unglamorous work that decides whether anything above it can be trusted.
AI engineer: Integration rather than invention: calling models, building retrieval, wiring the input and output gates. Increasingly a software engineer with a particular specialism rather than a separate profession.
Data scientist: Needed when you are building predictive models on your own history. The one role on this list where the deep-learning frameworks are the day job rather than a line in an advert.
Software engineer: An agent is ordinary software with a model inside it. Permissions, budgets, logging, and testing are ordinary engineering, and they are what stops it acting beyond intent.

Which of these need to program?

Four of the nine, and the four that do are the ones building rather than directing. The accountable owner, the subject expert, the business analyst, the service designer, and the people who own the source systems all need to understand what the machine does and where it fails. None of them needs to know how it is implemented, any more than the person who commissions a building needs to lay bricks.

The understanding those five roles need is real and specific, and none of it is programming. It is knowing:

That a model predicts text rather than looking anything up.
That retrieval grounds it in your documents only if the permissions are right.
That a predictive model inherits the bias in your history.
That an agent will do exactly what its permissions allow, and no more.
That fluency is no guide to whether an answer is correct.

That is the content of this course, and it can be held perfectly well by someone who has never opened a terminal.

What job adverts do wrong

The commonest mistake is a framework roll-call in an advert for a role that will never train a model. PyTorch and TensorFlow are tools for building and training neural networks. They belong in the advert for the data scientist, and almost nowhere else. An organisation using hosted models, retrieval over its own documents, and a supplier's agent platform may never touch either of them, and that is the situation most organisations are in.

Putting them in a leadership or design advert does three things, all bad. It filters out the people best placed to do the job, because they read the advert and conclude it is not for them. It attracts people who will be bored within a quarter, because the work turns out to be stakeholder management. And it tells everyone reading, inside and out, that the organisation believes the hard part of AI is implementation. The hard part is deciding what is worth building and proving it works.

If your stack has already chosen for you

Plenty of organisations are standardised on one cloud, with an assistant licence bundled into the productivity suite before anyone drew a plan. That changes the staffing question rather than removing it. If the models are a service and the assistant is a licence, you are configuring rather than building, and the engineering roles shrink to integration work you may well contract rather than hire.

What grows instead is everything on the non-coding side. Someone still has to decide which uses are appropriate, what the assistant may reach, whether its answers are right often enough to rely on, and what happens to the people whose work it changes. A bundled licence answers the question of which supplier. It answers none of the questions this page is about, and mistaking one for the other is how an organisation ends up with thousands of licences and no idea whether any of it helped.

Who to hire first

Name the accountable owner before anything else, and take the name from people you already have. Then secure the subject expert's time, in writing, because this is the role most often assumed rather than resourced and the one whose absence is hardest to detect early. Business analysis comes next wherever your systems disagree with each other, because somebody has to reach the definitions before anybody can enforce them, and it is nobody else's job on this list. Then data: either a data engineer or an honest assessment that your data is not ready, which is a finding worth having before you spend anything on models.

Engineers come last, and often as a contract rather than a hire, because their work is bounded and the requirements only become clear once the first three roles have done theirs. The pattern that fails is the reverse: an AI lead appointed on a technology CV, who builds something impressive against requirements nobody senior agreed, and cannot say whether it works because no one defined what working meant.

What changes when it is a programme, not a project?

The nine roles above are what one project needs. Run several at once and a layer appears above them that none of the nine covers, resourced and hired separately from any individual project:

Programme manager. Sequencing, dependencies, and funding across projects, including the decision to stop one that is not working while the others continue.
Adoption and change manager. The service designer's work at portfolio scale. One team absorbing one new system is a project concern. A workforce absorbing six systems in eighteen months is not, and it is the same people being asked to absorb all of them.
Portfolio governance. One risk register, one evaluation standard, and one place where a supplier decision is taken once rather than once per project.

This page stops at the project boundary, and the course does not cover programme design. The distinction is worth holding at the point of hiring: resource that layer explicitly and the second and third projects cost less than the first, because sequencing, adoption, and supplier choices are each settled once and inherited rather than repeated.

The same nine roles are drawn against the architecture on the anatomy of an AI system: switch on the Roles layer to see which part of the system each one is responsible for. Accountability and evaluation are covered properly in Module 5, and the buy-or-build decision that shapes how many engineers you need is in Module 6.