How to learn AI from scratch

The usual failure is not laziness. It is starting with a long theory curriculum — linear algebra, then statistics, then classical machine learning — and hitting month four with no working system and no momentum. Motivation collapses because nothing has been finished.

The alternative is to build something small and bad quite early, then let the gaps you hit tell you what to learn next. Theory absorbed to solve a problem you actually have sticks; theory absorbed pre-emptively usually does not.

There is a second, quieter failure: treating consumption as progress. Watching a course feels productive and leaves almost nothing behind. The reliable test is whether you could rebuild the thing without the video open.

Learn Python until you can write something you would not be embarrassed to hand to someone else — functions, error handling, reading other people’s code, a little testing. Not tutorial-following: actual maintainable code.

Learn SQL alongside it. This is the step most people skip and most regret. Practically every AI job involves getting data out of somewhere and reshaping it, and this is where real projects spend their time.

The standard to aim for is narrower than "know Python". It is being able to take a vague task, structure it into functions, handle the cases where the input is wrong, and come back to the code in three weeks and understand it. That is the skill every later step depends on.

• Write code that handles bad input without crashing
• Read someone else’s repository and follow what it does
• Write a few tests, enough to catch your own regressions
• Use git properly — branches, commits that mean something
• SQL: joins, grouping and aggregation over messy real tables

Once you can program, build something end to end using an existing model. Do not train anything yet. Take a real problem, wire up a working system, and put it somewhere a stranger can use it.

You will hit real questions immediately — why is this output wrong, why is it slow, how do I know it improved. Those questions are the correct entry point to theory, because now you have a reason to care about the answers.

Choose something you personally want to exist. Motivation is the scarce resource across six months of self-study, and a project you actually use survives the weeks when it is not going well.

• Something you personally want to exist works best
• Real data, however messy
• Deployed, not just running locally
• Some measurement of whether it works

With something built, deeper study has somewhere to attach. Evaluation first — most people never learn it properly and it is what separates a demo from a product. Then retrieval and context handling, then the modelling internals.

The ordering is deliberate. Evaluation makes every subsequent change measurable, so learning it early means the rest of your study compounds instead of being a sequence of guesses about whether things improved.

• Evaluation: metrics, test sets, and honest measurement of change
• Retrieval and embeddings: getting the right context to the model
• Statistics and probability, as far as your problems require
• Model internals and training, once you have a concrete reason

Implementing a transformer from scratch is a good exercise and a poor use of your first six months. It is frequently recommended because it is satisfying and legible, not because it changes what you can build.

The same applies to training models from zero. Almost no production work does this, the compute is expensive, and the skill it builds is narrower than the time it costs. Fine-tuning has its place, and it comes after you can demonstrate that a simpler approach was insufficient.

Skip the framework tour too. Learning five libraries shallowly produces a list; learning one well enough to debug it produces an engineer. You can pick up the others in a week each once you actually need them.

For someone already programming, six to twelve months of consistent effort with a real deployed project is a realistic path to employability. From zero programming, longer — and the variable that matters most is how much you finish, not how much you consume.

Proof is the part people neglect. A deployed link, a short honest write-up of what broke, and a resume that names the actual tools you used will do more than any number of completed courses. Check that resume against a real posting before you apply.

Write as you go rather than at the end. A short note after each significant problem — what broke, what you tried, what fixed it — becomes both your portfolio and the material you will draw on in interviews, and it is almost impossible to reconstruct months later.