Learning Path for an AI Engineer: A 9-Month Plan, Phase by Phase

8 min read ยท 2026-10-13

A good learning path for an AI engineer starts by building on top of existing models and then goes deeper. The order is Python and APIs, LLM basics, retrieval, evaluation, agents, machine learning foundations and finally production. If you already write code, the 9-month plan below is built around 7 phases at about 8 to 10 hours a week. Each phase ends with a milestone you can check.

This path is top-down. You don't spend months on theory before building anything useful. You ship a small AI feature in the first weeks, then learn the math and the model internals when your project needs them. It suits developers, data analysts and technical product people who can already read and write basic code.

The roadmap at a glance

Goal: Build, test and deploy LLM-powered applications with the skills of a working AI engineer. Duration: 9 months, about 8 to 10 hours a week

  1. Python and APIs for AI work (Month 1)

    Get fluent in the Python you will use every day in AI projects.

    • Practice functions, classes, type hints and virtual environments with small daily scripts.
    • Call REST APIs with requests or httpx, and handle errors, retries and timeouts.
    • Work with JSON, environment variables for API keys and basic async code.
    • Use Git for every exercise and push it to a public repository.

    Milestone: A command-line script that calls a public API, handles failures and sits on GitHub with a clear README.

  2. LLM fundamentals and prompting (Month 2)

    Understand how language models behave and how to control their output.

    • Learn tokens, context windows and temperature, and why models sometimes make things up.
    • Call a hosted model API and compare system prompts, few-shot examples and output formats.
    • Get structured JSON output and validate it with Pydantic.
    • Log token usage for every request so you understand cost from the start.

    Milestone: A small app that turns messy text such as emails or meeting notes into validated JSON, with 10 test inputs that all parse.

  3. Retrieval and your own data (Months 3 to 4)

    Make the model answer from documents it was never trained on.

    • Learn embeddings and similarity search by building a tiny search over 50 documents.
    • Set up a vector store such as pgvector or Chroma, and chunk the same documents in two different ways.
    • Build a retrieval-augmented generation (RAG) pipeline that cites its sources.
    • Add hybrid search (keywords plus vectors) and compare results on the same questions.

    Milestone: A question-answering app over a real document set that shows the source passage for every answer.

  4. Evaluation and testing (Month 5)

    Measure quality instead of judging answers by feel.

    • Write a test set of 30 to 50 questions with expected answers for your RAG app.
    • Score retrieval (did the right chunk come back?) separately from the generated answer.
    • Try model-graded evaluation and check a sample of its scores by hand.
    • Run the evaluation automatically after every change, like unit tests.

    Milestone: A short report showing how one change (chunk size, prompt or model) moved your scores up or down.

  5. Agents and tool use (Month 6)

    Let the model take actions through functions you control.

    • Learn function calling: describe tools, read the model's calls and return results.
    • Build an agent with 2 or 3 tools, such as web search, a calculator and a database query.
    • Add limits: a maximum number of steps, a list of allowed actions and a human approval step for risky ones.
    • Log every step so you can replay a failed run.

    Milestone: An agent that completes a multi-step task, keeps full logs and stops cleanly when a tool fails.

  6. Machine learning and fine-tuning foundations (Month 7)

    Learn what happens under the hood so you can pick the right fix.

    • Review the linear algebra and probability behind embeddings and training, only as deep as you need.
    • Train a simple classifier with scikit-learn and read its precision and recall.
    • Follow a PyTorch tutorial that trains a small neural network from start to finish.
    • Fine-tune a small open model with LoRA on a narrow task and compare it with prompting.

    Milestone: A written comparison of prompting, RAG and fine-tuning on the same task, backed by your own evaluation scores.

  7. Production and deployment (Months 8 to 9)

    Ship your project the way a team would run it.

    • Wrap the app in an API with FastAPI and package it with Docker.
    • Deploy it to a cloud host and add logging, tracing and cost tracking.
    • Add guardrails against prompt injection, and keep secrets and personal data out of prompts.
    • Cache repeated calls, stream responses and set a fallback for when a model provider is down.

    Milestone: A live, monitored app with a public demo, a README that explains your design choices, and an evaluation report.

Who this learning path is for

This plan assumes you can already program. You don't need to be a senior developer, but you should be able to write a function, read an error message and install a package without a tutorial. If that is not true yet, spend a month or two on general Python first, then start at Month 1.

Before day one, check that you have:

  • Basic Python or another language you can switch from quickly.
  • Comfort with the command line and Git.
  • High school algebra. You will build on it in Month 7.
  • A small budget or free credits for model API calls, plus a laptop that can run Docker.

