Ground Truth

A working developer's path into AI and machine learning.

The short version. Eight chapters, one ordered path: from shipping software to shipping AI systems in about 450 hours. You build something real in every chapter on one thread — one dataset becomes one model becomes one AI product. Each chapter has a week-by-week plan and a resources folder for deeper reading.

---

A note from the author

I have spent my career as a developer, moving between domains, and every move brought a new set of challenges. Through all of them, one habit has helped me more than any tool: starting from a roadmap. A good roadmap does two quiet things. It builds the foundation in the right order, and it teaches you to think in systems — to see how the pieces connect before you start collecting them.

This book is that habit written down, for the move I think matters most right now: from software engineering into AI and machine learning.

I want to be open about how it was made. I used AI models, including Fable 5, to help me research and draft it. The plan, the judgements, and the final words are mine, but it felt right that a book about working with these systems should be honest about being written with their help.

I am not only the author here. I follow these chapters myself, to refresh my own skills, because in this industry the learning never stays done. If you find something that has aged, treat it the way this book will teach you to treat every claim: check it, correct it, and keep moving.

— Santosh Shinde

---

Contents

The chapters

1. Getting oriented  ·  resources
2. Data foundations  ·  resources
3. Core machine learning  ·  resources
4. Deep learning  ·  resources
5. Language models and AI engineering  ·  resources
6. Running it in production  ·  resources
7. Choosing a specialisation  ·  resources
8. Finding the work  ·  resources

Before you start

• Who this book is for
• How to read this book
• Start here: your first week
• One thread through the whole book
• Terms in plain English
• The path at a glance
• How much time it takes
• How each chapter works
• Using AI assistants while you learn

Reference

• Projects, in order of difficulty
• Common pitfalls
• Where thoughtful people disagree
• Keeping this book current

---

Who this book is for

This is written for someone who already writes software. You use Git, you call APIs, you have deployed something, and you can read a stack trace without panic. What you want is a clear route into machine learning and AI engineering, without spending six months on material that turns out to be out of date.

If you are not yet programming, this book will be hard going. The realistic figure from a standing start is closer to 1,000 to 1,500 hours, and the first three hundred or so contain no machine learning at all. CS50P is an excellent place to begin, and this book will still be here afterwards. You will move through it much faster.

A word on what this can and cannot promise. It is a well-researched, carefully checked path, and I think it is a good one. It is not the only good one, and it will not fit everyone. Where the evidence is genuinely mixed, I have tried to say so rather than sound more certain than I am.

---

How to read this book

Follow it in order. Everything optional is marked as optional. When you are unsure what to do next, do the next thing on the list. Most roadmaps offer a branching menu, and that turns out to be part of the problem: a long list of choices is easy to browse and hard to finish.

Build something in every stage. Reading and watching feel productive and, on their own, do not transfer very well. In the largest review of study techniques I could find (Dunlosky and colleagues, 2013), only two methods earned a high-utility rating: practice testing and spreading study out over time. Re-reading, highlighting and summarising all scored low. A video lecture is closer to re-reading than most of us would like to think.

Try to build the key exercise from an empty file, with the tutorial closed. It will feel slower and less pleasant than following along. That feeling is well documented, and it is not a sign that it is going badly. In the classic experiment on this (Roediger and Karpicke, 2006), re-studying beat self-testing when people were tested five minutes later, and lost clearly at two days and one week.

Keep a short log. One file, one line per session: the date, the hours, what you built, and what broke. It gives you a way to revise, and it is a genuinely good answer when someone asks how you learned all this.

Give yourself room. The plan below assumes ten to twelve hours a week, not twenty. A slower plan you finish is worth more than a faster one you abandon, and there is no prize for rushing.

Find one place to ask questions. You will get stuck, and a stuck hour with no one to ask is how most self-study ends. Pick one community early and use it: the fast.ai forums, the DataTalks.Club Slack, or the Hugging Face forums are all free, active and kind to beginners. Ask with what you tried and what you saw; that habit is itself a skill people hire for.

When you feel lost, do this: open the chapter you are on, find the week plan near the top, and do only that week's row. Do not browse the resource list for something better. The list is for lookup, not for choosing your next hour.

---

Start here: your first week

If eight chapters and forty-three weeks feel like a lot, start smaller. Week 0 is eight hours. You do not need to understand machine learning yet. You need a target role, a public repo, a log file, and a notebook that runs. The day-by-day plan for that week is at the top of Chapter 1.

End of week 0: you have a public repo, a log, a role, and Colab working. Open Chapter 2 and follow Week 1 of its plan.

---

One thread through the whole book

