---
title: "Getting into AI without the bootcamp"
slug: getting-into-ai-without-the-bootcamp
date: 2026-10-09
url: https://mohammadhameed.dev/posts/getting-into-ai-without-the-bootcamp
tags: ["ai", "career"]
---

Every couple of weeks someone asks me the same question: what should I learn to get into AI? I used to answer with a syllabus. I don't anymore — because the people I've seen actually get in are rarely the ones who finished the most courses. They're the ones who ran a particular loop long enough to get good at it.

## The bootcamp problem

Tutorials teach you how to use a tool. The work teaches you a harder thing: what to build, what to measure, and when to trust the answer. A course can hand you a certificate in a month; it can't hand you judgment, because judgment only forms against failure you actually hit.

I don't have anything against structure — I have a master's thesis built on it. But I'd rather interview a candidate who shipped one broken eval harness than one who finished ten bootcamps.

## Start from a question, not a curriculum

The best projects start from a problem you already have, not from a technology someone is trying to sell you. My question was the thesis: how do you route a UAV when the map disagrees with reality? That one question pulled in probability, uncertainty, and search — and I still use the habits it forced on me.

If I were starting today, I'd pick something small and annoying in my own life: a folder of notes that won't search well, an email I keep rewriting by hand, a report my team rebuilds every week. That problem becomes the syllabus. It decides every tool you learn and every mistake you'll actually remember.

## Build it broken

Your first version should be embarrassing. You can't learn failure modes from a tutorial — you can only trigger them by accident and then be forced to understand them.

My first retrieval system was a text file of chunks with a naive scorer. It was obviously bad: irrelevant chunks surfaced, good answers hid, and queries with real intent scored worse than exact phrases. Embarrassing is exactly what I needed, because now I could see each failure and fix exactly one thing. That's the whole trick — break it, read the failure, fix one thing, repeat. The engineering is the boring part in between.

## Make it measurable

The single skill that transfers from any engineering discipline into AI is evals. If you can't answer "is this better than it was last Tuesday?", every decision after that is vibes. I wrote the whole journey up in [Your RAG demo is lying to you](/posts/evaluating-rag), and the harness has its own [project page](/projects/rag-eval-harness) — steal it.

```py
# the loop, minus the fancy parts
while True:
    run(system, sample)
    worst = worst_failure(results)
    if worst is None:
        break
    fix(worst)
```

An eval is just a small set of questions you actually care about, scored by rules you actually trust. Twenty hard questions beat twenty thousand easy ones every time. A demo can't tell you it failed; an eval can — that's the point.

## What to build, if you want a starting list

- A **retrieval app** over documents you own, with a scored 20-question eval from day one.
- An **agent that fails loudly** — an explicit "I don't know" state instead of fluent confidence.
- A **fine-tune** of a small model on one narrow task you actually do.
- An **eval harness** for whichever of the above you picked — the part everyone skips.

Build the smallest version of any of these that still works, and you'll have both the skills and something to show. That's the trick: the portfolio is a side effect of the loop, not something you assemble afterwards.

## Where robotics taught me the unwritten rules

Autonomy drilled two things into me that transfer directly. First, uncertainty is a feature to model, not a bug to apologize for. Second, a demo is a lie until it has survived a thousand runs — the same instinct that makes me put evals before polish on AI products.

<Figure src="/images/posts/getting-into-ai-without-the-bootcamp-alt.svg" alt="The question–build–measure loop, drawn as a circuit" caption="Bootcamps run this loop once. The work runs it constantly." />

The [path-planning post](/posts/path-planning-explained) goes deeper on that worry: when you can't see a failure coming, you design the system so it tells you. Same in AI. If your first instinct on a bad model output is "ship it anyway", you've already decided you're not in this for the long run.

<Callout type="insight">
The shortcut isn't a course — it's the loop: question → broken build → measure → fix. Run it enough times and you end up with both the skills and the proof.
</Callout>

So if you're early: skip the course purchase, pick one annoying problem of your own, and build the worst version of it this weekend. When it breaks — and it will — [tell me how it broke](/contact). That loop is the whole education.

<PullQuote>
Don't optimize for completion. Optimize for the number of loops.
</PullQuote>