How to Become an AI Engineer: A Path With Proof

A company adds an AI assistant to its help center. In the demo, it answers well. A month later it quotes a refund policy that changed weeks ago, and nobody can say how often that happens.

An AI engineer is the person who builds that assistant so it behaves predictably, and who can show how often it still gets things wrong. They don't train the model. They build software on top of a model someone else trained.

So the fastest way in isn't a course certificate. It's one finished project with an evaluation set, meaning a fixed list of test questions with known right answers that anyone can rerun after a change.

This guide is for people who already write code or work with data. It puts what to learn in order, points to a runnable lesson for each step, and describes the project that ties them together. Postings quoted here were read on September 26, 2026.

What employers are asking for

The term took off after swyx's 2023 essay The Rise of the AI Engineer, which described a software engineer who builds with foundation models and APIs rather than training models. Chip Huyen's book AI Engineering (O'Reilly, 2025) draws the same line. It covers building apps on top of large pretrained models through prompting, choosing what context to give the model, and fine-tuning. Traditional ML engineering, by contrast, centered on preparing training data and training the model itself.

Job posts spell it out. Baseten's AI Engineer asks for "demonstrated experience building AI or LLM-powered products, agents, or agentic workflows that real users depend on" and "strong software engineering fundamentals and the ability to clear a real technical bar, not just prompt well." Its nice-to-have list includes "experience building evals, agent observability, or tooling for non-deterministic systems."

Put those three phrases together and the ask is clear. Employers want something real people use, ordinary engineering skill, and a way to measure software that doesn't give the same answer twice. Your portfolio should show all three. The AI engineer vs ML engineer vs software engineer comparison shows how postings split the work.

What you already have, and what's missing

A software engineer's instinct is to fix a wrong answer like a bug. That fixes one case and hides the other fifty. A data scientist's instinct is to measure, which is exactly right, but the measuring has to live inside a service someone can actually call.

Pick the row that fits you and spend most of your time on the last column.

What to learn, in order

Each step has a runnable lesson on this site. They use fake data and local files, so none needs a paid API key to reproduce the recorded result.

1. Call a model and handle what comes back. The AI APIs lesson sends a request, checks that the JSON response has the right shape, and tests what happens with a bad key, a rate limit and garbled output. Everything later depends on treating a model call like a network call that can fail.
2. Write down what a good answer looks like. Prompt contracts with evaluation fixtures defines three prompts with an exact expected output shape, plus twelve test cases that should pass or fail. This is where "the answer looks right" becomes something you can check.
3. Find the evidence before answering. Build a small RAG pipeline shows retrieval: pulling the right documents first and having the model answer from them. It filters out documents the user can't see and outdated ones before ranking, checks that every citation came from what was retrieved, and leaves one known miss in its results on purpose.
4. Score a whole test set honestly. Evaluate a ticket agent scores format, evidence and correctness separately, and won't drop a timeout from the total just because it's inconvenient. Then compare evaluation tools on the same ten cases before you adopt one.
5. Let the model use a tool, within limits. The tool-calling lesson keeps what the model suggests separate from what your code allows. The MCP lesson offers the same kind of tool through a standard protocol and tests what happens when requests are malformed.
6. Ship it and watch it. Deploying agents to production covers hosting, saved state, cost limits and gradual rollouts, and monitoring and debugging covers the step-by-step records you need when an answer is wrong.

Steps 5 and 6 matter more if you want agent-heavy roles. Many AI engineer postings stop at retrieval and evaluation. The agent engineer guide and how to become an agent engineer cover the version of the job built around tools and recovering from failures.

Frameworks are missing from this list on purpose. Learn one after you can explain what it replaces in the plain version. A reviewer who asks "why this framework" wants to hear the problem it solved for you.

The portfolio project

Build one project, finish it, and document it well. Pick either a document-answering app or a tool-using app. Both need the same evidence.

Option A: an app that answers from documents

Pick a small set of documents you can publish: a public product's help docs, some open government policies, or fake documents you write yourself. Twenty to fifty is enough. Give each one an ID, a version, who it's for and whether it's current, stored outside the text itself.

The app answers a question from documents the user is allowed to see and that are still current, and cites them. If it can't answer, it says so. The AI engineer career guide has a ready-made version of this with a fictional product called Harbor and eight test cases, including an outdated document and a restricted page. Start there if you want a spec to follow.

Option B: an app that uses tools

Give a model two or three tools that work on a fake system you control: look up an order, suggest a refund, open a ticket. The model suggests a call, your code checks it, and anything that changes a record waits for a person to approve. The ticket workflow capstone shows the whole thing, from a verified incoming request to a stored approval.

What either project must include

The case count is a practical range, not a standard. It's enough to show your method. It doesn't tell you how well the app works for real users, and your write-up should say that. Hamel Husain's Your AI Product Needs Evals (March 2024) argues for building these tests early and looking at the data constantly. Read it before you write your first case.

A worked example

This is made up, to show what a good write-up sounds like.

Jordan builds Option A on a fictional company's 30 help articles. The first version finds documents by matching keywords. Jordan writes 40 test questions, locks them, and runs them. The failure report says something like: "Keyword search missed 4 of 12 questions that used different words than the article. Adding embeddings fixed 3 and caused one citation to an outdated version."

That one sentence tells a reviewer more than a dashboard screenshot would. It says what was measured, on what, and what broke. The README ends with what Jordan didn't test, like how it does on real customer questions.

Show it where hiring managers look

Put the project in a public repository with the README first and the demo second. Link the failure report from your resume, not just the repository. In a screening call a hiring manager has a few minutes, and one readable table of test cases does more than a live chat demo.

If your current job allows it, do a smaller version at work: add a test set to an existing AI feature, or add tracing to a flaky one. Postings ask for products "that real users depend on." A small internal tool with real users counts for more than a polished side project with none. Describe it without sharing anything your employer wouldn't want shared.

Where to apply first

Titles vary. Applied AI Engineer at one company means a product engineer building features. At another, such as OpenAI's Applied AI Engineer, Startups, it's a customer-facing role closer to a solutions or forward deployed engineer. Read the duties before the title, and match your project to the job you want.

Postings also set a real experience bar. Baseten asks for five or more years building and shipping software. If you're earlier than that, a software engineer job on a team that ships AI features is a fine first step, and the project above still sets you apart.

Next steps

• Follow the AI engineer career path: reading order, employer-posted pay and practice prompts.
• Read the AI engineer interview guide before your first screen. Your project will come up in most rounds.
• If you're switching from a non-technical role, start with the career transition guide and the free foundations guide.