You are not collecting random projects. One dataset becomes one model becomes one AI product. That is the end-to-end path interviewers can follow in five minutes.

flowchart LR
    D["Ch 2: Find and clean<br/>your own dataset"]
    M["Ch 3: Train a model<br/>on that data · API"]
    DL["Ch 4: Train something<br/>yourself · optional depth"]
    LLM["Ch 5: LLM app on<br/>documents in the same domain"]
    PROD["Ch 6: Deploy, monitor,<br/>cost table"]
    JOB["Ch 8: README + stories<br/>while you build"]

    D --> M --> LLM --> PROD
    M -.-> DL
    PROD --> SPEC["Ch 7: Capstone"]
    LLM --> JOB
    PROD --> JOB

If you change datasets every chapter, you will finish tired and with nothing coherent to show. Pick a domain you care about in Chapter 2 and stay with it until Chapter 6 at minimum.

---

Terms in plain English

Every term below is also explained in plain words where it first matters in a chapter. Come back here whenever a word feels fuzzy.

---

The path at a glance

flowchart TD
    S0["<b>Chapter 1 — Getting oriented</b><br/>week 0 · 8 hours<br/>Pick a target role. Set up your tools."]
    S1["<b>Chapter 2 — Data foundations</b><br/>weeks 1-5 · 50 hours<br/>Arrays, dataframes, SQL"]
    S2["<b>Chapter 3 — Core machine learning</b><br/>weeks 6-13 · 80 hours<br/>Validation, metrics, tree models, the maths you need"]
    S3["<b>Chapter 4 — Deep learning</b><br/>weeks 14-22 · 90 hours<br/>Backpropagation, PyTorch, transformers"]
    S4["<b>Chapter 5 — Language models</b><br/>weeks 23-32 · 100 hours<br/>Context, retrieval, evaluation, agents"]
    S5["<b>Chapter 6 — Production</b><br/>weeks 33-37 · 55 hours<br/>Containers, CI, serving, monitoring, cost"]
    S6{"<b>Chapter 7 — Specialise</b><br/>weeks 38-43 · 70 hours"}
    A["AI Engineer"]
    B["ML Engineer"]
    C["Data Scientist"]
    S7["<b>Chapter 8 — Finding the work</b><br/>starts week 33, runs alongside"]

    M1(["Milestone: a published data analysis"])
    M2(["Milestone: a model behind an API"])
    M3(["Milestone: a model you trained yourself"])
    M4(["Milestone: a deployed AI product with real users"])

    S0 --> S1 --> M1 --> S2 --> M2 --> S3 --> M3 --> S4 --> M4 --> S5 --> S6
    S6 --> A --> S7
    S6 --> B --> S7
    S6 --> C --> S7

    classDef stage fill:#1f3a5f,stroke:#1f3a5f,color:#ffffff
    classDef milestone fill:#f2f4f7,stroke:#8a94a6,color:#1f3a5f
    classDef pick fill:#2d6a4f,stroke:#2d6a4f,color:#ffffff
    class S0,S1,S2,S3,S4,S5,S7 stage
    class M1,M2,M3,M4 milestone
    class S6,A,B,C pick

---

How much time it takes

gantt
    title Ten-month track, at ten to twelve hours a week
    dateFormat X
    axisFormat %s
    section Foundations
    Chapter 1 Getting oriented   :done, 0, 1
    Chapter 2 Data foundations   :active, 1, 5
    section Machine learning
    Chapter 3 Core machine learning :6, 13
    Chapter 4 Deep learning      :14, 22
    section AI engineering
    Chapter 5 Language models    :23, 32
    Chapter 6 Production         :33, 37
    section Specialise and apply
    Chapter 7 Specialisation     :38, 43
    Chapter 8 Finding the work   :crit, 33, 43

The x-axis is the week number. The job search deliberately overlaps the last two stages, because in practice it takes several months and starting early tells you a lot. It adds three to four hours a week on top of the chapter hours, so weeks 33 to 43 are the fullest in the book. If that is too much, slow the chapters down rather than skipping the search.

About the hour figures. These are your hours on each chapter, assuming each resource is used as described rather than completed end to end. Several of the courses listed are much longer than the chapter that mentions them; where that matters, the chapter says which parts to do. The resource tables give each item's full length, so those numbers are often larger. That is expected, not a contradiction.

Then there is the job search itself. Audited bootcamp data, which is the best evidence available though it covers software engineering rather than AI roles, has put the median in-field search at three to six months. Recent hiring has been harder at the junior end, so four to eight months seems a fairer figure to plan around. That part is my judgement rather than a measurement, and I would rather say so.