Why this path starts with building, not theory

There are two ways to learn this field. Bottom-up starts with math, then classic machine learning, then deep learning, and you reach language models many months later. Top-down starts with building products on top of existing foundation models. This path is top-down because it lets you build useful things early, and every later topic gets a concrete reason to exist.

Theory still matters, so it comes in Month 7 instead of Month 1. By then you have hit real problems: retrieval that misses the right chunk, answers that drift and costs that climb. Embeddings, loss functions and fine-tuning make far more sense when you already know which problem they solve. If you want to train models for a living, put more weight on Month 7 and stretch it out. That is closer to machine learning engineering.

One project that grows with every phase

Pick one project in Month 1 and keep growing it until Month 9. Ten small demos show that you can follow tutorials. One project with many layers shows that you can build and run a system. Choose a field you know well, because you will need to judge whether the answers are good.

Good choices include a study assistant for your own course notes, a contract clause finder or a recipe planner based on what is in your fridge.

Here is how a support assistant for a software product's documentation would grow:

  • Month 1: a script that downloads and cleans the documentation pages.
  • Month 2: a prompt that answers one question from a pasted page and returns structured JSON.
  • Months 3 to 4: full RAG over all the pages, with citations.
  • Month 5: a test set of real support questions and an automatic score.
  • Month 6: tools to look up a ticket status or open a new ticket.
  • Month 7: a fine-tuned small model for sorting incoming questions, compared with prompting.
  • Months 8 to 9: a deployed API with monitoring, cost tracking and a public demo.

A weekly rhythm that fits around a job

Eight to ten hours a week is enough if those hours are protected and planned. It is easy to stall if every session is spent watching videos and nothing gets built. A fixed weekly pattern stops that from happening.

Keep a short learning log in your repository. One paragraph per week is enough. It becomes your best interview material, because it shows how you think through problems.

A simple split to start from:

  • Two learning sessions of about 90 minutes for a course, docs or a paper on this phase's topic.
  • Two building sessions of about 2 hours to apply it to your project right away.
  • One review session of about 1 hour to update your README, write down what broke and plan next week.

How to know you are ready for the next phase

Finishing a course is not the same as being ready to move on. Use the milestone of each phase as the main check, then run three quick tests before you move forward.

If you fail one test, add a week to the phase. Taking an extra week is easier than carrying a gap into retrieval or agents, where problems pile on top of each other.

  • Explain it: can you describe this phase's core idea to a non-technical friend in two minutes?
  • Rebuild it: can you rebuild the milestone from an empty folder using only the official docs?
  • Break it: can you name one way your milestone fails and show how you would detect it?

Common mistakes to avoid

  • Spending months on math before writing any AI code, when you can learn it in Month 7 once you have a reason to.
  • Collecting courses instead of finishing projects. Take one course per phase at most and spend the rest of your time building.
  • Judging output by reading a few answers, when a test set from Month 5 should judge every change.
  • Chasing every new framework. Learn the raw model API first and add a framework only when it removes real work.
  • Ignoring cost and security until the end. Track tokens from Month 2 and treat all user input as untrusted from your first agent.
  • Building many shallow demos. Grow one project so your portfolio shows a complete system.

Frequently asked questions

Can I follow this learning path while working full time?

Yes. The plan is sized for about 8 to 10 hours a week, which you can fit into evenings and one weekend block. If you have less time, keep the phase order and stretch each phase. Changing the order causes more problems than slowing down.

Should I learn machine learning theory before working with LLMs?

Not for this path. You can build useful LLM applications with Python and solid testing habits, then learn the theory once you know why you need it. If your goal is research or training models, flip the order and start with math and classic machine learning.

What is the difference between an AI engineer and a machine learning engineer?

An AI engineer mostly builds applications on top of existing models, using prompts, retrieval, tools, evaluation and deployment. A machine learning engineer focuses more on training, tuning and serving models, and on the data pipelines behind them. The two roles overlap, and this path covers the shared foundations in Month 7.

Which programming language should an AI engineer learn?

Start with Python, because model APIs, ML libraries and evaluation tools all offer Python support. TypeScript is a useful second language if you build web front ends or work in a JavaScript team. Learn SQL alongside them, because many apps read data from databases.

What should I build to show my skills at the end?

Show one deployed project with retrieval, an evaluation report, at least one agent feature and monitoring in production. Add a README that explains your trade-offs, such as why you chose RAG over fine-tuning for a given task. That shows more than a stack of certificates.

Generate this roadmap with AI