Since generative models entered organisations, job titles have multiplied: AI Engineer, GenAI Engineer, AI Product Manager, AI Solutions Architect, AI Quality Lead, Conversation Designer, AI Adoption Lead. The proliferation is real, but it is harder to read than it looks, because one new title can cover several very different situations.
Title, responsibility and occupation are three different things
GenAI produces at least five distinct effects, routinely collapsed into the phrase « new job ». It can create responsibilities that did not exist, reinforce a specialisation already present, move the boundary between two existing roles, produce a fresh label over unchanged work, or simply add a GenAI component to an otherwise stable position.
Reading by the title
« This role is called AI Engineer, so it is the same job as the AI Engineer role I saw elsewhere. » That assumption is wrong more often than it is right, even at comparable seniority.
Reading by the responsibilities
« This role requires shipping a system to production, owning its quality, and trading off cost against latency. » Those elements define the actual work, and they compare cleanly across postings.
A title is an organisational signal: it tells you how the company pictures the topic, not what you will do every day.
Six families of responsibility taking shape
This is not a taxonomy. It is a reading grid: in any given organisation these families may map onto six distinct roles, two roles, or one person carrying all of them under whatever title.
AI / GenAI Engineer
Building applications around models: API integration, document retrieval, workflows and agents, evaluation, running things in production. The overlap with software engineering is heavy — this is software engineering first — and the overlap with ML engineering depends on whether models are trained in-house at all. Two postings under this title can describe application integration in one case and platform work in the other.
AI Product
Product manager or product owner with responsibilities tied to probabilistic behaviour: defining what an acceptable answer is, organising evaluation, trading off quality, cost and latency, handling data and risk, running use-case discovery where feasibility is never a given. Product skill stays central; what changes is the set of decision criteria.
AI Solutions and architecture
Translating a need into an architecture that survives an enterprise context: integration with existing systems, security and access rights, data provenance and lifecycle, build-versus-buy, regulatory and contractual constraints. This role predates GenAI; what is new is the specific set of trade-offs these systems impose.
Evaluation and AI quality
Building representative case sets, defining acceptance criteria, catching regressions, characterising unwanted behaviour, making quality observable over time. In some organisations this is a dedicated role. In many others it is a responsibility spread across engineering, product and business teams — and the interesting interview question is which of the two you are joining.
Conversation and AI UX
Designing interaction with a system whose output is not guaranteed: setting expectations, handling uncertainty and error, fallback paths, human-in-the-loop, building trust, understanding what users actually do with the system. No single title has established itself here, and the responsibility is often shared with existing product design.
Adoption and transformation
Supporting usage: which processes are affected, which skills to build, change management, usage rules, operational governance. This is the family furthest from the technical work and the most dependent on organisational context. It is also where the title varies most, from project manager to programme lead.
Reading a posting whose title is new
Faced with an unfamiliar title, the useful question is not « what is this role called » but « what is actually expected ». Eight questions are usually enough to reconstruct the work behind the label.
- What problem am I solving, and for whom inside the organisation?
- What exactly do I deliver: a prototype, a production service, a framework, a decision?
- Which decisions are mine, and which stay elsewhere?
- What level of coding is expected: daily authoring, review, specification, none?
- Which teams will I work with day to day, and at what cadence?
- Who owns the data the system depends on, and under what conditions is it accessible?
- Who evaluates quality, and against which criteria that already exist?
- Who owns production and on-call, if the system is operated?
Answers to those questions compare across roles far better than titles do. Two postings with the same title can answer them in opposite ways; two postings with different titles can describe the same work.
What this movement does not let you conclude
The multiplication of titles is observable. What people infer from it usually is not. Three cautions are worth holding.
- A recent title is not a settled occupation: it can disappear, merge into another, or change content without notice.
- A title that appears often in postings is not a standard: organisations copy wording they see elsewhere, including when it describes something else.
- A new responsibility does not imply a new role: it is frequently absorbed by an existing one, which is the common case in smaller teams.
The Prompt Engineer case illustrates the difficulty. Depending on the moment and the organisation, the term has meant a cross-cutting skill expected of everyone, a genuine specialisation on complex systems, and a standalone job title. Those three readings are not equivalent, and none of them constitutes a universal career path.
Positioning yourself without waiting for stable naming
There will probably be no moment when the vocabulary settles and everyone finally knows what to call themselves. The workable strategy is to describe yourself through what compares across organisations: the problems handled, the deliverables, the level of responsibility, the environment.
- Describe your work through the responsibilities you hold, keeping the title as secondary information.
- When applying, align with the posting's vocabulary without adopting a title you have not held.
- In interview, check which of the six families the role actually covers, and which are held by others.
- Treat an unusual title as a question to ask, not as a signal of seriousness or amateurism.
It is also a form of protection: a professional who can describe their responsibilities stays readable when the vocabulary shifts, whereas a professional identified with a label depends on how long that label lasts.
Decoding a title you do not recognise
Worth checking before applying, and worth reopening in interview when the answers are missing.
- The problem to solve is named, not just the domain.
- The expected deliverables are identifiable: prototype, operated service, framework, decision.
- The decision scope is explicit.
- The expected level of coding is clear.
- The teams I would work with are named.
- Data ownership is identified.
- Responsibility for evaluating quality is assigned.
- Responsibility for production is assigned.
Key points
- A title describes how an organisation pictures the topic, not the daily work.
- Six families of responsibility are taking shape, but they are distributed differently in each company.
- Quality evaluation is sometimes a dedicated role, often a shared responsibility.
- Eight questions on problem, deliverables, decisions and production are enough to reconstruct a role.
- A frequent title is not a standard, and a new responsibility does not imply a new role.
- Describing yourself through responsibilities keeps you readable when the vocabulary changes.
- Market
- GenAI roles
- Reading a posting