AI engineering is one of the best-paid, fastest-growing jobs in tech right now. And the door to it just got wider than it's ever been.
Most guides get this wrong. They hand you a wall of theory, tell you to master linear algebra and neural network math, and lose you by week two.
Or they bury you in 80 links with no order and no verdict, so you spend more time deciding what to study than actually studying.
I read through the popular roadmaps, tested the tools they recommend, and built the version I'd hand to a friend who's switching careers and has real work to do.
No math degree. No 4-year plan.
Four focused months, one clear pick per skill, real prompts you can copy, and the mistakes that quietly kill most career switches before they start.
Here's why I think the timing matters, then the full path.
Why the door is open (and I can prove it)
You've probably been told AI is going to take jobs.
Here's the part that gets less airtime: it's creating a specific, well-paid category of job faster than almost anything else in the market, and the usual gatekeeper is falling away.
PwC's 2026 Global AI Jobs Barometer analyzed over a billion job ads across six continents. Three findings matter for anyone thinking about a switch.
First, jobs that require AI skills are growing about eight times faster than the overall market. AI-skill roles grew 69% while the total jobs market grew 9%.
That's not a rounding error. That's a category pulling away from everything around it.
Second, the pay premium is real and rising. Workers with AI skills command a 62% wage premium over comparable roles without them, up from 57% the year before.
Companies are paying more, not less, for people who can actually build with these tools.
Third, and this is the one that changes the math for career switchers: the degree requirement is falling, and it's falling fastest for exactly these roles.
PwC found that the share of AI-augmented jobs requiring a degree dropped from 66% to 59% between 2019 and 2024.
For jobs where AI automates parts of the work, it fell further, from 53% to 44%. Employers are dropping the credential filter faster in AI-exposed work than anywhere else.
There's one more number worth sitting with. In the US, entry-level roles most exposed to AI grew 35% since 2019.
Over the same period, other entry-level roles declined 10%. The bottom rung of the AI ladder is getting wider while the rest of the entry-level market shrinks.
Now the honest counterweight, because I'm not here to sell you a fantasy.
PwC also found that AI-exposed entry-level roles increasingly ask for skills that used to be reserved for senior people: judgment, communication, the ability to own an outcome instead of a task.
The bar isn't lower across the board. It moved. It's less "do you have the credential" and more "can you actually make this work and explain why it works."
Read that as bad news if you're a fresh graduate with no work history. Read it as good news if you're switching from another career, because you already have the thing they're now asking for.
You've shipped things. You've dealt with stakeholders. You've owned outcomes under pressure.
A 22-year-old with a CS degree usually hasn't. If you pair your existing judgment with the technical skills in this guide, you're not behind the new grads.
On the axis employers care most about, you're ahead of them.
That's the switcher's edge, and almost no roadmap tells you about it. Keep it in your back pocket for the whole four months. It's the reason this is realistic for you specifically.
A quick word on the money, because you'll want the real numbers before you commit four months.
I'll give the full breakdown at the end with sources, but the short version: as of mid-2026, Glassdoor puts the average US AI engineer salary at around $143,500, with a typical range of roughly $115,000 to $181,000.
Senior roles run much higher. Recruiters placing people in production AI work report mid-level base salaries clustering between $155,000 and $200,000.
These aren't hype figures pulled from a hype thread. They're current, and I'll show you where each one comes from.
What an AI engineer actually does (the 60-second version)
Before the plan, let's kill the biggest source of intimidation, because it stops more people than any technical hurdle.
When most people hear "AI engineer," they picture someone in a lab training a giant model from scratch, surrounded by GPUs and math they'll never understand.
That's a different job. It's called a research scientist or an ML researcher, there are relatively few of them, and it usually does require the advanced degrees.
The AI engineer job that's growing eight times faster than the market is a different thing entirely.
You build products and features on top of models that already exist. You take Claude, or GPT, or an open-source model, and you make it do a specific, reliable job inside a real application.
In practice, that means you connect to model APIs, design the prompts and the context you feed them, get structured data back out, wire the model up to tools and databases, make it retrieve the right information, handle everything that can go wrong, and deploy it so real people can use it.
It sits between software engineering, product work, and applied AI. You're a builder, not a researcher.
Here's the one-line test I'd use. If you can make an LLM do a specific job reliably inside an app, and you understand enough to fix it when it breaks, you're an AI engineer. That's the whole thing.
Everything in this guide is aimed at getting you to that sentence being true about you.
You do not need to know how a transformer works internally. You do not need calculus. You do not need to be able to derive backpropagation.
You need to be a competent builder who understands how to work with these models in the real world.
That's a learnable skill, and four focused months is enough to get functional at it.
Read this before Month 1: the 4 mistakes that kill career switches
I'm putting this before the roadmap on purpose.
Most guides bury the mistakes at the end, but the mistakes that end a career switch happen in week two, not month three. If you only remember one section of this guide, make it this one.
I've watched people, including an earlier version of me, make every one of these. None of them are about intelligence.
They're about strategy. Fix the strategy and the four months actually work.
Mistake 1: Starting with theory and math.
You get excited, you want to do this right, so you go find a machine learning course and start with linear algebra, gradient descent, and the math behind neural networks.
Three weeks later you've watched a lot of lectures, you can't build anything, and you feel like an impostor. So you quit.
The fix: skip it. For the job you're targeting, you don't need to derive the math.
You need to build.
You'll pick up the concepts you actually need as you hit them in real projects, and they'll stick because they'll be attached to something you built.
Theory-first is the single most common reason smart people wash out of this. Don't start there.
Mistake 2: Watching tutorials instead of building.
This one's sneaky because it feels like progress. You watch a four-hour Python course, nod along, feel like you learned something. You didn't.
You watched someone else learn something. The moment you open a blank file, none of it is there.
The fix: the 30-minute rule. For every hour you spend watching or reading, spend at least 30 minutes building something with no tutorial open.
Type the examples yourself. Break them. Change them. Get errors and fix them. The errors are the learning.
A person who builds badly for four months beats a person who watches perfectly for four months, every single time.
Employers can see the difference in ten seconds of looking at your GitHub.
Mistake 3: Learning tools instead of skills.
You hear that LangChain is the thing, so you go deep on LangChain.
Six months later the field has moved, everyone's on something else, and your LangChain knowledge feels wasted. So you chase the new tool.
Then that one changes too. You're always behind because you're optimizing for the wrong layer.
The fix: learn the skill under the tool. The skill of writing a prompt that produces reliable output doesn't expire when a framework updates.
The skill of getting structured data from a model, or evaluating whether your system actually works, or deciding when a task needs an agent versus a single call, those transfer across every tool that will ever exist.
Learn tools as a way to practice skills, not as the goal. This guide is organized around skills for exactly this reason.
Mistake 4: Waiting until you feel ready to build in public.
You decide you'll start sharing your work, applying for roles, or offering freelance services once you're "ready."
You will never feel ready. Ready is a feeling that arrives after you start, not before.
Meanwhile the people getting hired and getting clients are the ones who started sharing rough work months before they felt qualified.
The fix: start building in public in Month 1. Post the small thing you made. Write up what you learned.
Put every project on GitHub the day you finish it, even the ugly ones.
The gap between "I'm learning" and "I'm building visibly" is where most switchers get stuck for a year. Close it early.
Nobody is watching closely enough for your early work to embarrass you, and the compounding starts the day you begin.
Keep these four in view the whole way through.
The roadmap below is designed to avoid all of them by default: skill-first, build-first, tool-agnostic, public from day one.
Month 1: Python and the plumbing
Your goal this month: become a functional Python developer who can call an API, manage a small project, and stop Googling basic syntax.
Not an expert. Functional.
Everything in Months 2 through 4 assumes you can write clean Python and work in a terminal. This is the foundation, and rushing it will hurt you later.
Here's the thing to internalize before you start: AI engineering is software engineering first. The AI part sits on top of a normal software stack.
If the stack underneath is shaky, the AI part never gets reliable. So Month 1 is about getting comfortable enough with the basics that they stop being in your way.
I'll give you one primary pick per skill, with a clear verdict on why. I'm deliberately not handing you five options per topic. Choice is the enemy of momentum.
Pick the one I point at, and only branch out if it genuinely isn't working for you.
Python
Python is the language of this entire field. Almost every library, API, tutorial, and job you'll touch over the next four months is in Python. You learn it, and everything else gets easier.
My pick: CS50P, Harvard's Introduction to Programming with Python. Free, rigorous, and it forces you to actually solve problems instead of watching someone else solve them.
The problem sets are the whole value. It's more demanding than a gentle YouTube course, and that's the point.
You want the version that makes you struggle a little, because the struggle is where the skill forms.
Find it at cs50.harvard.edu/python.
If CS50P feels too steep as an absolute beginner, the freeCodeCamp Python course on YouTube is a softer on-ramp, but treat it as a warm-up, not the main event.
Come back to CS50P once you're not scared of a blank file.
What to actually focus on, in rough order: variables and data types, loops and conditionals, functions, then the collection types (lists, dictionaries, sets, tuples).
Then file handling and reading and writing JSON, which you'll use constantly with AI APIs.
Then just enough classes and object-oriented basics to read other people's code without panic.
Then error handling with try and except.
Finally, virtual environments and pip, so you can install packages without breaking your system.
Don't try to memorize any of this. Understand it well enough to look it up fast, and build with it until it sticks.
Your Month 1 build target for Python: a small command-line tool that does something real.
An expense tracker that reads and writes to a JSON file is a good one. Or a script that calls a free public API and prints the results in a clean format.
Something with maybe 60 to 100 lines of your own code.
It doesn't matter if it's ugly. It matters that you wrote it.
Learning with AI from day one
This is where I'd do something the old roadmaps don't: use AI to learn AI, starting in week one.
You have access to the best patient tutor ever built, and it costs nothing on the free tiers. When you hit an error you don't understand, don't spend 40 minutes on a forum.
Paste it into Claude or ChatGPT and ask it to explain the error in plain English and walk you toward the fix without just handing you the answer.
Here's a copy-paste prompt I'd set up on day one. Save it.
This is the first of several artifacts in this guide worth bookmarking.
Prompt: Your Python learning partner
(Framework: FAG Learning Partner, by AI Guides)
1Your job: act as my patient Python tutor while I learn to code as a career switcher.23Context about me:4- I am learning Python to become an AI engineer.5- I am a complete beginner at coding but not at working hard.6- I learn best by doing, not by being handed answers.78What to do:9- When I paste an error, explain in plain English what it means and what10 is likely causing it. Do not just give me the fixed code.11- Point me toward the fix with a hint first. Only show the full solution12 if I ask twice.13- When I share code I wrote, tell me one thing that works and one thing14 I could improve. Keep it to those two.15- After I get something working, ask me one short question that checks16 whether I actually understood it.1718Rules:19- No jargon without a one-line plain-English definition next to it.20- Assume I want to learn, not just pass. Slightly slower is fine.21- If I am about to build a bad habit, say so directly and kindly.2223Output: conversational, short, one concept at a time.
Use that every day this month. It turns the frustrating parts of learning to code into a conversation instead of a wall.
It also gets you fluent at prompting, which is the core skill of Month 2, before you even know that's what's happening.
One caution so you don't build the wrong habit: use the AI to understand and unblock, not to write the whole thing for you.
If you let it write your code while you watch, you're back to Mistake 2.
Make it explain. You type.
Git and GitHub
Git is how developers save, version, and share code.
GitHub is where your work lives in public and becomes a portfolio.
You'll use both constantly, and for a career switcher, GitHub is the closest thing you have to a resume until you have one.
My pick: GitHub Skills. Free, interactive, and built by GitHub inside GitHub itself, so you learn the tool by using it. Start there rather than reading about Git in the abstract.
Find it at skills.github.com.
If the branching and merging model confuses you, and it confuses everyone at first, the Learn Git Branching visual tool makes it click by letting you see the branches move.
What to focus on: the core loop of init, add, commit, push, and pull. Then branching and merging.
Then what a .gitignore file does and why you never commit secrets or API keys to a public repo, which matters enormously once you're working with paid APIs.
Then how to write a basic README, because your READMEs are going to do real work in your job search later.
The habit to build this month: every project you touch, even a 20-line script, goes in a GitHub repo the day you make it.
This is Mistake 4's fix in practice. You're building in public, quietly, from the start.
By Month 4 you'll have a trail of work instead of a blank profile.
The terminal
You'll run scripts, install packages, and manage projects from the command line constantly.
Being slow or scared in the terminal is a real drag on everything else, and it's an easy thing to fix.
My pick: a short beginner terminal course to cover the basics, then just live in it. The MIT "Missing Semester" materials go deeper if you want them, but for Month 1 you only need navigation and running things.
Learn cd, ls, pwd, mkdir, and rm for moving around and managing files.
Learn cat and grep for reading and searching.
Learn how to run a Python script from the terminal and how to set an environment variable, which you'll need the moment you're handling API keys.
You don't need to become a shell wizard. You need to stop hesitating.
A week of using the terminal for everything, even things you'd normally do with a mouse, gets you there.
APIs, JSON, and HTTP
This is the bridge to Month 2.
From the first day of building with LLMs, you'll be making API calls, which means you need to understand how web APIs work before you touch OpenAI's or Anthropic's tools.
My pick: the MDN Web Docs HTTP overview for the concepts, plus the Python requests library documentation for doing it in code.
MDN explains how requests and responses work more clearly than anything else that's free.
Then requests shows you how to make those calls in Python in a few lines.
What to focus on: what GET and POST requests are and how to make them in Python.
Reading and writing JSON, which is the format every AI API speaks.
HTTP status codes and what the common ones mean, especially 200 for success, 401 for a bad API key, 429 for rate limiting, and 500 for a server error, because you'll see all of these constantly.
What an API key is and how basic authentication works.
And a light introduction to what async and await do in Python, which you'll need when you start streaming responses from models later.
Don't go deep on async now.
Just know it exists and roughly what problem it solves.
Your build target here: a Python script that calls a free public API, one that needs no key like the Open-Meteo weather API, and prints the result as clean formatted output.
This is a tiny version of exactly what you'll do all through Month 2, just without the AI part yet.
A quick note on SQL
You don't need to be a data person, but you'll regularly need to look at and query data, and basic SQL saves you constantly.
My pick is SQLBolt, which is free, interactive, and teaches you the core of SQL in about 20 short in-browser lessons.
Find it at sqlbolt.com.
Focus on SELECT, WHERE, GROUP BY, JOIN, and ORDER BY.
That's enough for now.
You can go deeper the moment a project demands it.
Month 1 milestone
By the end of the month, you should be able to write a Python program that reads and writes files, calls an API, and handles its own errors without crashing.
You should version that code with Git and have it live in a GitHub repo.
You should move around the terminal without hesitating. You should understand what an HTTP request is and make one in Python.
And you should be able to run a basic SQL query.
If you can do those things, you have the foundation.
Most people who quit never get here, and getting here is genuinely the hardest part because it's the least exciting.
It gets more fun from Month 2 on, because from here you're building with AI.
Month 2: Build with LLM APIs
Your goal this month: build real AI-powered features using model APIs.
By the end, you should be comfortable writing prompts that produce reliable output, getting structured data back from a model, making the model call your own functions, managing a conversation, and handling everything that can break.
This is the core of the whole job. Everything after this builds on it.
This is the month where it starts to feel real. You stop doing setup and start making models do things.
Take your time here.
Depth in Month 2 pays off more than depth anywhere else in the guide.
Prompting that actually works
Prompting isn't asking a chatbot a question nicely.
It's the skill of writing instructions that produce consistent, reliable output from a system that's fundamentally probabilistic.
As an AI engineer, you'll spend more time here than you'd expect, and getting good at it is the highest-leverage thing you can do this month.
My pick: Anthropic's interactive prompt engineering tutorial on GitHub. It's the most hands-on resource that exists, broken into chapters with real exercises you run against the Claude API.
You practice writing and fixing prompts yourself instead of reading about it, which, if you remember Mistake 2, is the entire point.
Find it in the anthropics/prompt-eng-interactive-tutorial repo. Once you've worked through it, Anthropic's and OpenAI's official prompt engineering docs are the reference you'll come back to.
What to focus on: the difference between a system message and a user message, and why that difference matters.
Why specificity beats politeness every time.
Chain-of-thought prompting, where you ask the model to reason step by step before answering, which measurably improves results on anything with logic in it.
Using examples inside your prompt, called few-shot prompting, to show the model the format you want.
And developing a feel for how small wording changes produce large output changes, which only comes from doing it a lot.
A build exercise that teaches this fast: take one real task, like summarizing a document or classifying a piece of feedback, and write five different prompts for it.
Run all five.
Compare the outputs side by side. You'll see immediately how much prompt design drives reliability, and that lesson sticks better than any lecture.
Structured outputs
In a real application, you almost never want a paragraph of text back from a model.
You want structured data your code can parse, store, and use. Structured outputs solve this by forcing the model to return data that matches a schema you define.
This is one of those skills that separates a demo from something that actually works inside software.
My pick: the Instructor library for Python, backed by OpenAI's and Anthropic's official structured output docs.
Instructor is the cleanest way to get structured data out of any major model using Pydantic, which is a Python library for defining the shape of your data.
It works across providers with the same code and retries automatically when the model returns something malformed.
It's close to what a lot of working engineers actually use, which makes it worth learning on real projects rather than a toy version.
What to focus on: defining a Pydantic model that describes the data you want, passing that schema to the API, and handling the case where the model refuses or returns something unexpected.
Understand the difference between true structured outputs, where the schema is enforced, and looser JSON mode, where it isn't guaranteed.
Here's your second bookmarkable artifact, a prompt pattern for reliable structured extraction that works even before you add a library on top.
Prompt: Structured data extraction
(Framework: FAG Extractor, by AI Guides)
1Your job: extract structured data from the text I provide and return it2as clean JSON.34What to do:5- Read the input text carefully.6- Pull out only the fields listed under Output below.7- If a field is missing from the text, use null. Do not guess or invent.8- Return only the JSON object. No explanation, no markdown, no preamble.910Rules:11- Every value must be traceable to something in the input text.12- Dates in YYYY-MM-DD format. Numbers as numbers, not strings.13- If the text is ambiguous, prefer null over a confident wrong answer.1415Output: a JSON object with these fields:16{17 "field_one": string or null,18 "field_two": number or null,19 "field_three": list of strings or empty list20}2122Input text:23[PASTE THE TEXT HERE]
The tested-failure note, because I promised you the honest version: the first time you do this, the model will sometimes wrap the JSON in markdown code fences, or add a friendly sentence before it, and your parser will choke.
That's normal. The fix is to strip code fences before parsing, and to be explicit in the prompt that you want only the JSON object, which the pattern above does.
Once you've hit this once and handled it, you'll handle it forever.
Your build target: a receipt or invoice parser.
Feed it raw messy text like "Invoice 123, $45.99 for 3 widgets, due March 30" and get back a clean structured object with the invoice number, amount, item count, and due date.
This is a genuinely useful little tool and a good portfolio piece.
Tool calling
Tool calling is what turns a text generator into something that can take actions: search the web, query a database, call your API, run code.
It's one of the most important skills in this whole guide, and it's the foundation of everything in Month 3.
The mental model that makes it click: the model doesn't run your functions.
It looks at the conversation, decides a tool should be used, and returns a structured request naming the function and the arguments.
Your code runs the function and hands the result back to the model. The model is the decision-maker. Your code is the hands.
My pick: OpenAI's function calling guide and Anthropic's tool use docs, read together.
The concepts are identical across both, the syntax differs slightly, and seeing both makes the underlying pattern obvious.
Then work through a runnable notebook example, like the one in the OpenAI cookbook, so you see the full loop end to end instead of in pieces.
What to focus on: describing your functions clearly in a schema, parsing the model's tool-call response, running the function and feeding the result back, and handling the case where the model decides no tool is needed.
The quality of your tool descriptions matters more than beginners expect, which is a theme that comes back hard in Month 3.
Your build target: a small assistant with three tools, like get_weather, calculate, and search_notes where search_notes just looks through a hardcoded dictionary.
Wire them all up and watch the model decide which one to call based on what you ask.
The moment you see it pick the right tool on its own, the concept lands permanently.
Conversation state and streaming
Two smaller but essential skills round out the month.
Models have no memory between calls. A conversation is something you manage by sending the full message history with every request.
Understanding this is fundamental, and it surprises almost everyone at first.
My pick is OpenAI's and Anthropic's messages documentation.
Focus on how the messages array is structured, why you append both the user's messages and the model's replies, what happens when you exceed the context window, and basic strategies for trimming old messages.
Build a simple multi-turn terminal chatbot that keeps history and has a reset command. It's small and it teaches the concept completely.
Streaming means showing the model's output as it's generated, word by word, instead of making the user wait for the whole thing.
It makes apps feel dramatically faster.
My pick is the official streaming docs from either provider, plus Simon Willison's clear write-up of how streaming works underneath.
Focus on setting the stream option, iterating over the chunks, and assembling the full response from the pieces.
For anything a real person will use, streaming is almost always the right call.
Nobody wants to stare at a spinner for ten seconds.
Cost, failure, and one security idea
Three things that separate a hobby project from something you'd put in front of users.
Cost and tokens: models charge per token, which is roughly three-quarters of a word.
Input and output tokens are priced differently.
Learn to estimate what a request will cost before you send it, keep the provider pricing pages bookmarked, and internalize one rule that saves real money: don't use the biggest, most expensive model for simple tasks.
A cheaper model is often more than good enough, and the cost difference at scale is enormous.
Failure handling: APIs fail.
Rate limits get hit, requests time out, the model returns malformed output.
Handling this gracefully is what makes something production-ready.
Learn to catch rate-limit errors and retry with a growing delay between attempts, called exponential backoff.
The Tenacity library in Python does this with a single decorator.
Learn to validate the model's output before you trust it, and never let an unexpected response crash your whole app.
Prompt injection, briefly: this is the top security risk in LLM apps.
It happens when untrusted user input gets combined with your instructions, letting a user override or hijack what your system does.
You don't need to become a security expert this month, but you need to know it exists before you ship anything.
The OWASP guide on it is the authoritative reference.
The core defenses: don't trust unvalidated model output to take consequential actions automatically, and give your tools the least access they need to do their job.
Month 2 milestone
By the end of the month, you should be able to write prompts that produce reliable output for a given task, get structured JSON out of a model with Pydantic and Instructor, wire up tool calling so a model can run your Python functions, stream a response in real time, manage multi-turn conversation history, estimate the token cost of a request before sending it, handle API errors and bad output without crashing, and explain what prompt injection is.
That's a real, employable skill set on its own.
Plenty of paid AI features in production do exactly this and no more.
But the next month is where you build the thing that actually gets you hired.
Month 3: RAG and agents, the skills that get you hired
Your goal this month: build systems that let models answer from your documents instead of only their training data, and build systems that take multiple steps on their own.
These two skills, retrieval and agents, are the most in-demand practical abilities in AI engineering right now.
Almost every real company use case, from support bots to internal knowledge tools to document analysis, is built on them.
I've compressed what a lot of roadmaps spread across two months into one, because you don't need to master every advanced variation to be employable.
You need to build one solid retrieval system and one solid agent, understand why each piece is there, and be able to debug them when they break.
That's the bar. Let's hit it.
RAG, in plain English first
RAG stands for retrieval-augmented generation.
Strip the jargon and it's simple: you give the model a library to look things up in, so it doesn't have to have memorized everything, and so it can answer questions about your specific documents.
The flow is: you take your documents, break them into chunks, convert each chunk into a list of numbers that captures its meaning, and store those.
When a user asks a question, you convert their question into numbers the same way, find the chunks whose numbers are closest, and hand those chunks to the model along with the question.
The model answers using what you gave it. That's RAG. Everything else is refinement.
Let's build up the pieces.
Embeddings
An embedding is a piece of text turned into a long list of numbers that represents its meaning.
The useful property: text that means similar things ends up with similar numbers, close together in this number-space.
That closeness is what makes search-by-meaning possible, which is the engine under RAG.
My pick for building the intuition: the Stack Overflow blog's intuitive introduction to text embeddings, which focuses on the mental model rather than the math, plus OpenAI's embeddings guide when you're ready to generate them in code.
Focus on understanding what a vector is conceptually, why similar text produces similar vectors, and roughly how you measure the distance between two of them.
You do not need the math behind how embeddings are produced. You need to know how to use them.
A tiny build that teaches this completely: take 20 sentences on related topics, turn each into an embedding, and write a small function that, given a new sentence, returns the three most similar from your set.
That's RAG in miniature. Once you've built this, the full version is just the same idea at scale.
Chunking
Your documents are too big to embed whole, so you break them into chunks before embedding.
How you chunk directly controls how well your system finds the right information.
Even a perfect retrieval setup fails if the underlying chunks are bad.
My pick: start with LangChain's RecursiveCharacterTextSplitter, with a chunk size around 500 characters and an overlap around 50.
That overlap matters, because it stops you losing meaning at the boundary where one chunk ends and the next begins.
This is the sensible default that gives you a working baseline.
The core trade-off to hold in your head: chunks too big lose precision, chunks too small lose context.
Start with the default, then adjust based on what your retrieval is actually getting wrong.
Vector databases
Once you have embeddings, you need somewhere to store and search them fast. That's what a vector database does.
My pick for learning: Chroma. It runs locally with no infrastructure to set up, which is exactly what you want while you're learning.
You don't need managed cloud scale yet, and adding it early just gives you more to configure and break.
Chroma lets you focus on the concepts.
Find it at docs.trychroma.com.
Learn to create a collection, insert embeddings along with metadata like the source and section, query by similarity to get the top matches, and filter by metadata at query time.
You do not need to understand the indexing algorithms underneath. You need to use them.
When you eventually need production scale, pgvector is the natural next step if your app already uses a Postgres database, and there are managed options when you want someone else to run it.
But that's a Month 4 or on-the-job concern. For now, Chroma, locally, is enough.
Making retrieval actually good
Basic similarity search gets you a demo.
A few refinements get you something that works reliably, and knowing these is what separates people who copied a tutorial from people who understand the system.
Metadata filtering: tag every chunk with useful information when you store it, like the source file, the date, the section, or the category.
Then filter on those at query time. This is the difference between a toy and a system where a user can ask "only show me results from the Q4 report" and actually get them.
Reranking: your first search is fast but approximate.
A reranker takes the top handful of results and re-scores them for true relevance to the question, which noticeably improves quality for a small speed cost.
The pattern is: retrieve a broad set quickly, then rerank down to the best few. Cohere's reranking docs are the cleanest place to learn this, and it's often one line to add.
Debugging retrieval, because most RAG failures are retrieval failures, not model failures.
When your system gives a bad answer, the model usually isn't the problem.
The retrieval handed it the wrong chunks.
Learn the common failure modes: the question and the relevant chunk don't match in number-space even though the info is there (fixable by rewriting the query), the relevant info is split across two chunks (fixable with more overlap), or the right chunk exists but didn't make the top results (fixable by retrieving more, then reranking down).
When an answer is wrong, check what got retrieved before you blame the model. This one habit will save you enormous frustration.
Grounding and citations: a good RAG system doesn't just answer, it tells you where the answer came from, which builds trust and makes debugging far easier.
Pass the source information for each chunk into your prompt, and instruct the model to cite it.
Here's your third artifact, the grounding prompt that keeps a RAG system honest.
This is the one I'd bookmark above all the others, because it's the difference between a system that makes things up and one you can trust.
Prompt: Grounded RAG answering
(Framework: FAG Grounding, by AI Guides)
1Your job: answer the user's question using only the provided context.23What to do:4- Read the context chunks below. Each has a source label.5- Answer the question using only information found in the context.6- After each claim, cite the source label it came from, like [source: filename, p.3].7- If the context does not contain the answer, say exactly:8 "I don't have enough information in the provided documents to answer that."910Rules:11- Never use knowledge from outside the provided context.12- Never guess. Never fill gaps with what sounds plausible.13- If the context partly answers the question, answer that part and say14 clearly what is missing.1516Context:17[PASTE RETRIEVED CHUNKS WITH SOURCE LABELS HERE]1819Question:20[USER QUESTION HERE]
That "say exactly this when you don't know" instruction is doing heavy lifting. It's the single most effective way to cut hallucinations in a retrieval system, because it gives the model an approved way to admit ignorance instead of inventing an answer to seem helpful.
Your RAG build
Use a framework to tie this together rather than building every piece from scratch.
My pick for a first RAG system is LlamaIndex, which is built search-first and gets you a working pipeline in a short amount of code.
LangChain is the other major option and shines more for the multi-step agent work coming next, so you'll meet it in a moment.
Your build target, and this is a real portfolio piece: a "chat with your documents" app.
Ingest 10 to 20 PDFs or text files, your own notes or a set of product docs work well, build something that takes a question, retrieves the most relevant chunks with reranking, and returns a cited answer.
Put a simple interface on it.
This is the project that makes hiring managers take you seriously, because it's exactly the kind of thing companies are paying to have built right now.
Agents
Halfway through the month, shift to agents.
An agent sounds like magic and is genuinely simple once you see it: it's a loop where the model repeatedly decides the next step, takes it using a tool, looks at the result, and decides again, until the task is done.
The mental model: an agent is a while loop with a model making the branching decisions.
The thinking happens in the prompt. The branching is the model choosing which tool to use. The doing is your code running that tool.
Everything else is plumbing. Once that clicks, even complicated agent frameworks become readable.
My pick, and I'd read this before writing a single line of agent code: Anthropic's "Building Effective Agents."
It's the clearest writing on how agents work in practice, from the team that builds the models.
Pair it with a hands-on framework course when you're ready to build, like the intro to LangGraph, which is the most widely used framework for orchestrating agents.
What to focus on: the loop of perceive, decide, act, observe, and how it knows when to stop.
What happens when a tool call fails inside the loop. How to write tool descriptions the model can actually use, because a vaguely described tool gets called wrong or ignored.
And managing state, which is the shared memory that flows through the agent as it works.
The single most valuable exercise this month: build a small agent from scratch with no framework at all, using just the model API directly.
Give it three tools, a goal, and a loop. This teaches you what the frameworks are hiding, and it makes every framework you touch afterward make sense.
Do this before you touch LangGraph.
When not to use an agent
This is one of the most overlooked skills in the field, and knowing it marks you as someone with judgment rather than someone chasing the shiny thing.
Agents are exciting, and they're also slower, more expensive, less predictable, and harder to debug than simpler approaches.
Reaching for the simplest thing that works is a sign you know what you're doing.
The decision framework, worth memorizing: use a single model call if the task fits in one prompt with the right context.
Use a fixed workflow, a chain of steps you define, if the steps are predictable.
Use an agent only when the number of steps is genuinely unpredictable and needs the model to decide dynamically.
A chain of three fixed calls will always be faster, cheaper, and easier to debug than an agent that might make three calls. Reserve agents for genuinely open-ended tasks.
Between a single call and a full agent is a large, productive middle ground: workflows.
Chaining, where one call's output feeds the next.
Routing, where you classify the input and send it to a specialized handler.
Parallelization, where you run several calls at once and combine them.
Most real problems are best solved with a workflow, not an agent, and Anthropic's agents piece covers these patterns well.
Evals, briefly but seriously
You need to know whether your system actually works, not just whether it worked on the two examples you tried by hand.
That's what evaluations are for. Build a small set of 20 to 30 representative inputs with expected outputs or a scoring rubric, and run your system against all of them whenever you change a prompt, swap a model, or adjust your retrieval.
Tools like DeepEval for general use and Ragas for RAG specifically make this manageable.
The mindset that matters more than the tool: every prompt change or model swap you make without running evals is a gamble.
The people who ship reliable AI run evals constantly, and starting this habit now, even in a small way, puts you ahead of a lot of people already working in the field.
Month 3 milestone
By the end of the month, you should be able to explain what an embedding is and why similar text produces similar vectors, chunk a document sensibly, store and query embeddings in a vector database with metadata filtering, add reranking to improve results, debug a retrieval failure instead of blaming the model, build a complete RAG pipeline that returns grounded cited answers, implement an agent loop from scratch, decide correctly whether a task needs a single call, a workflow, or an agent, and run a basic eval to check your work.
That's the employable core.
If Months 1 through 3 are solid, you can build the things companies are hiring for.
Month 4 is about proving it and getting paid.
Month 4: Ship it, show it, get hired
Your goal this month: take everything you've built and make it real, then turn it into a job or paid work.
This is where most people stall.
They can build a demo but can't ship something that survives real use, and they can't convert their skills into income.
This month fixes both. It's shorter on new concepts and heavier on doing, because at this point doing is what matters.
Enough deployment to be dangerous
You don't need to become an infrastructure expert.
You need to be able to put a working AI app somewhere real people can use it, without it falling over or bankrupting you.
The minimum viable knowledge: learn enough Docker to package your app so it runs the same everywhere, which kills the "works on my machine" problem.
Learn to deploy that container somewhere.
And learn the cost and reliability basics that stop a bug from becoming a disaster: set hard spending limits on your API accounts, add caching so you're not paying for the same request twice, and add rate limiting so one user can't run up your bill.
Docker's official getting-started guide covers the packaging.
For the AI-specific cost side, the core moves are caching identical requests, using cheaper models where they're good enough, and setting a hard monthly spend cap so a runaway loop can't cost you $500 overnight.
You also want basic observability, which is a fancy word for being able to see what your app is doing.
LLM apps have a specific problem: the model can return a perfectly successful response that's also useless or wrong, and normal monitoring won't catch that.
A tool like Langfuse traces every model call, showing you the prompt, the response, the token cost, and the latency, which makes debugging and cost control far easier.
Set this up on one project so you understand the pattern.
Don't over-invest here.
One app, deployed properly, with cost controls and basic tracing, teaches you everything you need and gives you something real to show.
Depth in deployment can come on the job.
The part every other roadmap skips: turning projects into a job.
You've built three real projects. Now make them work for you, because a great project nobody sees does nothing for your career.
Your portfolio is three deployed projects, each with a README that does actual work.
And here's the move almost nobody makes, the one that will set you apart: in each README, include a section on what went wrong and what you'd do differently.
Most portfolios pretend everything worked perfectly, which reads as either dishonest or shallow.
A README that says "here's where my first approach failed, here's what I learned, here's how I fixed it" signals exactly the judgment employers said they're now screening for.
It's the switcher's edge from the intro, made visible.
Nobody expects a career switcher to have a perfect project. They're impressed by one who clearly understands their own work deeply enough to critique it.
Structure each README like this: the problem the project solves, who would use it, the approach you took and why, what went wrong and what you learned, and how to run it.
Five sections.
That's a better portfolio than most people with a CS degree have.
The resume and profile move: you don't need to pretend you have years of experience.
You need one clear line that says what you can do.
Something like "I build production LLM applications: RAG systems, agents, and API integrations. Here are three I've shipped."
Then link the projects. Your existing career is an asset, not something to hide.
"Former [your field] who now builds AI systems" is a stronger story than "junior developer," because it comes with the domain knowledge and judgment that a pure junior lacks.
If you're switching from finance, you understand finance problems an AI could solve.
If you're switching from healthcare, same. Lean into it.
Building in public as your pipeline: through this whole month, keep posting what you build and what you learn.
The best opportunities I've seen come to people who were visible, not to people who quietly applied to 500 listings.
Write up your projects. Share the mistake you fixed. The compounding is real, and by now you have real work to share, so it's easier than it was in Month 1.
Pick a direction
By Month 4 you can point your skills at whatever fits your goals. Three directions, pick one to go deeper on rather than spreading thin.
The AI product engineer path, best if you want a startup job fast: you build AI-powered products real users touch.
You already have most of this from Months 1 through 3.
Go deeper on building complete, polished apps and on the product side, meaning how the app handles the model being wrong, how it shows loading states, how users give feedback.
Ship two or three things people can actually try.
The applied ML path, best if you want deeper technical roles: go beyond API calls into fine-tuning, when to fine-tune versus just prompt better, running open-source models locally with a tool like Ollama, and inference optimization.
The decision framework to hold onto: start with prompting, add retrieval if the model needs your specific data, and only fine-tune when prompting and retrieval genuinely can't hit the quality you need.
Fine-tuning is often reached for too early.
The AI automation path, best if you want to earn from businesses immediately: focus on automating real business workflows, chaining AI across tools like email, CRMs, documents, and spreadsheets.
Tools like n8n for visual workflows and LangGraph for the code-heavy ones.
A sellable build here: a lead-qualification system that pulls in leads, uses a model to research and score each one, drafts personalized outreach, and logs everything.
Businesses pay real money for exactly this.
Month 4 milestone
By the end of the month, you should have a deployed AI app with proper cost controls, three portfolio projects each with an honest README, a clear one-line pitch of what you build, a visible trail of work in public, and a chosen direction you're going deeper on.
At that point you're not "someone learning AI." You're someone who ships AI systems, which is the thing the market is paying for.
The honest part
I told you at the start I wasn't going to sell you a fantasy, so here's the straight version before the money numbers.
Four months of focused work makes you employable at a junior level or ready to take freelance work. It does not make you a senior engineer.
Senior comes from years of shipping real things under real constraints, and no guide compresses that.
What four months buys you is the ability to build, ship, and deploy AI systems that solve real problems, which is a genuinely valuable and genuinely hireable place to be.
This assumes real work, roughly 15 to 20 hours a week, actually building and not just watching.
If you can only give it 7 hours a week, this is an 8-month path, and that's completely fine.
The timeline stretches, the destination doesn't change. What kills people isn't a slow pace. It's stopping.
Consistency beats intensity here every time.
And the whole thing rests on one behavior from the mistakes section: build, don't just watch.
Every month has a project. Do the projects. A person who builds four rough projects in four months is employable.
A person who watches four months of perfect tutorials is not. That's the entire game.
The money, with sources
Now the numbers you actually want, all current and all sourced, because loose salary claims are how these guides lose credibility.
As of June 2026, Glassdoor puts the average US AI engineer salary at roughly $143,500, with a typical range of about $115,000 at the 25th percentile to $181,000 at the 75th, and top earners reported up to around $223,000.
Senior AI engineers average around $285,000, with a typical range of roughly $221,000 to $375,000, which shows how steep the jump is once you have real experience.
Those are Glassdoor's figures based on submitted salaries.
Recruiters who place people in genuine production AI work report mid-level base salaries clustering between $155,000 and $200,000, based on signed offers rather than surveys, which lines up with the Glassdoor range and gives you a second independent read.
And the broader market backdrop from PwC's 2026 Barometer, which I opened with: AI-skill jobs growing about eight times faster than the overall market, a 62% wage premium for AI skills, and degree requirements falling fastest in exactly these roles.
Those aren't from a hype thread. They're from an analysis of over a billion job ads.
Freelance and consulting numbers vary too much to quote precisely without misleading you, so I'll say only this: the rates for RAG implementation, agent building, and LLM integration are high, and a switcher with three solid deployed projects and a clear pitch can start charging for that work well before they'd land a full-time role.
The projects are the proof. Build them and the earning options open up.
Start this week
Here's what I'd actually do, today, if I were you.
Pick the Month 1 Python project, the little command-line tool. Open a code editor.
Start CS50P's first problem set. Set up the learning-partner prompt so the AI tutors you through the frustrating parts.
Make a GitHub repo and put your first ugly file in it. That's the whole first week.
Don't wait until you feel ready, because ready comes after you start, not before.
Don't map out all four months in perfect detail before you write a line of code, because the plan is already here and the planning is just a comfortable way to avoid starting.
The gap between learning and building is where people lose a year. Close it this week.
Four months of real work genuinely changes what's possible for you.
The door is more open than it's been at any point before now, the credential barrier is falling, and the market is paying more for these skills than almost anything else in tech.
You have the guide. The only variable left is whether you build.
Save this and come back to it each month as you go. I'll keep it updated as tools and numbers change.
Follow @free_ai_guides for the updates ❤️
