Glossary

Every concept in this sheet, plus the smaller terms it uses. Select a concept to open its card.

A task spec: A short, structured prompt: the goal, the files involved, the constraints and what is out of scope, and how to prove it is done.
A written spec: A short document in the repository listing users, features, data, out-of-scope items and how each feature will be verified, which you and the agent both work from.
AGENTS.md: A plain Markdown instructions file at the repository root that many coding agents read.
AI review as a second pass: Asking a separate AI review, ideally in a fresh context, to look for bugs and security issues in a diff after you have reviewed it yourself.
AI-off sessions: Blocks of time where suggestions and agents are switched off on purpose, for practice, exams or learning a new language.
Allow and deny rules: Specific rules that let trusted, repeated actions run without a prompt and block dangerous ones in every mode, such as pushing to Git or reading key files.
Attempt first, then compare: Writing your own solution, or at least your own plan, before asking the tool, then comparing the two and noting what it did differently and why.
Automation bias: The human habit of trusting output from a confident machine more than we should, and approving it with less care than we would give a colleague's code.

Background and cloud agents: Agents that work without you watching: in a script or CI job, or on a cloud machine that returns a branch or pull request for review.

Checking a new dependency: Confirming a package is real, maintained, widely used and needed, and auditing known vulnerabilities, before adding it.
Checking invented APIs: Verifying that every function, method, option and configuration key in the change exists in the version you actually use.
Checkpoints and undo: Snapshots the tool takes of files it edits, so you can roll its changes back to an earlier point in the conversation.
CI as the gate: Automated checks that run on every push or pull request, tests, type check, lint and security scans, and must pass before anything merges.
Commit before each AI task: Committing your working state before asking the tool for a change, then committing its reviewed change on its own with a clear message.
Completion, chat and agent: The three ways you use these tools: completions suggest the next lines as you type, chat answers questions about code, and an agent reads files, edits several of them and runs commands to finish a task.
Context window: Everything the model can see at once: your messages, its replies, the files it read, command output and the tool's own instructions.

Data use and privacy settings: Account and organisation settings that control whether your prompts and code may be kept or used to train models.
Deliberate practice: Regular, focused practice slightly beyond what you can already do, with feedback, done without AI completions so the struggle is yours.
Disclosing AI use: Stating honestly where and how you used AI tools, in the README, pull request descriptions or commit trailers, and following any required format.
Do not let it edit tests to pass: A rule that the agent may not change, skip or delete existing tests to make its change pass, unless you explicitly agree the test was wrong.

Edge case list: A list of the inputs most likely to break code: empty, one item, very large, negative, zero, null or missing, duplicates, unicode, time zones, concurrent calls and bad permissions.
Employer and university AI policy: The written rules on which AI tools you may use, on what code and data, and whether you must disclose it, set by your employer, client or course.
Explain it back: Before you commit, explaining in your own words what the change does and why it works, without reading the tool's summary.
Explain without notes: Explaining a concept or a piece of your own code out loud or in writing, without looking anything up, as if to a classmate.

Fresh context per task: Starting a new conversation for each unrelated task, and compacting or summarising a long one, so old detail does not confuse new work.
Fundamentals AI does not replace: Data structures and algorithms, how HTTP and databases work, reading unfamiliar code, debugging, Git, testing and writing clear explanations.

Generating a starter file: A built-in command that reads your codebase and drafts the instructions file for you, which you then edit down.
Git as the safety net: Doing every agent task on its own branch from a clean commit, so any change can be inspected, reverted or thrown away.
GitHub Copilot: GitHub's AI assistant: inline suggestions and chat in VS Code, JetBrains IDEs and Visual Studio, agents in the editor, the Copilot CLI in your terminal, code review and a cloud agent on GitHub.
Give the agent a check to run: Telling the agent exactly which command proves the work, the tests, type checker, linter or build, and asking it to run it and show you the output.

Hallucinated packages: Package names a model invents that do not exist, or that attackers have since registered with malicious code because models keep suggesting the same fake names.
Hallucination: A confident answer that is simply wrong: a function, option, file path or package that does not exist, or a version detail from before the model was trained.
Hypotheses, not fixes: Asking for a ranked list of possible causes and how to test each one, then running the tests, instead of asking for a fix straight away.

Insecure patterns AI repeats: Classic flaws that appear often in generated code: SQL built by string concatenation, unescaped HTML, eval, disabled TLS verification, CORS set to allow everyone, weak password hashing and missing authorisation checks.
Installing and starting your tool: Getting the tool running inside a real project, signed in with your own account.

Keeping files out of context: Settings that stop the tool reading certain files, such as .env files, keys and customer data.

Large language model: The model behind every AI coding tool: a program trained on huge amounts of text and public code that predicts the most likely next piece of text, called a token, given everything before it.
Licences and copied code: Generated code can occasionally match public code closely, and that code may carry a licence with conditions such as attribution or sharing your changes.

