Runtime target: ~13–16 min
Format notes: [bracketed lines] are direction/visual cues, not spoken. Everything else is spoken dialogue — written the way you'd actually say it out loud, not how you'd write it.
[Talking head, direct to camera, energetic]
So you're a backend engineer. You've shipped APIs, you've argued about database schemas, you've debugged a race condition at 2 AM. And at some point in the last year or two, your org decided it's time to "adapt to AI." And the first step everyone takes — every single org — is the same: start using tools like Claude or ChatGPT to help get work done faster. Vibe-coding, basically. Describe what you want, paste in some code, let the tool do the heavy lifting.
[Beat] Here's the thing though. That's just using AI. A product manager can do that. A manual QA engineer can do that — no offense to either of them. That's not a developer skill. That's an end-user skill.
[Lean in] And if you're honest with yourself — that probably bugs you a little. You're a developer. You should know more than "I typed a prompt and it worked." But the moment someone on your team starts talking about LLMs, or RAG, or agents, or MCP — you go quiet. You nod along. Maybe you even ship stuff using these ideas, without actually knowing what's happening underneath.
That gap — between using AI and actually engineering with it — is what this series closes. No ML PhD required. No neural network math. Just what you, a backend engineer, actually need to go from "I vibe-coded this" to "I understand exactly what I built, and why it works."
[Title card: "AI Engineering Demystified for a Backend Dev"]
[Talking head, maybe a whiteboard or simple on-screen diagram appears here]
Let's start with something you already know cold: every system you've built follows exact rules. You write a function, it takes an input, and it gives you the same output every single time. If something breaks, it's a bug — a specific line, a specific rule, that you can go find and fix.
[On-screen text: "Same input → same output. Always."] That is not true anymore for the thing sitting at the center of every "AI feature." There's a new kind of building block now — one that doesn't run on rules you wrote. It runs on having read a massive pile of text, and learning to guess, really well, what text should come next. Nobody coded in "how to summarize a document." That ability just... emerged, from scale.
[Beat] And here's the part that matters for you specifically: this component can give you a different answer to the exact same question, twice in a row. It can be completely, confidently wrong — no error thrown, no stack trace, just a wrong answer stated as if it were fact. There's no line of code to point at when that happens. You're not debugging logic anymore. You're debugging behavior.
[On-screen text: "AI engineering = building reliable systems around an unreliable-by-nature component"] So here's the actual definition I want you to walk away with: AI engineering is not about building these models. That's a different job — closer to research, heavy math, huge compute budgets, not what most of us are doing. AI engineering is treating this component the way you already treat a payment gateway or a maps API — some external thing you don't control the internals of — except this one doesn't give consistent answers, and you have to feed it exactly the right information, at exactly the right moment, or it's useless.
Concretely — and this is basically the outline for this whole series — that means:
[Talking head] Every skill you already have — API design, failure handling, logging, testing discipline — all of that carries over directly, and it's most of the job. What's missing is understanding this one new moving part deeply enough to engineer around it properly.
Which means before we touch RAG, before we touch agents, before we even say the words "MCP" — we need to answer one question properly: what actually is this thing, and how does it behave?
That's the rest of this video.
[Screen: simple animation or text — "LLM = Large Language Model"] The thing we've been dancing around is called a large language model, or LLM. And I want to give you the one-sentence version, because everything else in this series is just this one idea, applied in different shapes.
[On-screen, bold]
**An LLM is a very good next-piece-of-text guesser.**
That's it. It read an enormous amount of text — most of the public internet, books, code — and got extremely good at one game: given some text, guess what comes next. You give it text, it gives you more text that plausibly continues it.
[Beat] Not "understanding." Not "thinking." Guessing. Extremely well. But guessing.
And two things fall straight out of that, before we've even gotten technical:
Number one — it can sound completely confident and still be wrong. Because "sounding confident" is just a pattern in text, same as everything else. There's nothing inside it fact-checking against reality.
Number two — it only knows what it read. Ask it about your company's internal docs, or something that happened last week — it's got nothing to guess from. And it won't tell you that. It'll guess anyway. That's literally how hallucination happens. We'll fix that later in the series — that's what RAG is for — but for now, just sit with this: that limitation is baked into what the thing fundamentally is.
[Talking head] Hold onto that one line — "very good next-piece-of-text guesser" — because I'm going to keep coming back to it. Everything weird an LLM does traces back to that sentence.
[Screen: word "unbelievable" splitting into "un" | "believ" | "able"]
Quick but important piece. When you type a sentence in, the model doesn't see whole words. It chops your text into small chunks first — sometimes a full word, sometimes a piece of one. "Unbelievable" might become three chunks: un, believ, able. Each chunk is called a token.
Why do you care? Two reasons. One — every API bills you and limits you by token count, not word count or character count. Two — this is why these models are historically bad at things like counting letters in a word, or doing precise math on long numbers. It's not seeing clean digits and letters one at a time the way you are. It's seeing chopped-up chunks.
[Screen: animation — token appearing one at a time, each new one highlighted]
Here's something that trips people up. The model doesn't write your whole answer at once. It goes token by token:
Look at everything so far. Guess the single next token. Add it on. Then look at everything so far, including what it just added, and guess the next one again.
[Beat] That's why, when you watch ChatGPT or Claude type out an answer live — that's not a visual effect. That's literally the model handing you each token the second it produces it.
But here's the consequence that actually matters for you as an engineer: once a token is written, it can't undo it. Every next guess assumes everything so far — including any mistake — is just correct, permanent context. There's no "wait, let me take that back" inside one answer. If it starts down a wrong path, it tends to keep going, because it's now reasoning on top of its own error.
[Screen: a box filling up with text, hitting a wall] There's a hard cap on how much the model can look at, at once — your question, the whole conversation so far, anything you've fed it — combined. That cap is called the context window.
This is, hands down, the most important practical limit you'll fight in every single system you build. Long conversations eventually stop fitting. And — this one surprises people — even when something does fit, the model tends to pay less attention to stuff buried in the middle of a huge input than to the beginning or end. So "just paste the entire handbook in" is not a strategy. It's a bug waiting to happen.
[Screen: dial graphic, low to high] One more piece, quick one. When the model "guesses the next token," it's actually working out how likely every possible next token is, and then picking one — not always the single most likely one. There's a setting called temperature that controls this.
Near zero — it almost always picks the most likely token. Same input, same output, basically every time. That's what you want for anything precise — pulling structured data out of text, deciding which tool to call.
Turned up — say 0.7 to 1 — it more often picks something a little less predictable. More creative-feeling, more varied. Also more likely to wander somewhere weird. That's what you'd use for, say, writing taglines, not for extracting a customer's order number.
[Talking head] Quick one that explains a lot. If you took the raw guessing-machine, right after it finished reading everything, and said "write me a poem about the ocean" — it wouldn't reliably write you a poem. It might just continue with more instructions that look like that one — because in a lot of what it read, instruction-shaped text is followed by more instructions, like a worksheet, not obediently followed.
To get something that reliably acts like a helpful assistant, it goes through extra rounds after that initial reading — shown tons of examples of "instruction in, good response out," then further tuned using real human feedback on which responses people actually preferred. Only after that does it become "ChatGPT" or "Claude" instead of just a raw pattern machine. Worth knowing, because it's a good chunk of why these products feel the way they do.
[Screen: dots on a 2D plane, similar-meaning dots clustering together] Last concept for today, and it's the one the entire second half of this series is built on. Separately from generating text, these models can take a piece of text and turn it into a list of numbers that represents what it means. Text with similar meaning ends up as number-lists that are close together — like nearby houses having similar coordinates. Unrelated text ends up far apart.
That list of numbers is called a vector, the process is called creating an embedding, and there's a standard way to measure "how close are two of these" called cosine similarity. Don't worry about the name. Just keep the idea: closeness in this number-space means closeness in meaning. That one idea is the entire foundation of "search by meaning instead of exact keyword" — which is what makes the next video's topic, RAG, possible at all.
[Talking head, direct to camera] So here's the one mental model I want you to leave with. This model has no memory of its own, and nothing inside it double-checking facts. Every time you call it, all it has is whatever text is in front of it right now, and whatever patterns it absorbed originally. It doesn't remember your last conversation unless you re-send it. It doesn't know your private docs unless you put them in yourself.
[Beat, slower] And that's actually great news. Because it means everything we build for the rest of this series — giving it memory, giving it your company's data, giving it the ability to take real actions, chaining it into agents — all of that is just engineering. You feeding the right text into a stateless guessing machine at the right moment, and handling what comes out. Nothing mystical. Just systems design, aimed at a new kind of component.
[On-screen: next video title] Next time — we go from "prompting" as a party trick to prompting as an actual engineering discipline: system prompts, few-shot examples, getting reliable structured output out of this thing, and the security problem you need to know about the moment you feed it anything from the outside world.
If this made one thing click that used to feel like magic — subscribe, and I'll see you in the next one.
[End card]