Skip to content
Guides

How to become an AI engineer

AI engineering and machine learning are different jobs that share a word. A machine learning engineer trains models. An AI engineer builds products on top of models somebody else already trained, and the hard parts are retrieval, evaluation, cost, latency and failure handling rather than calculus.

This matters because most people who want the second job start studying for the first, spend two months on linear algebra and gradient descent, and quit before touching anything they will actually use. The prerequisite for AI engineering is being a competent engineer, not being a competent mathematician.

01 / What the job actually involves

You call an API and get back text that is usually right. Everything that makes it a job comes from that word usually. The model will occasionally be confidently wrong, the context window will fill up, the latency will be inconsistent, the cost will scale with usage in a way nobody budgeted for, and none of these fail loudly.

So the work is scaffolding. Getting structured output you can rely on rather than prose you have to parse. Retrieving the right context so the model has what it needs. Measuring whether a change made things better, which is far harder than it sounds when the output is not deterministic. Handling the case where it goes wrong in a way a user can live with.

The models keep changing and this scaffolding does not. That is why it is worth learning as engineering rather than as a set of tips for whichever model is current.

02 / The order that works

24 days of this path, in sequence

Retrieval comes before agents deliberately. An agent is a loop around a model that calls tools, and debugging one when you do not yet understand why retrieval returned the wrong chunk is how people conclude the whole field is unpredictable magic.

DAY 67 TO 76LLM APIs, structured output, embeddings, and retrieval
  1. 67What a language model actually is, for engineers
  2. 68Tokens, context windows, and cost
  3. 69Calling an LLM API, end to end
  4. 70Prompting and context engineering
  5. 71Structured outputs and schema validation
  6. 72Streaming, latency, fallbacks, and routing
  7. 73Embeddings and vector similarity
  8. 74Chunking, indexing, and retrieval
  9. 75RAG, and every way it fails
  10. 76Debug a broken RAG system
DAY 77 TO 90Agents, tool calling, MCP, evaluation, and guardrails
  1. 77Tool calling: letting a model call your functions
  2. 78Tool schemas, validation, and tool errors
  3. 79The agent loop
  4. 80Workflow or agent, and when an agent is wrong
  5. 81Agent state, memory, and persistence
  6. 82Human in the loop and approval flows
  7. 83Multi-agent systems, and what they cost
  8. 84MCP, and what it standardizes
  9. 85MCP servers, resources, and trust boundaries
  10. 86Evaluating AI when normal tests don't work
  11. 87RAG evals and agent evals
  12. 88Tracing, observability, and cost monitoring
  13. 89Guardrails, prompt injection, and tool security
  14. 90Take apart a full AI system, end to end

Every one of those days is free to read in full. See all 90.

03 / Where people go wrong

  1. 01

    Studying machine learning first

    The single most common way to never start. Backpropagation, loss functions and gradient descent are genuinely interesting and almost entirely irrelevant to building a product on an existing model. If you want to train models later, that knowledge will still be there. Front-loading it mostly buys you two lost months.

  2. 02

    Building an agent before understanding retrieval

    Agents are the exciting part, so they get built first. Then they fail in ways that are impossible to diagnose, because the failure is usually that retrieval returned something plausible and irrelevant three steps back. Understand the retrieval layer and most agent debugging becomes ordinary debugging.

  3. 03

    Shipping without any evaluation

    Non-deterministic output makes conventional testing feel impossible, so people skip it and rely on trying a few prompts by hand. Then a prompt change fixes one case and silently breaks nine, and nobody notices for a month. A crude eval set of thirty real examples beats sophisticated intuition, and it is a day of work.

  4. 04

    Treating prompt engineering as the whole job

    Prompting matters and is maybe a tenth of it. The rest is what surrounds the call: what context you retrieved, what you do when the output does not parse, what it costs at a hundred thousand calls a day, what the user sees when the model is wrong. Roles that are only prompting are the ones being automated first.

04 / How long it takes

Twenty-four days at two to three hours, which is the span above, assuming you can already write and debug a backend service. If you cannot, that is a real prerequisite rather than a formality, because almost every AI engineering failure is an ordinary engineering failure wearing an interesting hat.

At the end you can build a retrieval system that works on your own documents, get structured output you can depend on, wire up tool calling and MCP, evaluate whether a change helped, and put guardrails around the parts that can go wrong in public.

05 / Common questions

Do I need machine learning to be an AI engineer?
No. You need to understand what a model does well enough to predict how it fails, which is a different and much smaller body of knowledge than knowing how to train one. If you later want to fine-tune or train, that is a separate path you can take afterwards.
Do I need maths for AI engineering?
Almost none. You need to understand what an embedding is and why cosine similarity finds related text, which is a concept rather than a calculation. There is no calculus, no linear algebra beyond intuition, and no statistics coursework.
Is AI engineering just prompt engineering?
No, and the pages that say so are why people are underprepared for the job. Prompting is one component. Retrieval, structured output, evaluation, cost control, latency and failure handling are the rest, and they are ordinary engineering problems.
What should I learn before AI engineering?
Be able to build and debug a backend service that talks to a database and an external API. That is the real prerequisite. The first sixty-six days of this path exist to get you there if you are not there yet.

The whole path is free and public.

Read the roadmap, open any day, and decide for yourself. Signing in is only so ninety days of progress survives a cleared browser.

See the 90 daysHow a day works