How to Actually Learn AI

Most advice about learning AI is useless. It's either a reading list nobody finishes, or a course that teaches you to build a spam classifier you'll never think about again.

Here's what has worked for people I've watched go from zero to competent.

Start with something you want to exist

Not a tutorial. A thing. A tool that summarizes your saved articles. A script that sorts your photos. A bot that answers questions about your own notes.

The project matters because it decides what you learn next. When you're stuck on a real problem, the next thing to read is obvious. When you're working through a curriculum, everything looks equally important, so nothing sticks.

Pick something small enough to finish in a weekend, and slightly harder than you're comfortable with.

Use the models before you study them

You don't need to know how a transformer works to build useful things with one. Spend your first month just calling APIs and seeing what happens.

You'll learn more about how these systems behave from a hundred bad outputs than from a paper explaining attention. You'll develop intuitions: what they're good at, where they hallucinate, how much the prompt matters, when a bigger model is worth it and when it isn't.

That intuition is the actual skill. The theory makes more sense afterward anyway, because you'll have real questions instead of abstract ones.

Learn Python properly

You can avoid this for a while. Eventually you won't want to.

You don't need to be a great programmer. You need to be comfortable enough that code isn't the bottleneck when you're trying to think about something else. Loops, functions, dictionaries, reading error messages without panicking, installing packages, and enough pandas to move data around.

A week of focused practice gets most people there.

Then go one layer down

Once you've built a few things, the black box starts to bother you. Good — that's when theory lands.

The order that tends to work:

• How neural networks train. Gradient descent, loss, backpropagation. Do this once with actual code, not just diagrams.
• What embeddings are and why they're everywhere.
• How transformers work, at least well enough to explain attention to someone else.
• How models get fine-tuned, and why that's different from prompting.

Andrej Karpathy's videos are the standard recommendation for a reason. He builds things from scratch in front of you, which is different from being told how they work.

Read papers badly

Papers feel intimidating because people assume you're supposed to read them start to finish and understand everything. Nobody does that.

Read the abstract. Look at the figures. Read the conclusion. If it still seems relevant, go back for the method. Most papers you'll abandon halfway, and that's the correct outcome.

Do this once a week and after a few months you'll notice you can follow conversations that used to be opaque.

Build in public, or at least in front of one person

Write up what you made. Post it somewhere. Explain it to a friend who doesn't work in tech.

This is not about self-promotion. It's that explaining forces you to notice the parts you only half-understand. You'll be halfway through a sentence and realize you have no idea why the thing works. That gap is the most useful thing you'll find all week.

Ignore most of the news

The field produces an enormous amount of noise. New model releases, benchmark arguments, predictions about the next five years. Almost none of it changes what you should do tomorrow.

Follow a few people who build things rather than comment on things. Check in weekly, not hourly. The fundamentals move slowly, and they're where your time pays off.

What this looks like over six months

Month one: build something small with an API. It'll be ugly. Finish it anyway.

Months two and three: get comfortable with Python and data handling. Build two or three more things, each slightly harder.

Months four and five: go under the hood. Train a small model yourself. Understand what you were calling all this time.

Month six: pick a direction. Applications, research, infrastructure, evaluation — they're different jobs. You'll know by then which one interests you, and that's a decision you couldn't have made on day one.

The uncomfortable part

You'll spend a lot of time confused. Not the productive kind of confused where you're one insight away — the kind where you're not sure what question to even ask.

That's normal, and it doesn't mean you're behind. It's what learning something genuinely new feels like from the inside. Everyone who seems fluent went through the same stretch and just didn't post about it.

Keep building. The confusion clears.