Most people who decide to learn AI quit somewhere around week three. Not because the maths is impossible, but because the first two weeks get spent watching videos, which feels like progress, and then they open a blank notebook and discover they can’t build anything at all.
The order of operations matters more than the number of hours you put in. What follows is the sequence that tends to work for people learning this alongside a full-time job, in 45 to 60 minute blocks, without a maths degree.
Spend two weeks on concepts, then stop
Code makes no sense until three ideas are lodged in your head. They’re not complicated, but skipping them means you’ll spend months copying snippets you don’t understand.
- A model is a function with adjustable knobs. It takes input, produces output, and training is just the process of nudging those knobs until the output matches reality more often.
- Training and inference are different jobs. Training is expensive, slow and happens once. Inference is cheap, fast and happens every time a user touches your app. Almost all commercial AI work is inference work.
- Overfitting is the default failure mode. A model can memorise your training data and still be useless on anything new. Every technique you’ll learn later, from dropout to regularisation to train/test splits, exists to fight this one problem.
Cap this phase at roughly 10 hours. Then move on, even if you don’t feel ready. You’ll come back to these ideas with better questions once you’ve broken something.
What you don’t need yet
Linear algebra beyond matrix multiplication, calculus beyond knowing what a derivative represents, and statistics beyond mean, variance and a rough sense of distributions. The rest can wait until a specific problem forces you to learn it. Plenty of working AI engineers picked up the deeper maths years after shipping their first model.
Get Python to the point where it stops being the bottleneck
You don’t need a computer science degree. You need enough Python that syntax errors aren’t the reason you gave up on a Tuesday night. That means variables, loops, functions, lists and dictionaries, importing libraries, and the ability to read a stack trace from the bottom up rather than panicking at the wall of red text.
Fifteen to twenty focused hours gets most people there. Add pandas and NumPy after that, because nearly every dataset you’ll touch arrives as a table and nearly every model wants an array. Set up a virtual environment early. The dependency conflicts you avoid are worth the twenty minutes of confusion.
Build something small enough to finish in a weekend
Pick a problem from your own life and shrink it until it fits inside two days. Sorting your inbox into three categories. Flagging which of your saved articles are actually about the same topic. Predicting whether a customer support ticket will escalate.
Here’s the shape of a realistic first project: collect 400 to 800 labelled examples, split them 80/20, train a simple classifier, and measure accuracy on the held-out set. Expect something in the 70 to 85 percent range. That’s fine. A working 78 percent model you built and evaluated teaches more than a perfect notebook you copied from a tutorial.
Plan for week three, because that’s where the plan breaks
Week one is exciting. Week two is comfortable. Week three arrives with a dataset that won’t load, a library that changed its API, and a tutorial that assumes you already know the thing you’re trying to learn. This is the normal experience, not a sign you’re not cut out for it.
The people who push through have usually committed to a schedule in advance, with slack built in for the bad weeks. Working from an eight-week learning plan designed around week three beats improvising, because the decision to keep going was already made before motivation dropped.
Use structured courses for direction, not comfort
Courses are excellent at telling you what to learn next. They’re terrible at making you competent, because competence comes from the part where you build without a script. Sign up for one at a time. Finish it or abandon it deliberately, but don’t stack five of them in an open browser tab as a substitute for shipping.
If you already work inside a big platform, use the training that lives there. Salesforce Trailhead’s AI skill paths make sense if your day job touches the Salesforce stack, and the context makes the material stick in a way a generic course won’t.
Learn the application layer, because that’s where the jobs are
Training foundation models is a handful of well-funded labs. Building useful things on top of them is everyone else. That layer comes down to three practical skills: retrieval, orchestration, and evaluation.
Retrieval
Most real AI products need to answer questions using documents the model was never trained on. You chunk those documents into pieces, convert them into embeddings, store them, and pull back the relevant ones at query time. A walkthrough of Pinecone’s vector database material is a decent way to get hands-on with that pipeline without a corporate budget.
Orchestration
Chains, tool calls, memory, agents that loop until a task is done. The LangChain Academy curriculum covers this territory and is honest about its own learning curve. If you prefer a tighter focus on document-heavy applications, LlamaIndex’s academy material spends more time on indexing and retrieval quality.
Evaluation
The unglamorous skill that separates hobby projects from products. Build a set of 50 questions with known good answers, run every change against it, and record the score. Without this you’re just guessing whether your tweak helped.
Read one paper a week, and read it badly
Don’t try to understand every equation. Read the abstract, skim the introduction, study the figures and captions, then read the limitations section. That’s it. Fifteen minutes. You’ll absorb maybe 30 percent of it, which is 30 percent more than the person who saved it to a reading list and never opened it.
After three months of this you’ll notice you can predict roughly what a paper is going to claim before you finish the abstract. That’s the real skill: knowing which ideas are load-bearing and which are noise.
Keep a build log, not a certificate collection
Two or three sentences after every session. What you tried, what broke, what you’d do differently. It takes ninety seconds and it does two things: it stops you repeating the same dead end, and it gives you something concrete to say in an interview besides “I completed a course.”
A repo with six messy, documented projects outperforms a stack of certificates every time. Recruiters and hiring managers can tell the difference instantly, and so can you when you look back at your own progress.
The days you don’t feel like it
There will be many. The trick that works is absurdly small: commit to 25 minutes, with a timer, and give yourself permission to stop the moment it rings. Most days you won’t. But the goal on a bad day is not progress, it’s contact. Reading one error message, renaming one variable, rereading yesterday’s build log entry. The streak matters more than the session length.
Six months of imperfect, interrupted, sometimes reluctant practice will put you further ahead than any amount of planning. Open the editor. Write the first line that doesn’t work.