Software Engineer to AI Engineer: A 3-Month Roadmap

If you're a software engineer trying to move into AI as fast as possible, this is the three-month plan I'd follow. I've worked with over 400 people on moving into AI and ML roles, and I can tell you that the standard roadmap doesn't work for people coming from software engineering.

The plan is simple: month one, build and deploy one small AI feature. Month two, learn evals and turn it into a real agent. Month three, get that proof in front of the right people. Along the way you close the four gaps I see most often in software engineers: model behavior, context engineering, agentic systems, and evals.

The short version

When	Goal	What you do
Before you start	Know your gaps	Model behavior, context engineering, agents, and (most of all) evals
Month 1, week 1	One model call	Pick a problem close to your job. Call the provider's SDK directly, no framework
Month 1, week 2	One tool	Add a single tool-calling loop. Decide what needs approval
Month 1, week 3	Retrieval	Let the feature search your documents. Simplest search first
Month 1, week 4	Deploy	Put it where someone else can use it. Add tracing. Only then try a framework
Month 2, weeks 5–6	Learn evals	Read traces, label failures, turn them into pass/fail checks
Month 2, weeks 7–8	A real agent	Multi-step agent with a hard step limit, covered by your eval suite
Month 3	Get hired	Become the AI person on your team, or apply elsewhere at the right level

I've also turned this whole plan into a free week-by-week checklist so you can track where you are.

Why the standard AI roadmap doesn't work for software engineers

Most roadmaps assume you're starting from zero. If you've already spent years building software, following one from the beginning can mean wasting 6 to 12 months on linear algebra and PyTorch you won't even use. Meanwhile, tech companies are actively hiring engineers to build production AI systems today.

What you need is a targeted path that fills the important gaps in your experience. Because for the roles we're talking about, your software engineering background already covers a lot:

• If you've handled slow third-party APIs, you already know why we need timeouts, retries, and fallbacks around model calls.
• If you've debugged a request across several services, you have a starting point for tracing an agent through its model calls and tools.
• You probably already know Python, or you can learn it super fast.
• And stuff like testing, deployment, permissions, cost, and system design all still matter for AI engineering.

How AI engineering is different from software engineering

But don't make the mistake of thinking that because you have all of these skills, you're already prepared for AI engineering roles.

I've heard people say that AI engineering is just calling a different API. I can guarantee you that you won't be getting job offers if you approach the transition like that.

And to be clear, using AI to write software is also not AI engineering. Everything becomes a lot more complicated when you're not writing traditional software with AI, but instead designing systems around AI models. When a model is part of the product itself, you're also responsible for its decisions.

Let's say you've built a support assistant. A customer asks for a refund, and the model says, "Sure, you can have your $500 back. No problemo."

The app might have worked exactly as intended from a software engineering perspective. But the answer could still be completely wrong.

There's actually a lot going on under the hood that you need to understand to be able to fix situations like this.

The four skill gaps software engineers need to close

Let me break it down into four groups of skills I see as common gaps for software engineers. The last one is particularly important.

1. Model behavior

You need to understand tokens, context windows, and generation settings well enough to explain what the model can see and why its output can vary. For the customer support bot, maybe your settings made the response less predictable, or you asked the model to generate an amount that should have been calculated by code.

2. Context engineering

Even perfect settings won't help if the model is working with the wrong information. Maybe both the old refund policy and the current one are in your documents, and the system retrieved the old version. That's a context engineering problem. You need to control the instructions, retrieved data, tool results, and conversation history the model sees at each step.

3. Agentic systems

Retrieving the right policy is only half the problem. What happens when the model needs to interact with your database and actually process the refund?

That's where agentic systems come in. You need to understand how the model requests a tool, how your code executes it, and how the result returns to the conversation. More importantly, you need to understand security and guardrails. Your assistant shouldn't be able to call issue_refund for $500 without a person approving it.

4. Evals

Because things will go wrong. And to be able to fix things before they break stuff for users, you need evals. This is where I'd spend the most time.

