Blog · Personal ·
An AI Glossary for Builders, Not Fundraisers
A terse, opinionated guide to AI terminology written for engineers shipping real products, not people raising money.
A product manager once tried to explain "hallucination" to me by comparing it to a colleague who's confidently wrong in meetings. Fine analogy. Except the colleague eventually learns. The model doesn't. It'll make the same mistake next Tuesday with the same swagger, and that difference is basically the whole ballgame when you're shipping something real.
Most AI glossaries are written for people raising money, not people writing code that has to work at 2am when a customer's angry. So here's a different one. Terse, opinionated, and aimed at builders who need to know what these terms mean when the thing breaks.
Inference
The act of running a trained model to get an output, rather than training it in the first place. Every dollar you spend after launch is inference cost, not training cost, so if your unit economics only look good in the training phase, you've built a demo, not a product.
Context window
The maximum amount of text the model can "see" at once, measured in tokens. It matters because when you go over it, older content gets silently truncated or dropped, and the model starts confidently answering questions about information it can no longer actually see, which is a special kind of nightmare to debug.
Retrieval-Augmented Generation (RAG)
Bolting a search step onto a language model so it pulls in relevant documents before answering, instead of relying purely on what it memorised during training. It's the difference between a model that guesses and a model that at least gets to cheat off the textbook, but garbage retrieval means garbage generation, full stop, no matter how good the model is.
Fine-tuning vs. prompting
Fine-tuning changes the model's weights with your own data; prompting just gives the existing model better instructions at request time. Prompting is cheaper, faster, and reversible in five minutes; fine-tuning is expensive, slow, and basically permanent, so start with prompting and only fine-tune once you've proven prompting genuinely can't get you there.
Embeddings
A way of turning text (or images, audio, whatever) into a list of numbers that captures meaning, so that similar things end up close together in that numerical space. This is the actual engine behind most search and recommendation features that feel "smart"; it's also where a lot of quietly bad decisions get made, because nobody checks whether their embedding model actually understands their domain's jargon.
Hallucination
When a model states something false with the same tone and confidence it uses for something true. It matters because there's no reliable "uncertainty flag" you can build a UI around yet, so you end up designing your whole product around the assumption that the model will lie to you sometimes and you won't know when.
Agent loop
A pattern where the model doesn't just answer once, it plans, takes an action, observes the result, and decides what to do next, repeating until some stopping condition. In practice this means your failure modes multiply with every loop iteration, because now you're not debugging one bad output, you're debugging a chain of decisions that each had their own chance to go sideways.
Function calling
Letting the model trigger actual code (send an email, query a database, hit an API) instead of just generating text. This is where "AI product" stops being a chatbot with a nice font and starts being an actual system, and it's also where you start needing real engineering discipline around permissions, because a model that can call functions is a model that can do damage.
Latency vs. throughput trade-off
Latency is how long one request takes; throughput is how many requests you can process per unit of time, and optimising hard for one often costs you the other. If your product needs to feel instant (a chat interface, say) you're fighting latency; if you're processing a backlog overnight, you care about throughput, and confusing the two is how teams end up over-engineering the wrong problem for months.
Cost per token
The price you pay for each unit of text the model reads or generates, and it's the number that actually determines whether your business model survives contact with real usage. Nobody wants to talk about this at the pitch stage, but it's the thing that turns a beautiful product into a beautiful product that loses money on every single active user.
Stylometric analysis
The statistical study of writing style, things like sentence length variance, word choice patterns, punctuation habits, to identify or verify who (or what) actually wrote a piece of text. This matters more than people think, because as AI-generated text floods every channel, the ability to detect a consistent, distinctive human voice (or the absence of one) becomes an actual product feature, not an academic curiosity. It's also, not coincidentally, most of what we build tools around here: not "is this AI or human", which is a dumber question than it sounds, but "does this sound like the person it claims to be."
Prompt injection
When someone hides instructions inside content your model processes (a webpage, a document, an email) to hijack its behaviour. It matters because your model doesn't distinguish "system instructions I trust" from "random text from the internet" nearly as cleanly as you'd hope, and that gap is a genuine security surface, not a theoretical one.
Grounding
Tying a model's output back to a verifiable source, so a claim can be checked rather than taken on faith. It's the actual antidote to hallucination in production systems, and any team that skips it because "the model's pretty good now" is going to learn the hard way, usually in front of a customer.
None of this is exotic. It's just the vocabulary of actually building the thing, rather than describing it on a slide. The gap between those two skills is where most AI products quietly die, and it rarely announces itself. It just shows up later, as a support ticket nobody can quite explain.