I get asked this often enough to write it down: if you already build for the web and want to add AI features to what you ship, what do you actually learn, and in what order?
What follows is the path I'd take today. I'm not selling a course and I don't have one — this is the route, with the parts worth paying for named where they exist, and the parts that are free named as free.
The thing most people get wrong first
They start with the models and end up collecting trivia — parameter counts, benchmark tables, this week's release. None of it makes you able to ship a feature.
The skill that pays is engineering around a component that is probabilistic, occasionally wrong, sometimes slow, and priced per call. That's an architecture problem, and nearly everything you already know about building reliable systems applies. The model is the easy part.
So the ordering below deliberately delays the interesting-sounding material until you have somewhere to put it.
1. Read the provider documentation properly — free, one weekend
Not skimmed. Anthropic, OpenAI and Google all publish genuinely good documentation covering their APIs, tool use, structured outputs and prompt caching. It is more current and more accurate than any course, because courses go stale the moment an API changes.
Do the quickstart for one provider end to end. Then read the tool-use and structured-output guides carefully — those two concepts are what turn a chat toy into something you can build a product on, and they're where most self-taught developers have a gap.
2. Build one small, real thing — free, a week
Not a tutorial clone. Something you'd use. Mine was a script that turned messy client notes into a structured brief; it was unimpressive and taught me more than the previous month of reading.
You want to hit the real problems early: the output that doesn't parse, the call that times out, the prompt that works on four inputs and fails the fifth. These are the actual job. Encountering them in a toy project is much cheaper than encountering them in a client's.
3. Structured outputs and evaluation — free, ongoing
Two things separate people who demo from people who ship.
Structured outputs
Constraining the model to return data matching a schema, rather than prose you parse with a regex and hope. Every major provider supports this now; learn it early and you'll never write a fragile parser again.
Evaluation
A fixed set of real inputs with expected outputs, so a change is a measurement rather than an opinion. Twenty cases is enough to start. Without it you are permanently guessing whether your last prompt edit helped, and that guessing compounds into a system nobody can safely change. An eval set is also the only honest way to compare one model against another on your own task rather than on a leaderboard.
4. Retrieval — free to learn, worth a course if you want structure
Once you can call a model reliably, retrieval is the next unlock: grounding answers in your own content. This is where paid material starts to earn its price, because the good practice is scattered.
DeepLearning.AI runs short courses on retrieval and LLM application patterns, many free, taught by people who build rather than market. They're a few hours each and genuinely worth the time. The provider cookbooks — Anthropic's and OpenAI's public example repositories — are free and often better than a paid course, because they're runnable.
Concepts to get solid on: embeddings, chunking strategy, why retrieval quality dominates model quality, and why citations matter. I've written the practical version in RAG for business websites.
5. Agents and tool use — last, and be sceptical
Deliberately last, because it's the most over-marketed corner of this field. A great deal of "AI agent" content is teaching you to build an unreliable version of a script.
Learn the mechanics — tool calling, the loop, when to hand a model the ability to act. Then apply a hard test before using it: could this be a deterministic script? If yes, write the script. Agents earn their place where the task genuinely can't be specified in advance, and that's rarer than the content volume suggests.
What to skip
Anything promising you'll "build an AI startup in a weekend." The building was never the hard part.
Prompt-engineering courses as a standalone subject. Prompting is a skill you pick up in a week of doing, and it changes with every model release. It is not a discipline you buy.
Fine-tuning, for now. Most problems people reach for fine-tuning to solve are better solved with retrieval and a clearer prompt, at a fraction of the effort. Learn it when you've hit a wall that genuinely requires it.
The shortest honest version
Read one provider's docs properly. Build something small you'd actually use. Learn structured outputs and write an eval set. Add retrieval when you need it. Treat agents with suspicion. Total cost: mostly your time.
The developers I know who are good at this got there by shipping unglamorous things repeatedly — not by finishing a curriculum. If you want to see what that looks like on real client work rather than in a syllabus, I've written up how I actually build sites with AI in the loop.
I'm Divyansh Sood. I took roughly this path and now ship AI features into client products, plus my own — WebSeek.ai runs on three providers at once. If you'd rather hire someone who's already made these mistakes than make them on a live project, email me.