Loading lesson…
Applied AI / Choosing & Designing
Prompting, RAG, fine-tuning, or just code.
Reviewed by Yuvaraj
The most consequential decision in an AI feature is made before you write a single prompt: which approach to reach for at all. There are really only four, a well-crafted prompt, retrieval (RAG) to ground the model in your data, fine-tuning to bake in behavior, or plain code with no model at all. Most teams reach for the most expensive option first and regret it. This lesson gives you a decision flow and the honest tradeoffs so you pick the cheapest tool that actually solves the problem.
Order the options by how much they cost you to build, run, and maintain:
plain code → prompt → prompt + retrieval → fine-tuning.
Every step up adds latency, spend, and a new class of things that can break. So the question is never "how do I use AI here?", it is "what is the least I can get away with?" You climb one rung only when the rung below genuinely cannot do the job. A model that summarizes an invoice is impressive; a regular expression that extracts the total is free, instant, and correct every time. Reach for the model when the task actually needs language understanding, judgment, or generation, not because AI is on the roadmap.
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
Walk the task through these gates in order and stop at the first one that fits.
| Approach | Best for | Handles fresh / changing facts? | Upfront cost | Per-request cost | Output control |
|---|---|---|---|---|---|
| Plain code | Rule-based, checkable tasks | Yes (you write the rules) | Low | Near zero | Total |
| Prompting | General language tasks | Only what fits in context | Very low | Low–medium (token cost) | Medium |
| Retrieval (RAG) | Private / current data | Yes, updates with your data | Medium (pipeline + index) | Medium (extra tokens + search) | Medium |
| Fine-tuning | Fixed style/format, latency | No, weights freeze at train time | High (data + training) | Low–medium (shorter prompts) | High (for form, not facts) |
This trips up almost every team once. They fine-tune a model on their knowledge base hoping it will "learn the company's data," then watch it confidently invent details and go stale the day a document changes.
Fine-tuning teaches form; retrieval supplies facts
If you want the model to answer from specific, current information, retrieve that information and put it in the context. If you want the model to consistently answer in a specific shape, a house tone, a strict JSON schema, a terse support voice, that is what fine-tuning is for. Confusing the two is the single most expensive error in applied AI: you pay for training and still get wrong answers.
These are not mutually exclusive, and mature systems combine them. A support assistant might fine-tune a small model for the company's tone and strict output format, use retrieval to pull the customer's actual order history and the current policy docs, and wrap the whole thing in plain code that validates the response and enforces business rules before anything reaches the user. Start with one rung, prove it, and add another only when a real limitation forces you to.
Common mistakes