Search "AI engineer roadmap" and you get a mind map with ninety boxes on it. Linear algebra, PyTorch, transformers, MLOps, Kubernetes, six kinds of vector database. It is not wrong, exactly. It is just unusable if you have classes, backlogs and about ten focused hours a week.
This is the version we would actually give a third-year student who wants to be employable as an AI engineer by the time placements start. Six months, roughly ten hours a week, and it ends in something you can show rather than something you can claim.
What does an AI engineer actually do all day?
Worth being clear on this before you spend six months, because the title covers two fairly different jobs and the roadmaps for them diverge sharply.
| AI / LLM engineer | ML research engineer | |
|---|---|---|
| Core work | Building products on top of models | Training and improving models |
| Day-to-day | APIs, retrieval, evals, latency, cost | Datasets, architectures, experiments |
| Maths needed | Working intuition | Deep and non-negotiable |
| Typical entry route | Strong software engineer who learned AI | MS or PhD, or a serious research record |
| Open to freshers | Rarely |
Month 1 — Python and the fundamentals you will actually use
If you can already write Python comfortably, compress this into two weeks and move on. If you cannot, nothing later in this plan will work, so do not skip it.
- Python to the point of fluency: comprehensions, generators, decorators, type hints, virtual environments,
async/await. - Git properly — branches, rebase, resolving a conflict without panicking. You will be judged on your commit history.
- HTTP, REST, JSON, authentication. Build one small FastAPI service with three endpoints and deploy it.
- SQL to the level of joins, indexes and reading a query plan. Half of "AI" work is getting the right rows out of a database.
- Enough NumPy and pandas to load, clean and inspect a dataset without looking everything up.
Month 2 — Working with LLMs like an engineer, not a user
The gap between someone who uses ChatGPT and someone employable is entirely here: structured output, error handling, cost, latency and evaluation.
- 1
Call the APIs directly first
Before any framework, write raw HTTP calls to a model API. Understand messages, system prompts, temperature, token limits and streaming. Frameworks hide exactly the things you need to be able to debug.
- 2
Learn structured output properly
Get the model to return JSON that validates against a schema every time, including when it does not want to. Pydantic on the Python side. This one skill appears in almost every real AI feature.
- 3
Measure tokens and cost from day one
Log tokens in and out for every call and convert to rupees. An engineer who can say what a feature costs per thousand users is immediately more useful than one who cannot.
- 4
Build a tiny evaluation harness
Twenty test inputs, expected behaviour, a script that runs them and prints a pass rate. Crude is fine. Being able to answer "did that prompt change make it better?" with evidence is what separates engineering from guessing.
Month 3 — Retrieval, and why most RAG demos fall over
Retrieval-augmented generation is the single most common thing AI engineers are hired to build, and the gap between a weekend demo and something that works is almost entirely in retrieval quality rather than in the model.
- Embeddings, and what "similar" actually means in vector space.
- Chunking strategies and why naive fixed-size splitting destroys tables and code.
- Vector search with pgvector — Postgres you already know, one extension. Learn a dedicated vector database later, if ever.
- Hybrid search: keyword plus vector. Pure vector search fails badly on names, IDs and exact phrases.
- Re-ranking, and measuring retrieval separately from generation so you know which half is broken.
Month 4 — Agents and tool use
Now the model gets to do things rather than just answer. Keep the scope small; an agent that reliably does one job is a far better portfolio piece than an autonomous one that mostly does five.
- Tool/function calling: defining tools, validating arguments, handling a model that calls the wrong one.
- MCP — the protocol for exposing tools to assistants — is worth understanding now that it is widely supported.
- Retry, timeout and fallback behaviour. Real agents fail constantly; the engineering is in the recovery.
- Guardrails: what the agent may never do, enforced in code rather than requested in a prompt.
- Tracing, so that when it does something strange you can see every step it took.
Month 5 — Production: the part that gets you hired
This is where most self-taught candidates stop, which is precisely why doing it puts you ahead of them. Anyone can get a notebook working. Far fewer can keep a service up.
- 1
Containerise and deploy properly
Docker, environment variables, secrets kept out of the repository, a deployment that survives a restart. A Render or Railway free tier is enough.
- 2
Add observability
Structured logs, request tracing, and a dashboard showing latency, error rate and cost per day. Screenshot it for your portfolio.
- 3
Cache and route
Cache embeddings and repeated queries. Route easy requests to a small cheap model and only escalate the hard ones. Then report the cost reduction as a number.
- 4
Write the tests
Unit tests on your tools, a regression suite on your evaluation set, and CI that runs both on every push. This is the single strongest signal you can send that you have worked on something real.
- 4
- deployed projects with public URLs
- 1
- measured before/after improvement you can talk about
- 6
- months, at roughly ten focused hours a week
Month 6 — Portfolio, applications and interviews
Building stops being the bottleneck here; presentation starts. Give this month the same seriousness you gave the code.
- One portfolio page linking all four projects, each with a one-line problem statement, the stack, and the number that improved.
- A README per repository that a stranger can follow to run the thing in five minutes. Most repositories fail this test.
- Rewrite your resume around the projects — see our fresher resume guide for the format.
- One written case study on your best project: what broke, what you tried, what you would do differently. This is the document that gets you through an interview.
- Practise explaining your architecture out loud in three minutes, with no slides. It is harder than it sounds and it is exactly what the interview is.
What should you deliberately skip?
A roadmap is as much about what you leave out. In your first six months, skip these without guilt — you can pick any of them up later in a week, once you have a reason to.
- Training models from scratch. Genuinely interesting, and not what a fresher is hired to do.
- Kubernetes. Learn it when a job requires it. It will not be the reason you get one.
- Five vector databases. Learn pgvector. The concepts transfer in an afternoon.
- Every new framework. Pick one, ship four projects with it, and ignore the rest of the timeline.
- Certificate collecting. A deployed URL beats a PDF certificate in every hiring conversation we have been part of.
Frequently asked questions
Can I become an AI engineer without a Computer Science degree?
Yes, for LLM/AI engineering roles, and it is common. What is checked is whether you can build and ship software. A non-CS degree costs you some resume screens and almost nothing once you are in the interview with four deployed projects.
How much maths do I need?
For AI engineering: enough linear algebra and probability to understand what an embedding is and why a similarity score behaves the way it does. For research roles it is non-negotiable and much deeper. Do not let maths anxiety stop you from starting — learn it alongside the building.
What is the salary for a fresher AI engineer in India in 2026?
Broadly ₹6–18 LPA for entry-level AI/ML roles, with product companies and funded startups at the upper end and services companies at the lower. The spread is driven far more by demonstrable projects than by college tier.
Should I learn PyTorch or TensorFlow?
PyTorch, if you learn either. But for AI engineering roles you may not need either in your first year — the job is API calls, retrieval, evaluation and backend engineering far more often than it is model training.
Is six months realistic alongside college?
At around ten focused hours a week, yes, if you finish and deploy each project instead of collecting half-built ones. The failure mode is never speed — it is abandoning project three to start something shinier.
Do I need an internship as well?
It helps considerably, mostly because working to someone else's requirements and having your code reviewed teaches things solo projects cannot. If you can get one in months 4–6, take it — the production month goes much faster with a mentor.
Start with the boring month
The instinct is to skip month one, because Python and SQL do not feel like AI. Resist it. Almost every student who stalls in month four stalls for a month-one reason: they cannot debug their own backend, so the agent that fails intermittently is unfixable.
Ship the boring service first. Everything after it gets easier.