The skills map, in order

The AI engineer roadmap: a stage-by-stage skills map

How to use this roadmap

This is a map for engineers who already ship software, not a beginner syllabus. Three rules make it work:

• Skip what you already know. If you live in production observability, the deployment-and-ops stage is revision, not new ground — spend the time you save on evals, which almost nobody arrives with. Which stages you can compress depends on your background, and the order matters more than the duration of any single stage.
• Don't read your way through it — build. Every stage names an outcome: an artifact you can run and show. Reading about agents teaches you nothing the first broken tool-call won't teach you faster. Treat each stage as a thing to ship.
• Carry one project the whole way. The fastest route is a single agent you grow stage by stage — add retrieval to it, add evals to it, cost-model it, harden it, deploy it. By the end the project is your portfolio, and the layers prove you understand how they fit.

The stages cluster into three arcs: foundations (stages 1–3), building agents (stage 4), and production (stages 5–8), with the portfolio (stage 9) as the proof that ties them together. The table is the whole map at a glance; the sections after it go a level deeper.

The roadmap, stage by stage

Read it top to bottom. The middle column is the skill to learn; the right column is the artifact that proves you learned it — the thing a hiring engineer can actually look at.

This map mirrors how the aiArch curriculum is sequenced — backward-designed from the job, so the order reflects what production AI actually demands rather than what's easiest to teach first.

Where to start, by background

Your background does not change the order — it changes which stage is going to hurt. And the one that hurts is rarely the one people brace for.

Seniority changes the pace, not the route. A staff engineer moving into AI skips more of stages 1, 2, and 8 than a mid-level engineer does, and spends the time saved on evals and the trust boundary — the two stages where experience elsewhere transfers least. What does not change is stage 4: nobody gets to skip building the agent, because every production stage after it operates on the thing you built there.

Foundations: stages 1–3

The opening arc is about changing how you think before you build anything ambitious. Stage 1 is the shift from deterministic to probabilistic: the same input can return different output, the core component is metered per token, and your job is to build a reliable system around an unreliable part. Internalise that and the rest of the roadmap stops feeling strange. Nothing here requires machine learning — and it stays that way the whole route; you are building on models, not training them.

Stage 2 is prompting and context done properly: not prompt-whispering tricks, but treating the prompt as a spec, controlling what goes into the context window, and using prompt caching to keep cost down. Stage 3 adds retrieval — embeddings and vector search — but the real skill is judgement about when RAG helps. A lot of systems reach for retrieval where a better prompt or a tool call would do. Get these three right and you have a grounded, controllable single-shot system; the next stage puts it in a loop.

Building agents: stage 4

This is the hinge of the whole roadmap. Stage 4 turns a single model call into an agent — a model running in a loop, deciding when to call tools, working toward a goal instead of answering one prompt. The skills are tool and MCP design (least-privilege, well-described tools the model can actually use), orchestration across sub-agents, and — the part beginners skip — bounding the loop so it can't burn tokens forever or take an unsafe action. Build one that does real work, with the loop and tool layer visible.

This is also where structure starts to matter: how the orchestrator, tools, retrieval, and stopping conditions fit together is an architecture decision, not an implementation detail. The patterns behind that — and why a bounded loop is the default — are laid out in agentic AI architecture. Stage 4 is where many people stop and call themselves done. The roadmap doesn't, because an agent that works in a demo is a long way from one you'd run in production.

Production: evals, cost, safety, deploy

Stages 5–8 are what separate an AI engineer from someone who got a demo working once. They're the moat, because they're the least fun and the most valued:

• Stage 5 — Evals. The single most underrated skill in the field. When output varies, vibes don't tell you whether a change helped; an eval suite does. Learn to define correctness, build a harness, use LLM-as-judge where exact-match won't work, and gate changes on a score. Our guide to evaluating LLM systems is the deep dive for this stage.
• Stage 6 — Cost & routing. Token economics is the new latency-and-throughput. Learn to pick a model per step — a cheap one for routing and extraction, a strong one for hard reasoning — and to compute the blended cost at production volume so the bill doesn't ambush you.
• Stage 7 — Safety & guardrails. The trust boundary for a system that takes untrusted text and can act on the world: prompt injection, data exfiltration, unsafe tool use. Least-privilege tools and an explicit threat model belong in the design, not in the post-incident review.
• Stage 8 — Deployment & ops. Stand the whole thing up on a real platform — Anthropic, AWS Bedrock, or Cloudflare — with the observability, tracing, and cost visibility you'd demand of any production service. The model in the loop doesn't excuse you from operating it well; it raises the bar.

Done in order, each of these adds rigour to the agent you built at stage 4 rather than sending you back to a blank page. That's the point of carrying one project: by stage 8 you have a system that's correct, affordable, safe, and operable — the four things production actually asks for.

Portfolio: prove it

Stage 9 isn't more building — it's packaging the build as evidence. AI hiring leans hard on demonstrated work because the field moves faster than credentials can keep up. The artifact that makes you screen-ready is one shipped system, well explained: a running agent with the tool layer and loop visible, the eval suite that proves it works, the cost and model-selection writeup, evidence you handled the trust boundary, and a short design rationale tying the decisions together.

