Reference · 10 min read
Glossary
Plain-English definitions of every bit of jargon you will meet.
Every bit of jargon in this guide, and most of what you'll meet elsewhere, in plain English. Skim it once now; come back when something confuses you.
The AI tools
| Agent | An AI that can act — read your files, write changes, run commands — rather than just chat. Claude Code and Cursor's agent mode are agents. |
| Context window | The working area holding everything the AI can currently see: your conversation plus any files it's read. Finite. When it fills, early detail is lost. |
| Token | Roughly three-quarters of a word. The unit AI usage is measured and billed in. |
| Hallucination | When the AI confidently states something untrue — usually inventing a function or setting that doesn't exist. |
| Prompt | What you type. A good one contains context, task, constraints and success criteria. |
| System prompt | Standing instructions the tool sends behind the scenes. Your CLAUDE.md effectively adds to it. |
| Plan mode | A mode where the agent proposes what it will do but can't change any files until you approve. |
| MCP | Model Context Protocol — a standard way to give an AI tool access to other systems (your database, your issue tracker). Useful later; ignore for now. |
| Sycophancy | An AI's tendency to tell you what you want to hear — agreeing with your idea, praising your question, folding the moment you push back. A side effect of training on human ratings, since humans rate agreeable answers highly. The reason "is this a good idea?" is a bad question. |
| Non-sycophantic prompting | Explicitly instructing the AI to disagree with you when you're wrong, to hold its position under pushback, and to admit what it doesn't know. See Prompting for software. |
| Socratic interview | Getting the AI to interview you, one question at a time, until your requirements emerge from your own answers — rather than you describing the feature and it guessing at the rest. Named after Socrates, who taught by questioning. |
| Adversarial review | Giving the AI the explicit job of breaking your work rather than approving it, ideally in a fresh conversation so it isn't reviewing its own homework. Called red-teaming in software teams. |
Code and version control
| Repository (repo) | A project tracked by Git. |
| Commit | A saved snapshot of your whole project, with a message saying what changed. |
| Branch | A parallel version of your project where you can work without affecting the main one. |
| main | The default branch. By convention, the version that works. |
| Merge | Combining a branch's changes back into another branch. |
| Merge conflict | Two branches changed the same lines and Git needs a human to decide. Rare when working alone. |
| Pull request (PR) | A proposal to merge a branch, with a place to review and discuss it first. |
| Push / pull | Sending your commits to GitHub / bringing GitHub's commits down. |
| Clone | Downloading a repository onto a computer. |
| Diff | The red-and-green view of exactly what changed between two versions. |
| .gitignore | A list of files Git should ignore — secrets and generated folders. |
| Revert / restore | Undoing changes. git restore . throws away everything uncommitted. |
Building blocks
| Frontend | Everything that runs in the user's browser. What they see and click. |
| Backend | Everything that runs on a server. Talks to the database, holds secrets, enforces rules. |
| Full-stack | Both. Next.js is a full-stack framework — frontend and backend in one project. |
| Framework | A pre-built structure that handles common problems so you don't. Next.js, React. |
| Library / package / dependency | Someone else's code that you use in your project. All roughly the same word. |
| npm | The tool that installs JavaScript libraries. npm install downloads everything your project needs. |
| node_modules | The folder those libraries live in. Huge. Never edit it, never commit it. |
| package.json | Your project's ID card: its name, its dependencies, and its available commands. |
| Component | A reusable piece of UI — a button, a card, a nav bar — defined once and used many times. |
| Props | The values you pass into a component to configure it. Like HTML attributes. |
| State | Data that changes while the user is using the app, causing the screen to update. |
| Hook | A React function starting with use that adds behaviour to a component. useState, useEffect. |
| TypeScript | JavaScript with type checking — it catches mismatches before they become bugs. |
| Tailwind | A CSS approach where you apply small utility classes directly in the markup. |
| Server component / client component | In Next.js: code that runs on the server (safe for secrets and database access) versus in the browser (interactive, but fully public). |
Data
| Database | Where your app's data lives permanently. |
| Postgres | The most widely used open-source relational database. What Supabase gives you. |
| Table / row / column | A kind of thing / one of them / one fact about it. |
| Schema | The overall structure: what tables exist, with what columns, related how. |
| Primary key | The unique identifier of a row. |
| Foreign key | A column pointing at a row in another table. How tables relate. |
| Query | A request to the database to read or change data. |
| SQL | The language queries are written in. |
| Migration | A recorded, repeatable change to your database's structure. Always use these rather than clicking in a dashboard. |
| Row Level Security (RLS) | Database-enforced rules about who can read or write which rows. Without it, your data is effectively public. The most important term on this page. |
| Seed data | Fake data for testing. |
| Backup | A copy of your database from a point in time. Check you have them. |
Running and shipping
| Terminal / command line / shell | The text window where you type commands. Same thing, three names. |
| localhost | Your own computer. localhost:3000 is only reachable by you. |
| Port | The number after the colon. Different apps on your machine use different ports. |
| Dev server | The process started by npm run dev that runs your app locally and reloads it as you edit. |
| Build | Turning your source code into the optimised version that gets served to users. |
| Deploy | Putting that build onto the internet. |
| Production | The live version real users are using. |
| Environment variable | A setting stored outside your code — usually a secret, with different values locally and in production. |
| API | A way for programs to talk to each other. |
| API key | A password that identifies your app to a service. Never commit one. |
| Endpoint / route | One specific URL that does one specific thing. |
| DNS | The system that turns a domain name into the address of a server. |
| SSL / HTTPS | The padlock. Encrypts traffic between browser and server. Free and automatic on modern hosts. |
| CDN | A network of servers around the world that serve your site from somewhere near each user. |
| Cache | A stored copy kept to avoid redoing work. Cause of roughly half of all "but I changed that" confusion. |
When things go wrong
| Bug | Behaviour that isn't what was intended. |
| Stack trace | The list of function calls that led to an error. Read the top few lines; ignore anything inside node_modules. |
| Console | The browser's log of errors and messages. Press F12. |
| Hydration error | A Next.js error meaning the server and browser rendered different things. |
| Race condition | A bug caused by two things happening in an unexpected order. The reason double-clicking sometimes breaks things. |
| Regression | Something that used to work and now doesn't. |
| Technical debt | Shortcuts that made things fast now and slow later. Some is fine; unmanaged, it compounds. |
| Refactor | Restructuring code without changing what it does. |
| Edge case | An unusual situation — empty data, a very long name, a double-click. Where most bugs live. |
| Root cause | The actual underlying reason, as opposed to the symptom. Always ask for this. |
I'm a non-technical founder. Explain [term] to me:
1. What it is, in two sentences, with no analogies
2. What problem it exists to solve — what did people do before it?
3. Where it appears in MY project specifically (point at actual files)
4. What I'd notice if it were wrong or missing
5. The one thing beginners misunderstand about it
Then show me a real example from my own code and walk through it.Go through this project and find every piece of terminology that appears in it — library names, framework concepts, domain-specific terms, anything in the code or config that a non-technical person wouldn't recognise.
Write me a glossary, saved to docs/glossary.md, with each term explained in one or two plain sentences plus where it appears in my project.
Sort it by how often I'm likely to encounter each one, most common first. Flag the five terms I genuinely need to understand versus the ones I only need to recognise.Create docs/questions.md. Every time you see a word you don't know, add it. Don't stop to look it up — that breaks your flow. Once a week, paste the whole list into a fresh session and ask for all of them explained in terms of your own project.
You'll know it worked when terms start moving off the list because you already know them. This is the cheapest, most reliable way to build real vocabulary, and it takes about ten minutes a week.