Blog · Personal ·
An AI Glossary for Builders: The Terms Nobody Puts on the Slide
Essential AI terminology for building in practice: token budgets, grounding, prompt injection, chunking, and the other unglamorous concepts that actually matter
An AI Glossary for Builders: The Terms Nobody Puts on the Slide
Right, so we've done glossaries before on this site, terms that matter when you're pitching, terms that matter when things break. This one's different. This is the stuff that comes up in the actual build, the boring middle bit, the part where you're three weeks into shipping and someone on the team says a word you've nodded along to in meetings but never actually had to define under pressure. So let's define it under pressure now.
Token budget. The rough allowance of tokens you've got to work with in a single request before cost or context limits bite. Sounds abstract until your prompt plus your retrieved documents plus your conversation history blows past it and the model just... quietly drops the bit you needed most.
System prompt vs. user prompt. The system prompt is the instruction layer you set once, the scaffolding; the user prompt is whatever gets typed in the moment. Mixing these up is how you end up debugging "weird behaviour" for two days when actually your instructions were just in the wrong slot.
Temperature. A setting that controls how random or safe the model's outputs are, low is boring and consistent, high is creative and occasionally unhinged. If your product feels inconsistent between runs, check this before you blame the model itself.
Grounding. Making sure the model's answer is actually tied to real, verifiable source material rather than its own internal guesswork. This matters because "grounded" is the difference between a tool people trust and a tool people quietly stop using after it confidently invents something.
Prompt injection. When a user (or a document, or a webpage) sneaks in instructions that hijack your model's behaviour away from what you intended. If your product ever ingests user-supplied text and acts on it, this isn't a hypothetical, it's a when.
Guardrails. The rules and filters you bolt on to stop the model doing something daft, offensive, or off-brief. People treat these as a nice-to-have; they're actually load-bearing, especially the day your product meets the public.
Eval set. A fixed batch of test cases you run every time you change a prompt or a model, so you can actually tell if things got better or worse. Without this you're just vibing, and vibing does not scale past about the second week of building.
Model drift. The way a model's behaviour can shift over time, sometimes because the provider quietly updated it underneath you. This is why "it worked fine last month" is one of the most useless sentences in this whole industry.
Chunking. Splitting long documents into smaller pieces so a model can actually process or retrieve them properly. Get your chunk size wrong and your retrieval quality tanks, and nobody will know why, they'll just say the answers feel "off".
Vector store. A database built to hold and search embeddings quickly, the thing that makes retrieval fast rather than agonisingly slow. If you're building anything RAG-shaped, this choice matters more than the model choice, honestly.
Stylometric analysis. The practice of analysing patterns in someone's writing, sentence rhythm, word choice, structure, to identify or verify who actually wrote something. This is close to home for us; it's the difference between a tool that spots AI-generated text by vibes and one that actually holds up to scrutiny.
Latency budget. How much delay your product can tolerate before users notice or care. A chatbot can eat a second or two, fine. A voice product cannot, and building as if it can is a fast way to ship something that feels broken even when it isn't.
Fallback logic. What your product does when the model fails, times out, or gives you garbage. Most teams design the happy path beautifully and then treat the fallback as an afterthought, which is exactly backwards, because the fallback is what your users remember.
Anyway. None of this is glamorous. There's no slide in the world where "chunking strategy" gets applause. But this is the actual texture of building the thing, not talking about the thing, and the gap between those two is enormous and mostly invisible until you're in it.
I guess what I'd say, if you're starting out, is: don't learn these terms in the abstract. Learn them the way you learn where the potholes are on a road you drive every day, by hitting them, ideally at low speed, ideally early. You will hit most of these anyway. Might as well know the name of the thing that just wrecked your afternoon.
That's the list. Not exhaustive, never is, but it's the stuff that actually shows up in the work rather than the pitch deck. Which, if you've read this far, is probably the bit you actually needed.