An eval checks whether the system does the job you built it for. In our example, valid JSON is one check, and getting the right refund policy might be another.

That just sounds like testing, right? No big deal?

The tricky thing is that AI systems often can't be tested with easy yes/no answers. They're non-deterministic and often subjective. We'll talk a lot more about evaluation in month two.

So those are the four gaps: model behavior, context engineering, agents, and evals. The real question is where you build that foundation fast, without wasting six months on things you don't need.

Month 1: build and deploy one small AI feature

By the end of this first month, you're going to have one small AI feature with at least one tool, deployed somewhere another person can mess around with it.

And I really do mean small. The goal isn't to build an entire AI startup in four weeks. It's to go through the full process once, because that's how you find out which parts you understand and which parts you only recognize from tutorials you've watched.

Week 1: one model call, no framework

Pick a problem that's close to your current job or your existing stack.

Maybe you build an assistant that reads an error report and suggests the right runbook. Or you could keep going with our support example and build something that recommends whether a customer qualifies for a refund.

Call the model directly using the provider's SDK at first. Don't use a framework yet. You need to understand what's happening inside one model call before you add another layer on top.

Week 2: one tool

Give it just one tool.

For the refund assistant, that tool could look up the customer's order. The model requests the tool, your code validates and executes the request, and the result goes back to the model.

You can write a tiny MCP server for this, or connect to an existing one. Just don't turn the week into collecting twenty tools you don't need. You're trying to understand one complete tool-calling loop, including what the model is allowed to do and which actions need approval.

At this point, your feature can reason over one prompt and fetch live information. But it still doesn't know anything that isn't in the model or returned by that tool.

Week 3: retrieval

Start by letting the feature search your documents. Try the simplest search that could work first. If the results are bad, then try different things: add a vector store, look at how you split the documents, or try a different embedding model. Approach it systematically until you gain intuition for why something works or doesn't work. That's how you really make it stick.

Week 4: deploy it

Put it somewhere another person can use, even if that's just a basic internal page or a tiny hosted app. Then add tracing so you can inspect each model call and tool call instead of guessing what happened.

Only after all of that would I try a framework. Pick one that fits your stack and move the feature onto it. If the framework makes the code easier to understand, great. If it just adds a bunch of abstractions to a feature that already worked, you've learned something useful too.

By the end of the month, you've built the full path from model call to tool use, retrieval, tracing, and deployment. Nice!

All of that probably felt pretty manageable to you as a software engineer. The next month is where things start getting harder if you come from a traditional engineering background.

Month 2: learn AI evals and build a real agent

Month two is focused on the number one skill that separates the engineers who succeed in this transition from those who don't.

Because right now, your feature probably works most of the time. Then the same input gives you a different answer, or the agent calls the wrong tool, or it gets stuck repeating the same step.

One senior backend engineer in my learning community described this as getting out of his "deterministic-engineering comfort zone."

As a software engineer, you're used to reproducing a bug, fixing it, and writing a test that passes every time after that. With AI systems, one successful run doesn't tell you very much. AI evaluations are their own special thing.

How to get good at AI evals

Here's the method I'd use:

1. Read the traces yourself. Collect a diverse set of around a hundred traces and personally label at least the first thirty. Keep going until you stop finding new kinds of failures. This process is called error analysis, and it's something we do all the time in machine learning. For the refund assistant, maybe it retrieved an outdated policy. Maybe it found the correct policy but applied it to the wrong customer plan. Or maybe it kept searching even though it already had enough information.
2. Turn each important failure bucket into a pass-or-fail check. Ask specific questions. Did it use the current policy? Did it calculate the correct amount? Did it request approval before taking action? Did it finish without exceeding the step limit?
3. Use code for anything code can check. You don't need another model to tell you whether a tool received valid arguments.
4. Use an LLM as a judge only for checks that require judgment, and only after comparing it with your own labels. Give the judge examples you've already scored yourself and check where you disagree. If it passes answers you know are wrong, your rubric probably needs work.
5. Keep a human in the loop. Realistically, this is completely normal. A lot of top teams use human review as part of their workflows. You don't need to automate every evaluation before you understand what a good answer looks like.
6. Run each task several times. Anthropic recommends starting with around 20 to 50 tasks drawn from things your agent has actually failed at. Include successful cases too, so fixing one problem doesn't break something that worked before. If the refund assistant follows the policy four times and promises an unauthorized refund on the fifth, that task is not reliable. An average score can hide the exact failure you care about.

