Fine-tuning, and where you go from here

01Three ways to make a model do what you want

By now you have learned two ways to steer a model, and this chapter adds the third — so let us line them up, because choosing between them is a real senior decision. Prompting (Chapters 6–7): change the instructions. Zero cost, instant, try a hundred versions in an afternoon. RAG (Chapter 10): change the knowledge you hand the model at question time. Gives it your facts without touching the model. Fine-tuning (this chapter): change the model itself — actually nudge its parameters (Chapter 5) so it behaves differently by default.

The instinct beginners have is that fine-tuning, being the most powerful-sounding, must be the best. It is usually the wrong first choice — the most expensive, slowest, most brittle of the three. The professional move is the opposite order: reach for it last.

Think of a new hostel warden on their first day. If you want them to answer “what time does the gate close?”, you do not send them for six months of training — you hand them the rule book and tell them to read from it. That is RAG. If you want them to answer politely, in Marathi, in three lines, never guessing when they are unsure, you tell them so once. That is prompting. Training is what you would do to change who they fundamentally are — expensive, slow, and pointless if the real problem was that nobody gave them the rule book.

02What fine-tuning actually is

Remember from Chapter 5 how a model is built: pretraining sets billions of parameters, then fine-tuning nudges them toward being a helpful assistant. You can do a small version of that last step. You take an existing trained model and continue training it a little more, on a few hundred or thousand examples of exactly the behaviour you want — and its parameters shift to make that behaviour its new default. Give it a thousand examples of your company’s support replies and it learns to write in that voice without being told each time.

The critical thing to understand — and the mistake that wastes real money — is what fine-tuning is good at. It teaches form: a tone, a style, a format, a consistent way of responding. It is bad at teaching facts. Fine-tuning a model on your notices will not reliably make it know them — it will make it sound like them while still inventing details. Facts are RAG’s job (retrieve the real text); style is fine-tuning’s job. Mixing those up is the single most common expensive error in applied AI.

03Prompt, RAG, or fine-tune? Decide.

Here is the decision as a professional makes it — try them in this order, and stop at the first that works:

The honest summary: prompt first, RAG for knowledge, fine-tune only for consistent behaviour you cannot get any other way — and even then, only when you have the data and the volume to justify it. Most production AI you will build and see is prompting plus RAG. Fine-tuning is a real tool with a narrow, genuine use — and knowing that it is narrow is exactly the judgment that marks you as someone who understands the field rather than its buzzwords.

04Who trains, who fine-tunes — the whole ladder

Pull back to see the full picture from Chapter 5, now with every rung named. Pretraining a base model from scratch — the trillions of tokens, the thousands of GPUs, the months and the fortune — is done by a handful of frontier labs (OpenAI, Anthropic, Google, Meta, Mistral and a few others). Almost no one else, and certainly no student, does this. Fine-tuning an existing model is far more accessible — companies do it to specialise a model for medicine, law, or their own voice, and the tools are within reach of a small team or a capable individual. Building applications on top of these models with prompting, RAG and agents — that is the vast majority of all AI jobs, and it is exactly what these sixteen chapters trained you to do. You are aimed at the biggest, most open door in the field, not the narrowest.

05The whole journey, in one breath

Look at how far you have come. You started not knowing what a frontend was. You can now explain — and build — a complete modern AI system: a frontend and backend and database (Ch 1–4); what a language model is, how it is built, and how to drive it (Ch 5–6); how to prompt it reliably and safely (Ch 7); how to give it your own knowledge with embeddings, vector search and RAG (Ch 8–10); how to make that retrieval sharp, measured, and fast at scale (Ch 13–15); how to let it act as an agent (Ch 11); how to guard it for real users (Ch 12); and now, when to reshape the model itself (Ch 16). That is not a collection of tricks. That is the architecture of the AI era, and you hold all of it.

06The roadmap from here

Be honest with yourself about what you have and what comes next. You have the architecture — the rare, durable, valuable part, the thing that separates an engineer from a syntax-typist and the thing the AI cannot do for you, because it is the judgment that reviews what the AI produces. What deepens now is craft, and craft comes from building. Ship real projects. Read production code. Go deeper on whichever layer gripped you most as you read — the frontend, the retrieval, the agents, the infrastructure. And put your work where people can see it: a public GitHub, a small live demo, a short write-up of what you built and the decisions you made. In this era, proof of building beats a list of courses, every single time.

The deepest lesson under all sixteen chapters is the one you felt in Chapter 1 and have earned the right to believe now: the AI made the typing cheap and the judgment valuable. Understanding the system, choosing the architecture, reviewing the machine’s work, knowing what can go wrong and guarding against it — that is the job now, and it is a better job than the one before it. You began this worried you only knew syntax. You end it able to design, build, and defend a modern AI system, from the frontend a user taps to the model at its heart. That distance is not small. That is a career, begun.

07Your last assignment

One thing remains, and it matters more than any chapter. Take the notice-board app you have built across this whole journey — the RAG, the agent tool, the guardrails, the cache — write a clear README that explains its architecture in your own words, and put it on GitHub under your name. Then do the thing that changes everything: show it to someone. A senior, a recruiter, a friend, a room. Walk them through every box and every decision. When you can do that without notes — when the system you built is something you can defend out loud — you are no longer a student who took a course. You are an engineer with proof. Now go build the next one.