A friend messaged me last month, three weeks into "learning AI" and a little proud of himself. He could explain self-attention. He'd watched the whole video series. Then he asked why his script kept returning the model's answer wrapped in a paragraph of apology instead of the JSON he'd asked for.
That's the gap I want to talk about. He'd learned the engine and never learned to drive.
I won't pretend there's one correct path here. But after watching a lot of people start, and pulling a few of them out of the ditch, I've got opinions about the order you should do things in. So here they are.
Start with the raw API, not a framework
The first move most beginners make is installing LangChain. I'd wait.
Send a raw request first. Any provider, ten lines of code, hit the endpoint, and then read what comes back. Not just the text. The whole response object. There's a finish_reason sitting in there. There's a usage count telling you exactly how many tokens you just spent. The output comes back as tokens, not words, which is the reason the model can write a whole essay and still miscount the letters in "strawberry."
Then break it on purpose. Send a prompt that's too long and read the error it throws. Crank the temperature up and watch the output come apart. You'll learn more from ten deliberate failures than from any polished tutorial.
Frameworks are fine, later. The trouble is that they hide the exact thing you're trying to understand, so the first time something goes wrong you're debugging your code and someone else's abstraction at once. A roundup of 2026 courses made the same point, that the API-first route gets you shipping faster. I'd push it further. It's the only version where the fundamentals actually stick.
The real question is always "how do I give it my data"
Strip the buzzwords off and most "AI apps" are answering one question. How do I get this general-purpose model to know about my specific stuff?
You have three tools for that, and people reliably grab the heaviest one first.
The lightest is just putting the information into the prompt. If your data is small and doesn't change much, you might already be finished. This is not cheating. It's usually the right answer, and it's the one people are weirdly embarrassed to use.
Next up is retrieval, or RAG. You store your documents, search them when a question arrives, and paste the best matches into the prompt. That's what you want when your knowledge is large, private, or shifting, and when you need the answer to point back at where it came from.
Heaviest of all is fine-tuning, where you retrain the model's weights on your examples. And this is the part everyone has backwards: fine-tuning changes how a model behaves, its tone and its format. It's not for stuffing new facts into it. Try to teach facts that way and you'll have a rough week.
The costly mistake, the one I've watched happen more than once, is reaching for fine-tuning when plain RAG would have shipped by the weekend. A 2026 field guide named that as the mistake teams make most. If you take one rule from this whole post, take that one. Use the simplest layer that solves your problem, and add the next layer only when the problem drags you there.
That same instinct, incidentally, is roughly what separates a hobby demo from something that survives real users, and it's why teams offering generative AI development services almost always begin a project with retrieval and prompting long before anyone mutters the word "fine-tune."
RAG will humble you, and it won't be the model's fault
Everyone expects the model to be the hard part of a retrieval system. It's the retrieval. Every single time.
When the search step hands over the wrong chunk of text, the model gives you an answer that's fluent, confident, and wrong. That mix is the dangerous one, because it doesn't look wrong.
And what actually breaks these systems is dull. You split documents by character count and slice a sentence clean in half, so the meaning's gone before the model ever reads it. Or you pull back two chunks when the answer needed five. Or you pull fifty and bury the useful one in noise (four to six tends to be the sweet spot). Or you lean on generic embeddings that have no clue two words in your field mean the same thing. Or you ignore metadata completely when a plain date filter would've beaten any clever vector trick.
None of that is deep learning. It's data plumbing in a trench coat. Honestly, that's the good news, because you already know how to think about messy data.
The part you'll skip: evals
Nobody wants to write evaluations. You built the thing, you typed into it, it answered, you want to ship. I get the urge. I've had the urge.
But "it worked when I tried it" isn't a test. It's a feeling.
The numbers on this are grim. MIT research that Fortune wrote up found that 95% of generative AI pilots moved profit by nothing at all. McKinsey puts it around 88% of companies using AI somewhere, and only about 6% seeing real impact. The distance between "we have a prototype" and "this helps anybody" is huge, and evals are the only bridge across it I've ever found.
You don't need a fancy setup to begin. Write down twenty real inputs. Write down what a good answer looks like for each one. Re-run them every time you touch a prompt or a chunk size. A spreadsheet and a short script cover it. The whole point is to catch the moment your "tiny improvement" quietly wrecks five cases you weren't watching, because it will, and you'd much rather learn that before a user does.
So why does everybody skip it? Part of it is that it's boring. Part of it is that it forces you to see how often your clever prompt doesn't hold. Both of those are reasons to write the eval, not reasons to dodge it.
What doesn't go out of date
New models land constantly and it's easy to feel permanently a step behind. A lot of the foundation, though, just sits still.
Tokens matter and won't stop mattering. They drive your bill, your context limits, and half the model's stranger failures. Context windows have a hard ceiling, and cramming one full is slow and doesn't mean the model reads the middle with any care. And the same prompt can hand you two different answers back to back, which isn't a bug to squash but a fact to design around, which loops you straight back to why evals exist in the first place.
Learn those three and every new release gets easier to read, because you can tell what's a genuine shift and what's a bigger number bolted onto an old idea.
If you want an actual plan
Rough order for the next week or two. Make ten raw API calls and read every field that comes back. Build a tiny RAG setup over five of your own documents and watch it fall over before you fix it. Write your twenty evals. Then, and only then, go poke at agents and fine-tuning.
You'll notice theory isn't first on that list. That's on purpose. You'll absorb it far faster once you've smacked into the problems it explains, and it'll lodge in your head in a way no diagram ever manages.
The people I've watched get good at this weren't the ones who memorized the architecture up front. They shipped something small, watched it break somewhere interesting, and got curious about the break.
My friend, for what it's worth, closed the video series that night, went back to a bare API call, and had his JSON working by Thursday. Start there.
Top comments (0)