From .NET to AI Engineer — Part 0: The Roadmap
This is the map for a series on how an experienced software engineer can stay current by adding AI — stage by stage, theory first and then the thing I built with it. I did it from a .NET background; you can adapt it to your own. Start here, then follow the parts in order.
AI is changing what's expected of software engineers, and you don't need to switch careers to keep up — you can add it to what you already do. After a decade writing C#, that's what I set out to do: not retrain from scratch, but bolt AI onto the engineering I already knew. I built a five-week, six-stage plan and worked through it the way I'd tackle any engineering problem — learn the concept in the morning, build something real with it in the afternoon, push to GitHub at night.
This post is the map. Each stage below is a separate part you can follow at your own pace.
Why backend developers have an edge
"AI Engineering" is two words, and most people obsess over the first one.
The AI part — embeddings, prompts, models, retrieval — is genuinely learnable in a few weeks. The Engineering part — clean data pipelines, APIs, input validation, error handling, caching, cost control, security, deployment — is the part that actually makes an AI feature into a product people can rely on. And that part is what we already do every single day.
Most AI tutorials end at a notebook that works once on clean data. Turning that into a system that survives messy input, handles failure, and runs in production is exactly the muscle a backend developer has already built. So don't think of your .NET years as something to leave behind — they're half the job already done.
One quick clarification, since the titles get muddled: by AI Engineer I mean the application layer — building products on top of existing models like GPT and Claude. That's different from a Machine Learning Engineer, who trains models from scratch. This series is entirely the former; no model training required.
The six stages
| Stage | Days | What you learn | What you build |
|---|---|---|---|
| 1 — Python for AI Engineers | 1–3 | Vectorization, Pydantic, the no-loop mindset | A stock data engine |
| 2 — Data Engineering & ETL | 4–7 | Analytical SQL, SQLAlchemy, Parquet, validation | An API → database pipeline |
| 3 — Embeddings & Vector Search | 8–10 | Embeddings, cosine similarity, vector DBs | Semantic search over PDFs |
| 4 — The RAG project | 11–13 | What RAG actually is (and isn't) | A job-matching engine |
| 5 — RAG & Orchestration | 14–15 | LangChain, memory, evaluation | "Chat with your documents" |
| 6 — Agents & Tool Use | 16–19 | Function calling, agent loops, guardrails | A tool-using agent |
| 7 — Shipping it | 20–24 | FastAPI, Docker, caching, observability | A deployed app |
About 26 working days, roughly five weeks at a full-time pace. Stretch it across evenings and weekends if you're doing this alongside a job — the order matters more than the speed.
A note on language: I worked through this in Python, because I'd used it before and that's where most AI tooling lives today. But you don't have to switch — much of this is doable in .NET / ASP.NET too, and I'll publish a .NET version of the path soon. Wherever you see Python below, the concept is what matters; the language is swappable.
How I studied
The rhythm was the same every day:
- Morning (~2–4h): theory. Read, watch, take notes — understand the concept before touching code.
- Afternoon (~4–5h): build. Apply the concept to a real project, not a toy snippet.
- Night: push to GitHub. A visible trail of progress, and a portfolio building itself.
One rule I held to: type everything, don't copy-paste. The errors you hit while typing are where the actual learning happens.
How to make a project "real"
A project that only runs once, in your notebook, on clean data, doesn't count. Before I considered any stage "done," the project had to clear this bar — and it's the same bar that separates an AI tutorial from an AI engineer:
- Uses real, messy data, not a hand-picked toy dataset
- Validates its inputs (this is where Pydantic earns its keep)
- Handles errors instead of crashing on the first surprise
- Has at least a few tests
- Ships with a README that explains what it does, why, and how to run it
- Is deployed somewhere, or at least containerized so it could be
If you've shipped software before, none of this is new. That's the point.
A note on the code: Throughout this series I link to my own projects as references. They're where I explored these ideas in practice — not exact companions to each post, but real code you're welcome to learn from.
What's next
Part 1 starts where the journey started: unlearning the loop, and the Python mindset shift that everything else is built on.