Once you have all that set up, when you change the prompt, model, retrieval, or tools, you can rerun the whole suite and see if anything broke.

Weeks 5–6: evaluate the feature from month 1

Use the feature you built in month one. Read the traces, label the failures, and build your first checks around the problems you find.

Weeks 7–8: turn it into a multi-step agent

For the refund assistant, you could add a tool that looks up the customer's plan using sample account data. The agent now has to gather the order details, find the correct policy, decide whether the refund qualifies, and either draft a response or hand the case to a person.

Keep predictable steps in code. Give the model the decisions that actually need flexibility, and set a hard limit on how many steps it can take.

Then add those new behaviors to your eval suite from the start. Run it whenever you change the prompt, model, retrieval, or tool behavior.

By the end of the month, you should be able to show a failure, explain the change you made, and prove that the agent became more reliable across repeated runs.

As you work on your project, make sure to document it. Make a nice README, put it on your portfolio site, and show proof that you know what you're doing beyond the surface level.

Month 3: get the proof in front of the right people

In the last month, we're going to get ourselves some interviews, and hopefully be ready for a new role.

By the end of the month, you want one of two things: either you're starting to do AI work at your current company, or you're actively applying elsewhere with a clear story about why your software engineering experience belongs on an AI team.

Path 1: become the AI person on your current team

Your company already knows your work, and you already understand its systems and users. Companies increasingly expect every engineer to know how to work with AI, but there's still a place for people who are experts at it on most teams.

That's your opening. If your team already has an AI feature, offer to evaluate it. Bring in the process you used in month two: read the traces, label the failures, build checks, and measure whether changes help.

If there isn't an AI feature yet, propose a small one around a problem the team already cares about. Bring them a specific problem you know the company has and propose a reasonable solution. That's how you start becoming the AI person on the team.

Path 2: apply elsewhere, at the right level

The good news is that your existing experience is a huge advantage here. Senior roles have driven most of the recent growth in software development job postings, while entry-level roles make up less than 5%.

So don't present yourself like you're restarting your career, even though you may be new to AI engineering. Describe yourself at the right level. Something like "software engineer building AI applications" is much better than "aspiring AI engineer." You're not a new grad, even though you're trying to change titles.

Target roles where your background makes sense. A backend engineer might focus on AI infrastructure or services. Or if you enjoy working directly with customers, forward deployed engineering is another option to consider.

Make it extremely clear to recruiters what roles to consider you for. Keep your experience section close to your official job titles, but on LinkedIn, use your headline and summary to make the AI direction obvious.

Use your network

Then make use of the biggest advantage you have as a software engineer: your network.

Tell former coworkers and managers what you're moving toward. Reach out to people on AI teams and ask for feedback on your project. When there's a relevant opening, ask for the referral.

Don't rely entirely on applications. Send specific cold outreach to people working on problems related to your project. Give them a reason to look at your work and have a normal conversation.

That's how you avoid becoming one of those people who sends a thousand applications and never hears back.

By the end of the month, you want a deployed AI system, evidence that you didn't approach it like just another API call, and people who understand why your experience makes you useful to their AI team.

What to learn next

But how do you choose a project that actually proves you can do the job? In this video, I break down five levels of AI engineering projects and which ones are most likely to help you get hired.

And if you want help building your own production-ready project, I run a small, application-only build cohort where I personally work with a handful of people over eight weeks to take an AI Engineering project all the way through deployment.