A 12-month roadmap to AI Engineer, no Computer Science degree required

You don't need a Computer Science degree to work in AI. What decides it is what you can ship.

How an AI Engineer differs from an ML Researcher

An ML Researcher invents and trains new models. The job needs heavy math and advanced degrees, and it is a very thin slice of the market.

An AI Engineer takes existing models (Claude, GPT, open-source models) and builds products that work: a support bot that actually closes tickets, an internal search that finds the answer among ten thousand documents, an agent that runs a whole multi-step workflow without anyone watching it.

Almost every role you can get without a degree is the second kind. It is judged on software engineering, product sense and the discipline to ship, not on grades.

Aim at the right role so you don't waste three months grinding linear algebra you won't use yet.

The 12-month roadmap: 6 phases, one product per phase

There is one rule: every phase produces something that runs. No phase is only reading and watching tutorials.

Phase 1 (months 1–3): Python and Git

This is the step most people skip.

The language is Python, and taste has nothing to do with it: every library and SDK in AI ships for Python first.

The milestone: open a blank file and write a small program without looking up basic syntax. Variables, data types, control flow, functions, reading and writing files, calling an API, handling errors, reading and understanding someone else's code. Learn Git and push everything to GitHub from day one, because GitHub is the first half of your portfolio.

Put the math aside. You need basic statistics; you don't need linear algebra and calculus to start building with LLMs. Learn them when a project needs them.

Must be done in this phase

• Code every day, even if it's 30 minutes
• Five programs written from scratch: a calculator, a file cleanup script, a script that calls a public API, a data cleaning script, a terminal note-taking app
• All five public on GitHub

Phase 2 (months 3–5): LLM APIs and tool use

A chat interface is a product for end users. An AI Engineer works through the API: sending requests from your own code and handling the responses with your own code.

A basic request with the Claude API:

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from env

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    system="You are a summarizing assistant. Answer briefly, no preamble.",
    messages=[{"role": "user", "content": "Summarize the following text: ..."}],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

What to learn: streaming responses, managing conversation history, forcing an output format, handling rate limits and errors. Most important is the difference between a prompt that gives an "okay" answer and one that gives an accurate, repeatable result. In a real product, "usually right" is a bug.

Tool use (function calling) is how the model calls your functions:

tools = [
    {
        "name": "get_order_status",
        "description": (
            "Look up an order's status by order ID. "
            "Call it when the user asks about an order, a delivery date, or shipping status."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "description": "Order ID, for example DH-10293"}
            },
            "required": ["order_id"],
        },
    }
]

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    tools=tools,
    messages=[{"role": "user", "content": "Where is order DH-10293 now?"}],
)

for block in response.content:
    if block.type == "tool_use":
        result = get_order_status(**block.input)  # your function, running on your side
        # send the tool_result back to the model so it can write the final answer

Look at the description: say when to call the tool, not only what the tool does. The model decides whether to call it based on exactly that line.

An agent is, at its core, a model with tools and a loop. Once you know tool use, phase 4 only adds the loop.

Must be done in this phase

• Your first request sent from a Python script within the first hour
• A CLI tool: paste text in, and it does one useful thing
• A chatbot with memory that remembers earlier turns
• Tool use that works: the model calls the function with valid arguments

Phase 3 (months 5–7): RAG, embeddings and vector databases

This is the skill that gets you hired, because most real AI products run exactly this underneath.

RAG = retrieval-augmented generation. A model only knows what it was trained on and what you put in its context. RAG pulls the right piece of information out of your data and puts it in front of the model, so it can answer accurately about things it was never trained on: internal documents, product guides, a knowledge base.

The work: split documents into chunks, turn the chunks into embeddings, store them in a vector database, retrieve the most relevant chunks for each question, and hand them to the model. The result is an answer that cites its sources instead of a confident fabrication.

If retrieval is wrong, no prompt can save it. Most bugs in a RAG app sit in chunking and retrieval, not in the model.

Must be done in this phase

• A RAG app over a real set of documents: your notes, a pile of PDFs, or a wiki
• Measure retrieval: does it fetch the chunk it needs, or only a chunk that is close
• Deploy it so a stranger can use it
• This is portfolio project number one

Phase 4 (months 7–9): AI agents and handling tool failures

An agent takes a goal, splits it into steps, uses tools for each step, and decides the next step from the result it just got. A RAG app answers a question. An agent finishes a job.

You learned tool use in phase 2. Now put it inside a loop with a goal, give the agent several tools, and deal with what happens in practice: the agent goes in circles, calls the wrong tool, or gets stuck.

An agent demo is easy; an agent that runs reliably is hard. The gap is in error handling, clear tool design, and evaluation.

Must be done in this phase

• An agent that uses several tools to finish a real multi-step job
• A small multi-agent system: two agents that work together or check each other
• Explicit error handling: what the agent does when a tool fails or returns nothing
• This is portfolio project number two

Phase 5 (months 9–11): evals, deployment and token cost

This is the most boring phase, and the one that gets you hired. Amateurs skip exactly this phase.

Anyone can build an AI feature that works once. Companies pay for the thing that works the ten-thousandth time.

Evaluation: build a way to measure whether the system is good, and whether a change makes it better or worse. For text generation tasks, measure factual accuracy, relevance and consistency against reference answers, using another model to grade the output or a human reviewer.

Deployment: get the system off your laptop. Hosting, monitoring, handling load, tracking token cost, catching errors before users do. This cluster is often called MLOps; knowing the basics already puts you well ahead of people who can only build on their own machine.

Must be done in this phase

• An eval suite for an earlier project: a set of test cases and a way to score them
• One properly deployed project, with monitoring and cost tracking
• This is portfolio project number three

Phase 6 (months 11–12): portfolio and interviews

There is no new technical skill here. What's left is getting the right people to see what you built.

By now you have three projects: a RAG app with evals, a multi-agent system that solves a real problem, and a deployed system with monitoring. For most AI engineering roles, that set opens more doors than a master's degree.

Write each project up as a case study: the problem, the approach, what you measured, what you would do differently. Then apply at the right level. The realistic way in is often a software engineer role that uses AI first, and a pure AI engineer role after that.

Salaries in Vietnam: the 120K–200K USD a year figures floating around online are the US market, so don't use them as your benchmark. In Vietnam in early 2026 this field is still new, the range is wide, and pay is set differently: what raises it is evidence that you took an LLM system to production and kept it running, not the word "AI" on your CV. Bring three numbers to the negotiation: token cost per request, a measured wrong-answer rate, and uptime. A hiring manager who knows the field will ask about exactly those three.

If your company has no dedicated AI Engineer role yet, don't wait for them to open one. Add an LLM feature to the product you already work on (a support bot, internal search, document data extraction) and let the results create the role.

Must be done in this phase

• One case study per project
• At least one technical write-up that dissects how you built something hard
• Apply widely, counting software engineer roles that use AI as a stepping stone
• In interviews, talk about what you shipped and what you would improve; don't recite theory

Where this roadmap usually breaks

Twelve months only works if you build for all twelve. The people who come out of the roadmap with a job are the ones who shipped something in every phase and didn't chase perfection; the ones who stay stuck keep "preparing" and never put anything in front of real users.

As for "AI writes all the code now, so why learn this": someone still has to design the system, integrate it, judge whether the output is right, and decide what to build. That is the part companies are paying for.