reference · look it up
Plain-language definitions for the AI and software words you keep hearing, plus the Claude Code commands worth remembering. Look anything up — no order, no quiz.
Software that does things we used to assume needed a human: understanding language, recognizing images, making decisions. It's a broad umbrella — today's most useful kind for everyday work is the LLM behind tools like Claude.
"AI" is the headline word, but it covers a lot. When people say AI today, they usually mean a large language model.
see alsoMachine learningLLMAgent
A way of building software that learns patterns from examples instead of being handed step-by-step rules. Show it thousands of cat photos and it learns what a cat looks like — nobody wrote down "a cat has whiskers." It's the engine under most modern AI.
It explains where AI gets its abilities: not hand-coded, but learned from huge amounts of data.
see alsoAITraining dataLLM
A Large Language Model — the kind of AI behind Claude. It was trained on a huge amount of text until it became very good at one thing: predicting what word should come next. At enough scale, that single skill is enough to hold a conversation, write code, and explain almost anything.
When you chat with Claude, you're talking to an LLM. That one fact explains both why it's so capable and why it sometimes makes things up.
One specific trained AI you can talk to — like Claude Opus or Claude Haiku. Same idea as car models: one company, different sizes and trade-offs. Bigger models are usually smarter but slower; smaller ones are faster and cheaper.
In Claude Code you can switch models with the /model command, depending on whether a task needs speed or depth.
A chunk of text — very roughly three-quarters of a word. AI models don't read letters or whole words; they read tokens. The word unbelievable might be three tokens: un, believ, able.
Almost everything is measured in tokens: how much an AI can read at once, how fast it replies, and what it costs. The context window is just a token budget.
see alsoContext windowModel
How much the model can hold in mind at once — your question, the files it's looking at, and everything said so far — measured in tokens. Think of it as the model's desk space. When it fills up, the oldest things start to slide off the edge.
If a long Claude session starts forgetting earlier details, you've probably filled the context window. /clear or /compact gives it a clean desk.
Simply what you say to an AI — the question, instruction, or request you type in. "Rename these photos by date" is a prompt. There's no secret syntax; clear plain English is the whole skill.
Better prompts get better results. Most of getting good at Claude is just learning to say what you want clearly and completely.
see alsoLLMContext window
When an AI states something false with complete confidence — citing a function that doesn't exist, inventing a file, or misremembering how a tool works. It isn't lying; it's pattern-matching to a plausible-sounding answer when it doesn't actually know.
This is why the verify habit matters: read what Claude did before you trust it. Hallucinations are usually caught in seconds — if you look.
The huge pile of examples a model learns from — for an LLM, an enormous amount of text. The model never "looks things up" in it later; it absorbed the patterns once, during training, and that's frozen in place.
It's why a model has a knowledge cutoff and can be confidently out of date — see hallucination. It only knows what it was trained on.
see alsoMachine learningLLMHallucination
An AI that doesn't just answer — it takes actions in a loop to reach a goal: read a file, decide the next step, run a command, check the result, repeat. Claude Code is an agent. A plain chatbot only talks; an agent does things on your behalf.
Seeing Claude as an agent explains why it asks permission before acting — it can actually touch your files and run commands, not just describe them.
When an AI doesn't just talk but reaches for a tool to get something done — reading a file, running a command, searching the web. The model decides which tool fits, uses it, and reads the result back. It's what turns a chatbot into an agent.
Tool use is why Claude Code can actually change your files instead of only telling you how. Each tool is also a spot where it pauses to ask permission.
A standard way to plug extra tools and data sources into an AI — like a USB port for AI. Through MCP, Claude can connect to things like your calendar, a database, or a design tool and use them directly.
It's how you extend Claude beyond your code — wire in the services you already use instead of copy-pasting between them.
see alsoAgent
Taking an already-trained model and training it a little more on a narrow set of examples, so it gets better at one specific job — a certain writing style, a particular kind of task. A tune-up, not a rebuild.
You'll hear "a fine-tuned model." It means a general model nudged toward a specialty — most people never need to do it to use Claude well.
see alsoModelTraining data
A Command-Line Interface — running a program by typing commands instead of clicking buttons. The terminal is where you do it. It looks bare, but it's precise, fast, and easy to automate.
Claude Code is a CLI tool. This whole course is about getting comfortable talking to your computer this way.
see alsoTerminal
The window where you type commands and read their output — a plain-text way to talk to your computer. Same machine as your usual desktop, just a different door in. ("Shell" is the program inside it that actually reads your commands.)
It's home base for Claude Code and most developer tools. It looks intimidating; it's really just a text conversation with your computer.
see alsoCLI
How one program asks another to do something — a defined set of requests a service agrees to answer. When an app shows you the weather, it's quietly asking a weather service through its API. It's a menu of what you're allowed to order, and the format for ordering.
"Use the X API" just means "have your code talk to X's service in the way X documented."
The side of an app that makes the request — usually your device. Your browser is a client: it asks a server for a page and shows you what comes back. The client asks; the server answers.
Half of "client/server," the basic shape of how the internet works. The client is the part right in front of you.
see alsoServerFrontendRequest / response
A computer whose whole job is to wait for requests and answer them — always on. When you load a website, some server somewhere received your request and sent the page back. It's an ordinary computer in a role, not a special machine.
"The server" is where a website or app actually runs and stores things — as opposed to your own device, where the frontend lives.
The part of an app you actually see and touch — buttons, text, screens — running on your own device. Everything visual is frontend. It's the dining room of a restaurant: where you sit, order, and are served.
When someone says "that's a frontend change," they mean the look or feel — not the behind-the-scenes logic.
The part of an app you don't see — the logic, the rules, and the stored data, running on a server. It's the kitchen behind the restaurant: where the real work happens, out of sight. The frontend takes your order; the backend prepares it.
Logins, saved data, and payments are usually backend work — handled on a server, not on your screen.
An organized store of information that an app reads from and writes to — your messages, orders, profile. Picture a giant, fast, searchable spreadsheet that lives on a server.
When an app "saves" something, it usually goes into a database. It's where the data lives between visits.
The basic back-and-forth of the internet: a client sends a request ("give me this page"), a server sends a response (the page). Every click and page load is one of these short round trips.
Almost everything online is requests and responses. Once you can see them, the web stops feeling like magic.
A project folder that tracks its own history — "repo" for short. Every saved change is recorded, so you can see what changed, when, and undo any of it. It's a folder with a complete memory.
Your code usually lives in a repo. It's what makes experimenting safe — you can always go back to how things were.
see alsoGitCommitDependency
The tool that tracks the history of your code — every change, who made it, and the power to go back. A repository is a project under Git's watch. It's the standard for version control.
Git is how teams work on the same code without chaos, and how you undo a bad change. Level 8 is all about using it with Claude.
see alsoRepositoryCommitBranch
A saved snapshot of your code at one moment, with a short note on what changed. Commits line up into a history you can read and rewind. Think of it as a save point in a game.
Good commits make the story of a project readable — and make experimenting safe, because you can always return to the last one.
see alsoGitRepositoryBranch
A parallel line of work in git — you split off, make changes safely, then merge back when ready, without disturbing the main version. Like editing a copy of a document and folding your edits in later.
Branches let you try something risky without breaking what already works. New features usually start on one.
see alsoGitCommitRepository
Outside code your project relies on — someone else's work you build on instead of writing everything yourself. A recipe depends on store-bought flour; your project depends on ready-made pieces. Most software is mostly dependencies.
When a project "installs dependencies," it's downloading those building blocks so the code can run.
see alsoRepository
A ready-made skeleton for building software — common pieces and structure already in place, so you don't start from a blank page. Like a kit house: the frame is up; you do the rooms.
"Built with React / Next / Django" names the framework. It shapes how the whole codebase is organized.
see alsoDependencyFrontendBackend
A setting kept outside your code that a program reads when it runs — often a secret like an API key, or a value that differs between your laptop and the real server. The code says "read the key from the environment" instead of writing it down.
It's how secrets and per-machine settings stay out of the code itself. You'll usually meet them as .env files.
A mistake in code that makes it behave wrong — a crash, a wrong answer, a weird glitch. The name stuck after a real moth was found jamming an early computer. Every program has them; finding and fixing them is half the job.
"There's a bug" just means something's broken in the code. Claude is genuinely good at hunting them down with you.
see alsoDependencyRepository