Course Content
Introduction to AI
4 sections · 10 lessons
Emerging AI Careers
Job titles in this field are a mess. "Data scientist" means something different at every company. "AI engineer" barely existed five years ago. "Prompt engineer" was declared the job of the future and then largely absorbed into other roles within two years.
So rather than a list of titles, this lesson describes the work. There are roughly six distinct kinds of job in and around AI. Understanding what each actually involves — day to day, not in the job advert — lets you read any posting and work out what it really is, and which direction suits you.
The six kinds of work
1. Building models
Common titles: Machine Learning Engineer, Research Scientist, Applied Scientist
This is what most people picture, and it is the smallest of the six by headcount.
The work is designing and training models: choosing an architecture, preparing training data, running experiments, diagnosing why a model underperforms, and improving it. A great deal of it is careful, patient debugging — a model that trains but produces poor results gives you very little to go on, and finding out why is a genuine skill.
You need: solid mathematics — linear algebra, calculus, probability. Strong Python. Deep familiarity with a framework such as PyTorch. The ability to read research papers and reimplement them.
Reality check: pure research roles are highly competitive and often expect a postgraduate degree. Applied roles at ordinary companies are far more numerous and far more attainable, and involve less inventing and more adapting.
2. Putting models into production
Common titles: ML Engineer, MLOps Engineer, AI Infrastructure Engineer
This is where the jobs actually are, and it is consistently underestimated by newcomers.
A trained model on a laptop is worth nothing. Making it useful means serving it behind an API that responds fast enough, monitoring whether its accuracy is drifting as the world changes, building pipelines that retrain it on fresh data, versioning models so you can roll back a bad one, and controlling the cost of running it.
A useful rule of thumb from industry: training the model is a small fraction of the total work. Everything around it — data plumbing, serving, monitoring, retraining, cost control — is the majority of the effort and the majority of the jobs.
You need: strong software engineering first and foremost. Containers, cloud platforms, CI/CD, monitoring. Enough ML understanding to know what can go wrong and why.
Why it is a good entry point: if you already write software, this is the shortest path in. You are adding ML understanding to skills you have, rather than starting over.
3. Building products on top of existing models
Common titles: AI Engineer, AI Application Developer, Full-Stack AI Engineer
The newest of the six, and currently the fastest growing.
You do not train models. You call them. The work is building real applications on top of model APIs: designing how the system uses the model, building retrieval so it can answer from your organisation's documents, giving it tools so it can act as an agent, handling failure gracefully, evaluating whether output quality is good enough, and managing latency and cost.
This role exists because capable models became available as services. It turns out that building a genuinely good product on top of one is substantial engineering in its own right — and a different skill set from training models.
You need: strong general software engineering. Understanding of how language models behave and fail. Systems thinking about what happens when a component is unreliable by nature.
4. Working with the data
Common titles: Data Engineer, Data Scientist, Analytics Engineer
Every model depends on data arriving reliably, in the right shape, with acceptable quality. That does not happen by itself.
Data engineers build the pipelines that move and transform data at scale. This is genuinely one of the most reliably employable skills in the entire field, and it is not glamorous, which is precisely why demand outstrips supply.
Data scientists sit closer to the business question — analysing data, running experiments, building models where a model is warranted, and translating findings into decisions. In many companies this role involves more statistics and communication than machine learning.
You need: SQL, seriously and properly. Python. Understanding of pipeline tooling and warehouses. For the science side, statistics and the ability to explain a result to someone who does not want a technical answer.
5. Deciding what to build
Common titles: AI Product Manager, AI Solutions Architect, AI Consultant
Someone has to decide which problems are worth solving, whether AI is even the right tool, what "good enough" means, and how the product behaves when the model is wrong.
This is harder than ordinary product management for a specific reason: AI products are probabilistic. You cannot specify "the system shall correctly categorise every ticket". You have to decide what accuracy is acceptable, what happens to the cases that fail, and how a user recovers. That requires understanding the technology well enough to know what is realistic.
You need: enough technical grounding to have credible conversations with engineers. Strong judgement about users. Comfort with uncertainty as a design material rather than a defect.
6. Governance, safety and ethics
Common titles: AI Ethics Specialist, AI Governance Lead, Responsible AI Manager, AI Policy Analyst
Once dismissed as a nice-to-have, this has become a compliance necessity as regulation arrives in multiple jurisdictions.
The work involves auditing systems for bias, documenting how models were built and on what data, assessing risk before deployment, ensuring decisions can be explained where the law requires it, and translating between regulators, lawyers and engineers.
You need: enough technical literacy to audit honestly, plus knowledge of the relevant regulation. Backgrounds in law, policy or social science are genuinely valued here — this is one of the more realistic routes into the field for people who did not come through computer science.
Where these roles sit relative to each other
| Kind of work | Maths needed | Software needed | Relative demand | Easiest from |
|---|---|---|---|---|
| Building models | High | Medium | Low | Maths, physics, CS postgrad |
| Production and infrastructure | Low | High | High | Backend or DevOps engineering |
| Products on existing models | Low | High | Very high | Any software engineering |
| Data | Medium | Medium | High | Analytics, databases |
| Product and strategy | Low | Low | Medium | Product, consulting, domain expertise |
| Governance and ethics | Low | Low | Growing | Law, policy, social science |
Read that table carefully, because it contradicts the common assumption. The roles requiring the heaviest mathematics are the least numerous. Most AI work is software engineering, data engineering, and product judgement applied to a probabilistic component.
Roles that are not called AI jobs
Some of the best opportunities are in existing professions where AI is arriving, and where your domain knowledge is the scarce ingredient.
- A radiographer who understands model evaluation is far more valuable to a medical AI team than a machine learning engineer who has never been in a hospital.
- A lawyer who can assess an AI contract review tool understands the failure modes that matter legally.
- A teacher who can judge whether an adaptive learning system actually helps students is genuinely rare.
- A fraud analyst knows which patterns matter and which are noise, which no amount of modelling skill substitutes for.
If you already have expertise in a field, adding AI literacy is often a stronger position than starting from zero as a generalist. Deep domain knowledge is hard to acquire and cannot be picked up in a course; AI fundamentals can.
A realistic route in
Advice that ignores the market is worse than no advice, so here is the honest version.
If you already write software
You are closer than you think. Learn enough machine learning to understand what models do and how they fail, then build things that use existing model APIs. Aim at production and application roles rather than research. Your existing engineering skill is the scarce part; ML understanding is the addition.
If you are starting from scratch
Learn programming properly first — Python, comfortably, not superficially. Then SQL and working with data, which is employable on its own and is the foundation for everything above it. Then machine learning fundamentals. Resist the temptation to jump straight to training neural networks; without the groundwork you will be able to follow tutorials and unable to solve problems.
If you come from a non-technical field
Governance, product and domain-specialist roles are real routes, not consolation prizes. Build genuine AI literacy — enough to ask hard questions and evaluate claims — and combine it with the expertise you already have. That combination is rarer than either half alone.
What actually gets you hired
Two things carry disproportionate weight, and neither is a certificate.
Something you built that works. A deployed project someone can use beats any number of completed courses. It does not need to be impressive in scope — it needs to be real, finished, and honestly described. Being able to explain why you made each decision, and what you would do differently, demonstrates more than the project itself.
The ability to explain clearly. Much of this work involves telling people who are not engineers what a system can and cannot do, and why a result is uncertain. Engineers who can do that end up in the rooms where decisions get made.
On the anxiety
It is worth addressing directly, because it affects how people approach this field.
AI genuinely is changing what jobs involve. The change is real. But the pattern, so far and consistently, is that specific tasks get automated and roles reorganise around what remains — rather than whole professions vanishing.
What tends to remain valuable is exactly what models are structurally bad at: work requiring context the system was never given, work requiring accountability, work requiring judgement about what should be done rather than how to do it, and work requiring trust between people.
The reliable move is not to bet on a specific tool being permanent. It is to build understanding that transfers — how these systems work, where they fail, how to evaluate a claim — because that understanding survives every change in which product is fashionable.