How to become an AI Engineer

You build products on top of models somebody else trained: agents, retrieval systems, assistants, anything where a language model is a component rather than the project.

This is the shortest route from working software engineer to working in AI, and the one with the most open roles. The work is mostly ordinary engineering — APIs, latency, cost, tests, failure handling — around a component that is probabilistic and occasionally wrong. You do not need to be able to derive backpropagation, and interviews for these roles will not ask you to.

Topics: 50
Reading: 603h
Practice: 678h
Projects: 6

The route

In order. Each chapter ends in something you can do, so you can tell whether it worked rather than whether you got to the end of it.

1Foundations

110h

By the end of this chapter: You have called a model and got something useful back, and you can write the Python around it properly — retried, rate-limited, validated, many calls at once — and get the data you need out of a database. You would pass a coding screen on the language itself.

2Working with models

45h

By the end of this chapter: You can drive a model API deliberately rather than hopefully: what temperature actually changes, how to get back JSON you can rely on, how to stream without breaking validation, what fits in the window, and how to stop paying twice for the same prefix.

3Agents

55h

By the end of this chapter: You can build an agent that calls tools, knows when to stop, degrades instead of collapsing when a tool fails, and keeps the right things in context when it cannot keep everything.

Build this now — you have just done Tool calling

An agent that uses tools

An agent written as a plain loop you own — no framework — that calls tools, survives them failing, knows when to stop, and leaves a transcript you can read afterwards.

7 stages · 21h

4Retrieval

42h

By the end of this chapter: You can build retrieval that actually retrieves: documents chunked sensibly, embedded, indexed, reranked, and answers grounded in the fetched text rather than in the model's memory.

Build this now — you have just done Retrieval-augmented generation

RAG with citations you can check

A question answering system over documents you supply, which answers only from the text it retrieved, cites the chunk behind every sentence, and declines when nothing good came back.

7 stages · 23h

5Internals

63h

By the end of this chapter: You can explain what happens inside the model you have been calling — how attention works, what fine-tuning changes and what it does not, and why quantization makes a model cheaper to run.

Build this now — you have just done Transformers & attention

Build your own GPT

A decoder-only transformer you wrote yourself, trained on text you chose, generating new text — no framework magic, about 300 lines.

7 stages · 24h · also needs PyTorch, Neural networks, Backpropagation, which are not on this route

Build this now — you have just done Transformers & attention

Serve a model, then make it cheaper

A model behind an HTTP API that you have measured honestly, then made faster with batching, caching and quantization — with the numbers for what each one bought.

7 stages · 24h · also needs PyTorch, which is not on this route

6Knowing it works

83h

By the end of this chapter: You can prove a change helped. You know where your labels came from and whether they are worth trusting, you can build an eval set from real traces, validate a judge before believing it, run both in CI, and see what the system actually did in production.

Build this now — you have just done Evaluation

Fine-tune a small model

A small open model adapted with LoRA to a task you define, measured against the two honest baselines — the base model, and the base model with a good prompt — and an adapter you serve.

7 stages · 26h · also needs PyTorch, which is not on this route

7Shipping it

96h

By the end of this chapter: You can put the thing in front of users and keep it up: deployed, containerised, traced, tested, and designed around the failures distributed systems actually have.

Build this now — you have just done Testing

An eval harness that fails the build

A dataset built from real traces, graders checked against human labels, a runner that scores a change, and a CI job that turns a pull request red when quality drops.

7 stages · 24h

8The interview

109h

By the end of this chapter: You can pass the rounds that decide the offer: the algorithms screen that still gates large companies, choosing a model and defending the choice, designing a product around a component that is sometimes wrong, and showing that a launch moved a real number.

What ready looks like

Not “finished the route”. These are things you can do, and each one is something an interview will actually ask you to do.

You can build an agent that calls tools, recovers from a failing one, and stops for the right reason.
You can build retrieval that answers from the fetched documents, and say why a chunking or reranking choice was made.
You can write an eval set from real traces, validate an LLM judge before trusting it, and run both in CI.
You can reason out loud about cost and latency: what a token costs here, what the cache saves, where the time goes.
You can design a system around a component that is sometimes wrong, and say what happens when it is.
You can explain what attention does, what fine-tuning changes, and when you would reach for neither.
You can pass a coding screen in Python, having done the algorithms work this route budgets 40 hours for, and can carry one problem through three changes to its requirements.

What this route is not

Training models. If you want to pretrain, fine-tune at scale or do research, this route gives you the vocabulary but not the depth — take the ML Engineer or Research route instead.

Commonly over-studied by AI engineers

These are on the route because they come up, but people reliably spend more time here than the role repays. Read the topic for the reason.

Prompting — Prompt-trick listicles age badly. Techniques that were essential two model generations ago are now actively harmful.
Streaming responses — Over-studied as a product feature, but do not skip it for a loop: parsing a streamed response arriving in arbitrary network chunks is a reported coding question, and designing a streaming handler is a reported system design one. Build it once, and know the chunk-boundary problem.
The agent loop — Framework-specific API knowledge is far less transferable than being able to write the loop yourself.
Vector databases — Vendor comparisons are a popular time sink. The access patterns and trade-offs transfer; the feature tables do not.
Fine-tuning — For AI Engineers: learn the vocabulary and the decision framework. The training objectives and RLHF mathematics are not asked.

Start at Python, or see this route drawn on the map. The question bank covers every topic here.

The ML Engineer route The Research route