One well-shipped, well-explained system beats five half-finished demos every time. If you want a worked example of what shipped-and-explained looks like, the architecture notes behind this platform are exactly that artifact — a production AI system with its decisions written down.

As-built: how this curriculum maps to real exam domains

This roadmap is not an abstract sequence we invented for the article — it is the stage order of a locked, backward-designed curriculum we maintain in docs/CURRICULUM.md (v1.6, Track 0 plus Tracks A through G, 67 modules). Every module in that document carries an explicit "cert domain · weight" line, so a stage like evals or the trust boundary is not just a skill we assert matters — it is traceable to a specific domain in a specific exam guide, with the percentage weight next to it.

Two of those exam guides are confirmed against their official public versions, not secondhand summaries. AWS Certified Generative AI Developer – Professional (AIP-C01) weights its five domains D1 31 / D2 26 / D3 20 / D4 12 / D5 11, with a pass mark of 750 — production integration and data/compliance (D1) dominate, which is why stages 3 and 7 of this roadmap get disproportionate space. Anthropic's CCAR-F (Claude Certified Architect, Foundations) weights D1 27 / D2 18 / D3 20 / D4 20 / D5 15, pass mark 720, 60 questions across 120 minutes, $125 — confirmed in the official public v1.0 exam guide published alongside Anthropic's four-exam certification portfolio. D1 there is agentic architecture and orchestration, which is exactly stage 4 of this map.

We do not treat certs as the goal — the North Star is the Monday-morning habit, not a badge — but the domain weights are a useful cross-check: if a stage on this roadmap barely shows up in either exam's blueprint, that is a signal to question why it is here at all. The bounded-loop discipline in stage 4 is also the subject of a real production pattern, the bounded agentic loop, if you want to see the architecture behind CCAR-F's D1 domain rather than just its weight.

Frequently asked questions

What is the AI engineer roadmap?

It's a sequence of nine stages that takes an experienced engineer from LLM fundamentals to a deployed, evaluated, cost-controlled AI system: foundations and probabilistic thinking, prompting and context, RAG and retrieval, agents and tool use, evals, cost and routing, safety and guardrails, deployment and ops, and a portfolio. Each stage pairs a skill to learn with an artifact to produce, and the stages build on each other in order.

What should I learn first?

Start with foundations: the shift from deterministic to probabilistic systems, prompts as spec, and what changes when your core component is non-deterministic and metered per token. Then prompting and context, then retrieval. Those first three stages give you a grounded, controllable single-shot system before you put a model in a loop at the agent stage. Resist jumping straight to agents — they make a lot more sense once the foundations are solid.

How long does the roadmap take?

For someone already working as an engineer, it's focused weeks rather than years, and the timeline depends mostly on how much you build rather than read. Foundations and a first working agent are a matter of days; the production stages — evals, cost, safety, deployment — are the part that takes deliberate weeks, because doing them properly is the point. Skipping stages you already know (say, deployment and ops) compresses it further.

Do I need to learn machine learning?

No. Training models and the maths behind them are a different profession (ML engineering and research). Every stage on this roadmap is about building systems on top of models that already exist — calling, orchestrating, evaluating, and operating them. The work is much closer to senior software engineering than to a research lab, which is why an experienced engineer can move quickly through it.

What should be in my portfolio?

Shipped systems, not snippets: a working agent you can show running with the tool layer and loop visible, an eval suite that defines and measures correctness, a cost and model-selection writeup, evidence you handled the trust boundary, and a short design rationale for the whole thing. The roadmap is designed so that carrying one project through every stage produces exactly this artifact by the end.

What's the fastest path for an experienced engineer?

Skip the stages you already own and carry a single project the whole way. Most seniors can move fast through foundations, prompting, and deployment because those lean on skills they already have; the time is best spent on agents, evals, and the trust boundary, which are the new ground. Build one real agent, add each production layer to it in order, and write the rationale as you go.

Is the roadmap different for a senior AI engineer?

The stages are the same; the distribution of your time is not. A senior engineer arrives already owning most of stages 1, 2, and 8, so the route compresses at both ends and expands in the middle — evals, cost discipline, and the trust boundary are where the hours go, because they are the stages where a decade of experience elsewhere transfers least. The other difference is what "senior" is being paid for once you get there: not writing the agent, but deciding which parts of a system should have a model in them at all. That judgment comes from stage 4 onward, which is why the map does not let you skip building one.

Where do I start if I'm coming from DevOps, data, or backend?

Start at stage 1 regardless — it is the shortest stage on the map, and everything after it assumes it. The real question is what to move fast through, and that depends on your background: backend engineers can compress deployment and ops but will find evals genuinely new, data engineers already own retrieval but not the agentic loop, and DevOps engineers own the operational stages while the retrieval and prompt-debugging stages are unfamiliar ground. The table above maps each background to what to skip and where it bites.