---

How each chapter works

Every chapter runs on the same loop.

flowchart LR
    L["<b>Learn</b><br/>the ideas, and one<br/>good resource for each"]
    P["<b>Practise</b><br/>follow along, with the<br/>tutorial open"]
    W["<b>Wait a day</b><br/>a short gap makes<br/>the next step work"]
    B["<b>Build it yourself</b><br/>empty file, tutorial closed"]
    D["<b>Compare</b><br/>read the reference version and<br/>note every difference"]
    C["<b>Check</b><br/>can you explain it<br/>out loud?"]
    N(["Next chapter"])

    L --> P --> W --> B --> D --> C
    C -->|yes| N
    C -->|not yet| P

    classDef box fill:#f2f4f7,stroke:#1f3a5f,color:#1f3a5f
    classDef build fill:#1f3a5f,stroke:#1f3a5f,color:#ffffff
    classDef done fill:#2d6a4f,stroke:#2d6a4f,color:#ffffff
    class L,P,W,D box
    class B build
    class C,N done

The step people skip is build it yourself, and it is the one that does most of the work. If you can finish a chapter by watching, something has gone wrong with the chapter.

Chapters 1 to 6 share one layout: week plan (what to do each week), what you will be able to do, what to learn, resources, what to build and before you move on, usually closing with a few things worth knowing. Chapters 1 and 5 add day-by-day plans where the work needs finer scheduling, and Chapters 7 and 8 are organised around the three branches and the job search instead.

---

Using AI assistants while you learn

This is a genuinely open question, and I do not want to overstate my confidence.

What can be said is that the survey evidence is mixed. In the 2025 Stack Overflow developer survey, 84% of respondents used or planned to use AI tools, and 39.5% of people learning to code used them daily. In the same survey, 46% said they actively distrusted the accuracy of the output against 33% who trusted it, 45% said debugging AI-written code took longer than writing it themselves, and 20% reported reduced confidence in their own problem-solving.

The concern for a learner is specific: an assistant removes the effort of recall, and that effort is what makes something stick. A suggestion that works well is a simple two-mode rule.

This is a reasonable compromise rather than a proven one. Adjust it if you find something that works better for you.

One thing worth taking seriously either way: only put code in your portfolio that you could talk through line by line. Interviewers increasingly ask.

---

Projects, in order of difficulty

What each one proves, and separately what makes it stand out. Those are different questions. The Where you build it column maps each project to the chapter whose build exercise covers it, or notes when it is optional or spans several chapters.

Three punch above their weight for the effort involved: the deliberate leakage write-up (project 3), the published failure taxonomy (project 7), and the honest fine-tuning comparison whose answer may be "not worth it" (project 8). That last kind of negative result is weighted heavily by experienced interviewers, because it cannot be produced by following a tutorial.

---

Common pitfalls

Collected from practitioner writing and from resources that turned out to be dated when checked. None of these are character flaws; most are design problems with the material available.

About sequencing

Resources that are commonly recommended and now dated

Technical traps

About money and portfolios

• Certificates mostly signal enrolment. Audit courses free and spend the money on compute.
• Expensive cohort courses are often excellent, and their authors frequently publish most of the same material free. Read the free version first.
• Buying a GPU before exhausting free tiers is usually procrastination in physical form.
• Ten shallow projects read worse than three deep ones.
• Code you cannot explain is a real risk now that reviewers ask about repositories in detail.
• Building in public works better in the quiet version: ship small things and write up what broke. The high-profile examples usually had a large audience already.

---

Where thoughtful people disagree

This book takes positions throughout. These are the places where competent, experienced people genuinely disagree, and where stating both sides is more impressive than picking one.

---

Keeping this book current

Three kinds of information in this book age fastest: prices and free tiers, model names and capabilities, and salary figures. Treat any specific number as a snapshot, and check the source before you rely on it.

Two studies shaped how the book asks you to work, and both are easiest to reach through a library: Dunlosky and colleagues (2013), on which study techniques actually hold up, and Roediger and Karpicke (2006), on why self-testing feels worse in the moment and works better in the end.

A few places deserve extra scepticism, and I would rather point them out myself. The causal and experimentation resources in Chapter 7 sit outside the rest of the book's heaviest curation, so vet them with particular care. The two-mode rule for AI assistants is a reasonable compromise, not a proven method. And the four-to-eight-month job-search estimate is judgement layered on older data.

If something here has drifted out of date, that is the field doing what it does. Check it against the source, adjust, and keep going. If you find a broken link or a claim that no longer holds, an issue or a pull request on this repository is very welcome; corrections from readers are how a book like this stays useful.