AI development can look like twenty new specialisms landing at once. It isn't. Most of this work you will never staff, and the part you do staff arrives in order, not all together. So here is the whole field laid out plainly — and then the one thing that tells you which slice of it is actually yours yet.
01 - The work itself
These are the kinds of work, grouped so the list is easier to hold. Read it as things to think about, not roles to fill — almost no team needs all of them.
Context engineering (what sits in the window, what is fetched on demand), prompt and instruction engineering, knowledge engineering (ontologies, graphs, entity resolution), and data / RAG engineering (pipelines, embeddings, freshness). Memory has no box of its own — it lives as run state, as shared memory, as a durable store. Only the write-back policy — what a run may save, and who is allowed to write — ever needs its own attention, and only once many proxies share one memory.
Model routing, agent engineering, multi-agent orchestration, harness engineering, tool engineering, and workflow engineering — knowing when a fixed graph beats a free-running agent. One trap shows up only at scale: give a proxy too many tools and it starts choosing badly, so pruning the toolset becomes a job in its own right.
Token and cost engineering — budgeting, caching, batching, latency. At scale, FinOps sits on top: cost attributed per feature and per proxy, forecast rather than discovered on the invoice.
Evaluation (golden sets, model-as-judge, regression — plus the quiet, ongoing job of building and maintaining those sets), ordinary software testing for the deterministic parts, observability, and lifecycle management — versioning and re-checking when the model shifts under you.
Testing and evaluation are not one job. One checks code that behaves; the other interrogates a model that won't answer the same way twice.
Safety and security (guardrails, prompt-injection defence, least privilege), governance and permissions (what a proxy may decide unsupervised, audit trails, and the delivery gate — where the check sits, and the rule that the checker is never the producer), and the interaction design that makes stepping in cheap.
02 - Not a hire
That list reads like an org chart. It isn't one — because the same work can be owned three very different ways, and only one of them is a hire.
The model itself. You route to it and pin a version; you don't build it. Adapting a model to your domain only earns its keep at real scale — and even then you are tuning a bought model, not making one.
Owned by everyone. Reliability, reproducibility, the habit of checking output before it ships. These are real, but they are how a competent engineer already works — not a department. A staffed "verification team" would just be a toll booth; the check is a rule, not a checkpoint someone mans.
Owned by a box. The disciplines above, once the work grows heavy enough to deserve its own people.
Most of the field you either buy or simply do. Only the heaviest slices ever turn into a hire.
And alignment — keeping behaviour true to intent — is the goal all of this serves, not a box of its own. Its hands-on version lives down at the model, below everything on this page.
03 - In order
Which slices become a hire isn't a matter of taste — it's load. A small system has reliability as a habit; a huge one staffs it as AgentOps. Cost is a footnote at ten thousand tokens a day and a team at ten billion.
So the disciplines don't arrive together; each switches on when the load that needs it shows up — roughly in this order:
One proxy, a prototype — maybe four jobs; everything else is still just a habit.
Put it in front of people who didn't build it, and evaluation, observability, and governance switch on: eyeballing stops scaling, and "what may it decide alone?" turns into a real question.
Run a fleet of proxies on shared infrastructure, and orchestration, the platform, lifecycle, and cost all harden into their own work.
Only at real scale and deep specialisation does the model layer itself come in-house.
The same line runs backwards, too. As vendors package eval, RAG, and the rest, work that used to be a hire slides back to something you simply buy.
The bet: which disciplines a team staffs is set by its load, not its taste; staff ahead of the load and you pay for idle boxes, lag behind it and you ship output nobody checked.
Falsified if: mature teams show no real link between load — tokens a day, number of proxies, who depends on the output — and which work they have actually made someone's job.
So the honest answer to "do I need twenty disciplines?" is no. Three people with one proxy need about four — and a sense of which one switches on next. The list is a map, not a hiring plan. And none of it replaces the old crafts; it extends them — testing grows an eval twin, monitoring grows tracing, API design grows tool design, ops grows a lifecycle.
Bought, owned-by-everyone, and owned-by-a-box aren't three kinds of thing — they're three points on one line: how concentrated the ownership of a piece of work is. Nobody-yet (bought), everyone-a-little (a habit), one-team (a hire). Load concentrates ownership, and that concentration is exactly what you notice as "a new discipline appearing." Even the bought end moves: enough scale, and the model layer slides inward too.