MCP servers: The Model Context Protocol is an open standard for connecting agents to outside tools and data, such as a database, an issue tracker or a browser.
Minimal reproduction: The smallest piece of code and data that still shows the bug, with everything unrelated removed.
Mutation testing: A tool makes small deliberate bugs in your code, such as flipping a condition, and reruns the tests.

Never paste this: The list of things that never go into a prompt, a file the tool can read or a screenshot you attach, whatever the tool's privacy settings say.

One pull request per slice: Opening a separate, small pull request for each slice, with a description of what changed, how it was tested and what the agent did.

Paste the evidence: Giving the tool the full error, stack trace, logs, input and what you already tried, instead of a summary in your words.
Path-scoped rules: Extra instruction files that load only when the tool works on matching files, such as test files or one folder, so specialised guidance does not fill every session.
Permission modes: The setting that decides which actions the agent may take without asking you: reading only, editing files, running commands, or everything.
Plan before code: Asking the tool to read the code and propose a plan, the files to change and the approach, without editing anything, then correcting the plan before any code is written.
Pointing at an existing pattern: Naming a file in your codebase that already does something similar well and asking the tool to follow it.
Pointing at exact context: Naming the specific files, folders, terminal output or diffs the tool should read, instead of describing where code lives and hoping it searches well.
Project instructions file: A Markdown file in the repository that the tool loads into every session: how to build and test, conventions that differ from the defaults, and gotchas.
Prompt injection: Instructions hidden in content the agent reads, such as a web page, an issue, a README or a dependency's docs, that try to make it do something you did not ask, like leaking secrets.
Prompt templates for common tasks: Reusable shapes for the prompts you write every week: explain, fix a bug, add a feature and refactor, each ending with how to verify.

Read every diff: Looking at exactly what changed, file by file and line by line, before you accept, commit or push it.
Read the docs first: Going to the official documentation of a language, library or tool before asking a model about it, especially for anything version-specific.
Red, green, refactor: The test-driven loop: write a failing test (red), write the smallest code that passes it (green), then clean up with the tests still passing (refactor).
Reproduce before you ask: Finding the exact steps, input and environment that make the bug happen every time, before asking anyone, human or AI, to fix it.
Review checklist for AI code: A short, fixed list you run on every AI change, so review does not depend on how tired you are.
Root cause and regression test: Fixing the cause you proved, then keeping the failing test from your repro so the same bug cannot return unnoticed.

Sandboxing: Running the agent's commands with limited access to the file system and network, or inside a container or cloud machine, so a mistake cannot reach the rest of your computer.
Saved prompts and skills: Prompts saved as files in the repository and run by name with a slash, so a team shares the same review checklist, test workflow or release steps.
Scoping a project for an agent: Choosing a project small enough to finish in a few weeks, with a real user, clear features and a way to test each one.
Secrets out of code and context: Keeping secrets in environment variables or a secrets manager, listing .env in .gitignore, blocking it from the tool and scanning commits for leaks.
Small, checkable tasks: Breaking work into steps small enough that you can describe the change in a sentence or two and check it in a few minutes, then giving the tool one step at a time.
Static analysis on AI code: Automated tools that scan source code for bug and security patterns without running it, run locally and in CI on every pull request.
Symptom patches: Changes that hide a bug instead of fixing it: an empty catch block, a null check that skips the work, a retry loop, a disabled lint rule or a longer timeout.

Tests as the spec: Writing down the expected behaviour as tests before the code exists, so "done" means the tests pass rather than "the tool said it is done".
Tests that cannot fail: Tests that pass whatever the code does: asserting that a mock was called with what you gave it, snapshotting output nobody checks, or no assertions at all.
The agent loop: An agent repeats a cycle: read the task, choose a tool (read a file, search, edit, run a command), look at the result, and decide the next step, until it thinks the task is done.
The project write-up: A short document explaining the problem, your design, what the agent did, what you changed or rejected and why, bugs you caught, and what you would do differently.
Tutor mode prompts: Prompts that make the tool ask you questions, give hints and review your reasoning, instead of writing the answer.

Unrequested changes: Edits you did not ask for: renamed variables, reformatted files, new abstractions, extra features, deleted comments or tests, and code that is never called.
Use the real debugger: Setting breakpoints, stepping through code and inspecting variables in your editor's debugger, or adding targeted log lines, to see what the program actually does.

Vertical slices: Building one feature at a time through every layer, database, API, UI and tests, so each slice works end to end before the next begins.

What belongs in instructions: Commands the tool cannot guess, conventions that differ from the defaults, architecture decisions, environment quirks and known traps.
Where AI helps most: Well-trodden work with a clear check: boilerplate, syntax you half remember, explaining unfamiliar code, first drafts of tests, mechanical refactors covered by tests, and searching a codebase you are new to.
Where AI struggles: Work that depends on facts the model cannot see or rarely saw: your business rules, subtle concurrency, security decisions, new library versions, performance under real load, and large, vague tasks with no clear definition of done.
Write the first test yourself: Writing at least the first, most important test by hand, then letting the tool suggest more cases that you review.