ReferenceGlossary for the novice agentic coder
Plain-language definitions for every key term in the guide. Dotted-underlined words above link here. The last group covers everyday engineering words a newcomer may not know yet.
- LLM (Large Language Model)
- The AI that reads and writes text, like Claude. It predicts the next piece of text one step at a time. It has no memory of its own between sessions; everything it "knows" in a session is the text you have given it.
- Token
- The unit an LLM reads and writes in — a chunk of text, roughly ¾ of a word (about 4 characters). "Agentic coding" is ~4 tokens. You pay per token, and the model's limits are measured in tokens, so tokens are the currency of everything here.
- Context (context window)
- All the text the model can see right now: your instructions, the files it has read, the conversation so far, and its own replies. Measured in tokens, with a maximum size (the newest Claude models hold from hundreds of thousands up to 1 million tokens). The model's short-term working memory for this one session.
- Prompt
- The message you send the model. In agentic coding a good prompt is less "write me X" and more "here is the goal, the constraints, and how to check you got it right."
- Inference
- One run of the model turning input into output. "The agent made 40 inferences" means it took 40 turns of thinking and acting.
- Temperature
- A dial from 0 to 1 for how random the model's output is. Low temperature = more repeatable and focused; high = more varied and creative. For coding you usually want it low — though agent tools like Claude Code set this for you; there is no dial for you to turn.
- Hallucination
- When the model states something confidently that is wrong or invented (a function that doesn't exist, a fact it made up). The whole workflow exists to catch these before they reach production.
- Harness
- The software scaffolding around the model that lets it actually do work: read and write files, run commands and tests, use tools, and loop until a task is done. Claude Code is a harness. The key insight of modern agentic coding: most of your results come from the harness, not the model.
- Agent
- An LLM running inside a harness in a loop: it looks at the goal, takes an action (edit a file, run a test), sees the result, and decides the next action — repeating until done.
- Agentic coding
- Building software by directing agents that plan, write, test, and fix code themselves, while you stay "on the loop" — setting direction and checking evidence — rather than typing every line.
- Subagent
- A separate agent the main agent spawns to do one focused job (e.g. "explore these 40 files") in its own context window. It returns a short summary, keeping the main agent's context clean. Subagents are how you fan work out in parallel.
- Orchestrator
- The main agent that plans the work and hands pieces to subagents, then assembles their results. An orchestrator-plus-subagents setup is the standard shape for larger or parallel tasks.
- Tool
- A capability you give the agent to reach outside its own text: run a shell command, search the web, query a database. The agent calls tools the way a person clicks buttons.
- MCP (Model Context Protocol)
- An open standard for plugging external tools and data (GitHub, a database, a browser) into an agent. If a tool speaks MCP, your agent can use it without custom glue code.
- Hook
- A script that fires automatically at a fixed point in the agent's lifecycle — for example, before it runs any shell command. Hooks are deterministic (they run every single time, no matter what the model decides), which makes them the reliable way to enforce rules like "never use npm, use pnpm."
- Skill
- A small reusable instruction file (a
SKILL.md) that teaches the agent how to do one kind of task well, loaded only when needed. Matt Pocock'sgrill-me,tdd, anddiagnoseare skills. Skills keep expertise out of the always-on context until the moment it's relevant. - CLAUDE.md
- A file of standing instructions Claude Code reads at the start of every session. Keep it lean — the model has a limited instruction budget. In a project that also has an AGENTS.md, the simplest CLAUDE.md is one line —
@AGENTS.md— that imports the shared file, plus only whatever is genuinely Claude-specific. - AGENTS.md
- An open, cross-tool standard — a "README for agents" at the root of a project: build/test commands, directory layout, conventions. Read natively by Claude Code and most other coding agents (Cursor, Copilot, Gemini CLI, and others), so it's the one standing-instructions file worth writing regardless of which tool reads it. Stewarded by the Agentic AI Foundation under the Linux Foundation.
- Plan mode
- A setting where the agent proposes a plan and waits for your approval before touching any files. It separates "decide what to do" from "do it," which is where most quality is won or lost.
- Headless mode
- Running the agent non-interactively from a script or CI (e.g.
claude -p "..."), with no chat window. This is how agents run inside automated pipelines. - Grilling
- Having the agent interview you — one question at a time — about your plan until every fuzzy decision is resolved, before it writes code. Matt Pocock's
grill-me/grill-with-docsskills do this. It fixes the oldest failure in software: building the wrong thing because nobody was aligned. - Ubiquitous language
- A shared glossary of your project's real terms (kept in a
context.mdfile) used by you, the code, and the agent alike. An idea from Domain-Driven Design. Once a term has one agreed meaning, the agent stops over-explaining, names things consistently, and even uses fewer tokens to think. - PRD (Product Requirements Document)
- The "destination document": exactly what the finished feature should do, who it's for, and how you'll know it's done. The grilling session becomes the PRD.
- Tracer bullet / vertical slice
- A thin slice of work that goes all the way through the system (database → backend → screen) instead of one horizontal layer at a time. Each slice runs and can be tested on its own, which gives fast feedback and lets slices be built in parallel.
- TDD (Test-Driven Development)
- Write a failing test first, then write just enough code to make it pass, then clean up. The test defines "done" before the code exists.
- Red-green-refactor
- The three beats of TDD: red = a failing test, green = make it pass, refactor = tidy the code without breaking the test. With agents, a separate agent writes the test so the coding agent can't "mark its own homework."
- Blackbox / behaviour test
- A test that checks what the software does from the outside (open the app, click the button, see the status change) rather than how it's built inside. These survive refactors and double as a readable spec of the feature.
- Mutation testing
- A tool deliberately introduces small bugs ("mutants") into working code and reruns the tests; tests that don't fail ("surviving mutants") would miss real bugs of the same shape. Stryker does this for JavaScript/TypeScript, mutmut for Python. It tests your tests.
- Property-based testing
- Instead of hand-written examples, you state an invariant that must always hold ("no two bookings ever overlap") and a framework — fast-check for JavaScript/TypeScript, Hypothesis for Python — generates hundreds of cases trying to break it.
- Diagnose
- A disciplined debugging loop (reproduce → minimize → hypothesise → instrument → fix → regression-test) that stops the agent from guessing at bug fixes.
- Handoff
- Compressing the important state of a session into a small file so a fresh agent can pick up cleanly, instead of dragging a bloated, tired context along. Prevents the "dumb zone."
- Review
- Checking the agent's output before merge. State of the art: watch a recorded demo reel of the behaviour tests and read the evidence, rather than reading every line; scrutinise harder when the change is risky.
- Blast radius
- How much damage a change could do if it turns out to be wrong — small for a copy tweak behind a feature flag, large for anything touching payments, security, or stored data. The scale review effort is calibrated to: spend your attention where the blast radius is big, skim where it's small.
- Definition of done
- The agreed checklist a change must clear before "finished" is allowed to mean "ready" — tests, performance, accessibility, error handling — enforced in CI so nothing merges without it, instead of living in anyone's memory.
- ADR (Architecture Decision Record)
- A short, numbered text file — from Michael Nygard's 2011 essay — recording one significant design decision as Context, Decision, and Consequences, kept in the repo (conventionally
docs/adr/). Old records are superseded, never rewritten. For agents it doubles as long-term memory: fresh sessions read the ADRs and stop re-proposing what you already rejected. - Git worktree
- A feature of git that gives each agent its own separate copy of the project on its own branch. Agents in different worktrees never overwrite each other, so you can run several at once safely.
- AFK ("Away From Keyboard") / Ralph loop
- A working mode, not just one tool: letting agents keep pulling and finishing work while nobody is watching — an overnight "Ralph loop" on your own machine (a script that restarts a fresh agent per ticket, with state on disk) or a CI-hosted loop that turns an approved issue into a reviewable pull request. Non-negotiable guardrails: a sandbox, hard iteration/turn caps, a "done" signal, only well-specified two-way-door tickets, and an agent that never merges its own work — it interrupts you only when blocked, done, or failed.
- Sandbox
- A restricted environment where the agent can run freely without being able to damage your real machine or reach the whole internet. Claude Code ships one built in on macOS, Linux and WSL2, enforced by the operating system: it confines filesystem writes to the project and blocks network access except to the hosts you list under
allowedDomains. A container (Docker), a VM, or a throwaway cloud machine are the other common options. Some form of it is essential before letting agents run unattended. - Permissions (allow / ask / deny)
- Claude Code's rules for which tool calls run without asking. You set them in the
permissionsblock of.claude/settings.json: anallowlist that runs silently, anasklist that always prompts, adenylist that is refused outright, and adefaultModefor everything unlisted. The catch worth knowing: these rules bind Claude's own tools, not what happens inside a shell command — a denied path can still be reached by a script the agent runs in bash. That gap is why a sandbox sits underneath permissions rather than instead of them. - CI (Continuous Integration)
- The automated pipeline that runs on every change: type-check, lint, and the full test suite. A change that fails CI never merges. CI is where "deterministic" quality is enforced.
- Staging environment
- A production-like copy of your app where changes are deployed and tested before real users see them. Your safety net between "tests pass" and "customers use it."
- Preview deploy
- A disposable copy of the app your hosting platform builds automatically for every pull request, at its own URL. Click the link, try the change, merge or close the PR and the copy disappears. The cheapest form of staging.
- Canary (canary release)
- Releasing a new version to a small slice of traffic first — a few percent of users — and watching its error rate and latency before letting it reach everyone. If the numbers turn bad you have hurt a handful of people instead of all of them. Named after the caged bird taken down mines to fail first.
- Rollback
- Undoing a release by putting the previously known-good version back in front of users. The only question that matters is how fast — minutes, not an afternoon — and the only way to know is to have rehearsed it while nothing was on fire. Note the asymmetry with migrations: code rolls back cleanly, data does not.
- Seed data
- Fake but realistic data — demo users, sample bookings — inserted by a script committed to the repo, so every environment starts in a known, useful state. Whatever staging runs on must be anonymised or synthetic — never a raw copy of production.
- IaC (Infrastructure as Code)
- Defining your servers, DNS, and databases in versioned files instead of clicks in a cloud console. Environments become reproducible — rebuildable from the files, not from memory — and every infra change arrives as a reviewable diff like any other code.
- Load testing
- Sending scripted traffic at staging to prove the app behaves under the concurrency you actually expect — before real users supply that traffic for free. Four variants: a load test uses your expected peak; a stress test keeps pushing until it breaks, to find the ceiling; a soak test runs for hours to find slow leaks; a spike test throws a sudden surge at it, the way a newsletter or a launch does.
- Observability
- Being able to see what your running app is doing from the outside. Three pillars: logs (what happened), metrics (how much, how fast), and traces (the path one request took through the system, and where the time went). Error tracking and real-user vitals are the starter kit you install first; traces are the pillar most worth having on the day something is slow and nobody knows why.
- SLO (Service Level Objective)
- A concrete, measurable promise about how well the service behaves — "99.9% of requests succeed," "checkout responds within 2 seconds" — chosen on purpose and tracked. It turns "is it good enough?" from a feeling into a number, and tells you when reliability work should beat feature work.
- SLA (Service Level Agreement)
- The reliability promise written into a contract, with consequences attached when you miss it — service credits, refunds, an exit clause. Not the same thing as an SLO: the SLO is the internal target you actually steer by, and it is deliberately set tighter than the SLA, so that missing your own target is a warning rather than a bill.
- On-call
- The rotation of who gets alerted when production breaks — even if the whole rotation is you. The point of naming it: alerts must reach a person who will act, with a known escalation path, instead of landing on a dashboard nobody watches.
- Correlation ID
- A random id attached to each incoming request and carried through every log line that request triggers. One search for the id reconstructs one customer's whole story — the difference between debugging in minutes and debugging in days.
- Dead-letter queue
- Where background jobs land after failing all their retries — the emails that never sent, the webhooks that never processed. It must alert someone: an unwatched dead-letter queue is silent data loss with a respectable name.
- Source map
- The map from the compressed, transformed code a browser actually runs back to the source files you wrote — so an error report points at a real line of your code instead of
app.min.js:1:48213. Error tracking is only as useful as its source maps. - Core Web Vitals
- Google's three real-user speed metrics — LCP (how fast the main content loads), INP (how fast the page reacts to input), CLS (how much the layout jumps around) — each judged at the 75th percentile of real visits, so a page passes only when most real users get the good experience.
- Conventional Commits
- A machine-readable convention for commit messages —
fix:for a bug fix,feat:for a new feature, aBREAKING CHANGEmarker for anything incompatible — that lets tools compute the next version number and generate release notes automatically. State it once in AGENTS.md and every commit the agent writes follows it. - Semantic versioning (SemVer)
- The near-universal MAJOR.MINOR.PATCH numbering convention: the patch number rises for bug fixes, the minor for new features that break nothing, and the major only for a breaking change — the signal that anyone depending on the old behaviour must act before upgrading.
- Migration (database)
- A scripted change to the database's shape — add a column, rename one, split a table. Dangerous because of an asymmetry: code can be rolled back in seconds, but transformed or deleted data stays that way. Hence expand-contract: build the new shape alongside the old, move over gradually, remove the old only when nothing uses it.
- Context engineering
- The craft of deciding exactly what goes into the context window — and what to leave out — so the model performs at its best. The modern replacement for "prompt engineering": curate, don't cram.
- Compaction
- Automatically summarising an overgrown conversation to reclaim context space while keeping the essentials. A tool for staying out of the dumb zone.
- Prompt caching
- Reusing the model's processing of an unchanged prefix (system prompt, AGENTS.md, tool definitions) across calls, so you pay full price once and a fraction thereafter. Order context static-first to benefit.
- The "dumb zone"
- The point where a context window has grown so large and cluttered that the model's quality drops — often well before the advertised limit (Pocock cites ~100k tokens). The cure is fresh sessions and handoffs, not a bigger window.
- Context rot
- The measured drop in model quality as input grows: in a 2025 Chroma Research study, all 18 frontier models tested got worse as their input got longer — well before the advertised context limit. The research behind the dumb zone.
- "Lost in the middle"
- The research finding (Liu et al.) that models retrieve information placed at the start or end of a long context far more reliably than the same information buried in the middle. Put what matters where the model can see it — early or late, not mid-pile.
- Instruction budget
- The practical limit on how many standing instructions the model can reliably follow at once — it is finite, and past it the rules start competing rather than adding up. The working rule is to keep the standing-instructions file lean: target under ~200 lines. Spend the budget on things the model can't infer; don't waste it restating the obvious.
- Deep module
- A component that hides a lot of complexity behind a small, simple interface (idea from John Ousterhout). Deep modules are what keep an AI-built codebase navigable; you design the interfaces, the agent fills the insides.
- One-way door
- Jeff Bezos's name (2015 shareholder letter) for a decision that is costly or impossible to reverse — a schema holding live data, a published API, the auth model — and therefore deserves slow, deliberate treatment: design it twice, adversarial review, an ADR, a prototype first. Two-way doors, by contrast, should be decided fast.
- Software entropy / "ball of mud"
- The natural drift of a codebase toward tangled mess. AI writes code so fast it accelerates entropy, so you actively fight it (with architecture reviews and deep modules) or drown in it.
- Determinism
- Getting reliable, repeatable outcomes even though the model itself is random. You don't make the model deterministic; you wrap it in deterministic machinery — hooks, tests, CI, sandboxes — that accepts only correct output.
- Evals
- A repeatable test suite for an agent, prompt, or skill itself — not for the product it builds. A capability eval targets a hard task you're not passing consistently yet; a regression eval must stay near 100% and exists purely to catch your own workflow getting worse when you change a prompt or model.
- Golden path
- A starter template with your hard-won defaults already wired in — strict types, both test layers, CI, staging, security scans — so a new project begins already meeting your standards instead of re-earning them one incident at a time. Built by extracting what your best project already does, not designed up front.
- Compounding engineering
- Fixing problems upstream instead of only in place: when any project teaches you a lesson — a missing gate, a flaky deploy step, a rule worth keeping — you patch the template, a skill, or your global config rather than just today's repo. Every future project inherits the fix, and old ones can be pulled up to match, so each improvement to the system improves all projects at once.
- Automation complacency
- The measured drift of human attention when supervising automation that is usually right — studied for decades in aviation, where it contributed to real incidents. As the agent proves reliable, monitoring quietly goes soft and the rare failure gets missed. Not a character flaw but a predictable effect, which is why the counter-measure is scheduled manual practice, not a resolution to stay alert.
- Deskilling
- Losing a skill by routinely delegating its exercise — measurable within months even in experts, as when a 2025 Lancet study found endoscopists' polyp-detection rates dropped after routine AI assistance. The reason to deliberately keep some coding, debugging, and reviewing in your own hands even when an agent could do it.
- Circle of competence
- The domain where you can reliably tell good work from merely plausible work — borrowed from investors Charlie Munger and Warren Buffett, whose point was that knowing the circle's boundary matters more than its size. Agents are most dangerous just outside that boundary: they produce fluent output in any domain, so the limiting factor is never whether work gets produced, only whether you can judge it.
- Brownfield
- Construction's word, borrowed: greenfield is an empty lot, brownfield is a site where something already stands. In software, brownfield means inherited code with running users. It reverses the guide's move order — assess read-only first, freeze, pin behaviour, install gates, and only then change things.
- Characterization test
- A test that pins down what existing code currently does — including its probable bugs — rather than what anyone thinks it should do. In an undocumented codebase, current behaviour is the only spec that provably exists. The term comes from Michael Feathers' Working Effectively with Legacy Code; these tests are the net every rescue is built on.
- Golden master
- The bluntest characterization test: run the system on real inputs, record the outputs, commit the recording, and have CI diff future output against it character by character. It understands nothing — it's a tripwire, not a spec — but it turns "did I break something?" into a mechanical question.
- Strangler fig
- Martin Fowler's pattern for replacing a system you can't afford to rewrite in one go: build clean new modules beside the old code, move traffic to them one path at a time, and let the old code die of disuse. Named after the fig that grows around a tree until the tree is gone. The alternative to the big-bang rewrite, which usually fails.
- Ratchet
- The way to adopt a quality gate in an existing codebase: set the bar at "no worse than today," then only ever tighten it. Old code is grandfathered in; any code you touch must meet the current bar. Like the tool, it turns one way only — the numbers can improve but never quietly slide back.
- git blame
- Git's per-line history view: for every line of a file, which commit, author, and date last touched it. Despite the name, its real use isn't blame — it's archaeology: "why is this strange line here?" usually has its answer in the commit that introduced it.
- RPO / RTO
- Two numbers that define a backup policy. Recovery Point Objective is how much data you can afford to lose (e.g. "at most 1 hour," meaning backups run hourly); Recovery Time Objective is how fast you must be back up. Pick both on purpose — don't let the backup schedule default to whatever the tool ships with.
- RBAC (Role-Based Access Control)
- Modelling who can see or do what as a small set of roles (e.g. "customer," "staff," "admin") instead of ad-hoc per-person permissions. Makes access reviewable — you can answer "who can see customer phone numbers" by reading the role list, not by auditing every account.
- DPA (Data Processing Agreement)
- A required contract, not paperwork, between whoever controls personal data and whoever processes it on their behalf — your hosting provider, email sender, or a business customer whose end-users' data flows through your product. Under GDPR this is an Auftragsverarbeitungsvertrag (Article 28).
- PCI DSS (Payment Card Industry Data Security Standard)
- The card industry's security rules for anyone who handles card data. They are heavy — and they apply in full to whoever's servers the card number touches. Route payments through a hosted checkout or a payment provider's own form and the number never reaches you, which keeps you in the lightest tier of the standard instead of the one with audits.
- MFA (Multi-Factor Authentication)
- Proving who you are with more than just a password — usually a one-time code from an authenticator app or a text message. Stops a stolen password alone from being enough to log in. Worth requiring at minimum for staff and admin accounts.
- Password hashing
- Never store a password. Store the result of running it through a deliberately slow one-way function — argon2id or bcrypt — with a random salt per password, so a stolen database can't be turned back into logins. Getting the details right is fiddly and unforgiving, and a hosted auth provider does all of it for you: that, more than the login screen, is the reason to use one.
- Immutable backup
- A backup copy that genuinely cannot be altered or deleted for a set retention window, even by someone holding valid admin credentials. The specific defence against ransomware, which otherwise tries to encrypt or delete backups along with production once it has access.
- Prompt injection
- An attack where instructions hidden in content the agent reads — a web page, an issue, a README — hijack its behaviour. The #1 risk on OWASP's Top 10 for LLM applications; treat everything the agent reads as untrusted input.
- Lethal trifecta
- Simon Willison's name for the dangerous combination of agent capabilities: access to private data + exposure to untrusted content + the ability to communicate externally. Any two are manageable; all three in one session let a single planted instruction steal your data.
- Slopsquatting
- Registering a package name that LLMs predictably hallucinate and filling it with malware — so the next agent that imagines the package installs the attacker's code. The reason generated dependency lists get audited before anything is installed.
- IDOR (Insecure Direct Object Reference)
- Being logged in, but never checked against the specific record you're asking for — change an ID in the URL and read someone else's data. One of the most common breaks in generated code, and one of the easiest to test for.
- SSRF (Server-Side Request Forgery)
- Getting your server to make a request on the attacker's behalf — you accept a URL (an image to fetch, a webhook to call), they hand you an internal address, and your server obligingly reaches somewhere they never could from outside. The prize is usually an internal service or a cloud metadata endpoint holding credentials. The defence is to validate and restrict where server-side fetches may go, never to trust a URL a user supplied.
- Security headers / CSP (Content Security Policy)
- Response headers that tell the browser what a page is allowed to load and do — which scripts may run, which sites may frame it, whether it must be served over HTTPS. CSP is the strictest of them: an allow-list for scripts and other resources, so an injected
<script>has nowhere to load from. Cheap to add, and they turn several classes of attack into a blocked request. - SCA (Strong Customer Authentication)
- The EU rule (from the PSD2 payments directive) that online payments must be confirmed with multi-factor authentication from the customer's own bank — a tap in the banking app, not just a card number. 3-D Secure is the card networks' implementation. Payment providers handle it for you, but your checkout flow has to survive the redirect.
- Chargeback
- A customer disputes a card charge through their bank instead of asking you for a refund. The money is pulled back, you answer with evidence (delivery confirmation, usage logs), and you pay a fee whether you win or lose. Too many and the card networks drop you — which is why refund-friendly policies are cheaper than they look.
- Dunning
- The retry-plus-email machinery for recovering failed recurring payments: retry the card on a schedule, tell the customer it failed, and downgrade or cancel only after the recovery attempts are exhausted. Subscription businesses lose real revenue without it; billing providers ship it ready-made.
- Double opt-in
- Consent to marketing email proven in two steps: the person signs up, then clicks a confirmation link in a neutral email before receiving anything promotional. The standard German courts accept as proof of consent — a signup form alone is not.
- OSS (One-Stop-Shop)
- The EU VAT scheme for selling to consumers across borders: instead of registering for VAT in every customer's country, you register once at home and file one quarterly return covering all cross-border EU B2C sales. Relevant once those sales pass the €10,000-a-year threshold.
- SEO (Search Engine Optimisation)
- Making a page findable by search engines: content that is crawlable and indexable, a descriptive title and metadata per page, and a sitemap listing what exists. At this level it isn't a dark art — mostly making sure the basics aren't accidentally broken.
- Open Graph
- The meta-tag protocol social networks and chat apps read to build a link preview:
og:title,og:description,og:image. Without the tags a shared link shows as a bare URL; with them it shows as a card — often the first impression your product makes. - Git & repository
- Git is the tool that tracks your code's history. A "repository" (repo) is one project under git. A "commit" is a saved snapshot; a "branch" is a parallel line of work you can develop and later merge back — the main branch, usually called
main, is the official current version of the code. Agents lean on all of these. - Branch (and "main")
- A parallel line of work in git: you branch off, build a feature without disturbing anything else, and merge back when it's ready. Every repo has one official branch — almost always named
main— holding the current agreed version of the code. Agents work on branches; only reviewed work reaches main. - Pull request (PR)
- A proposal to merge one branch into another. It shows the exact changes (the "diff"), runs automated checks, and is where a human — or another agent — reviews the work before it lands. On some tools it's called a merge request.
- Diff
- The exact lines a change adds and removes, shown side by side with what was there before — red for gone, green for new. It is what you actually read when reviewing: not the whole file, just what moved.
git diffshows it in a terminal; a pull request shows the same thing in a browser. - CLI (command-line interface)
- A program you drive by typing commands in a terminal, rather than clicking buttons. Claude Code is a CLI; so are
gitandpnpm. - API / interface
- The public "front door" of a piece of code: the functions and types other code is allowed to call, without knowing what happens inside. You steer a system by owning its interfaces (Section 10).
- Backend
- The part of an app that runs on a server rather than in the user's browser: it holds the database, enforces the rules, and answers requests from the screens people see (the frontend). Anything secret or shared between users must live here — the browser side can always be inspected.
- DOM (Document Object Model)
- The browser's live tree of everything on the page — each element a node the code can read and change. It matters more than it sounds: the order elements sit in the DOM is the order the Tab key walks through them, and screen readers follow it too. That's why a control moved with CSS but left in the wrong place in the DOM breaks keyboard navigation.
- Endpoint
- One addressable "door" into a backend — a URL plus a verb, like
POST /bookings— that accepts a request and returns a response. A backend's API is the set of its endpoints. - Database
- Where an app keeps its data so it survives restarts — users, bookings, orders — stored in structured tables the code can query. Changing its shape later is done with a migration, which is why data decisions deserve more care than code decisions.
- Dependency
- Code your project uses but didn't write — a library installed from a package registry like npm or PyPI. Free functionality, but inherited risk too: every dependency's bugs and security holes become yours, which is why generated dependency lists get audited before anything is installed (see slopsquatting).
- Deploy
- Putting a version of your app onto servers where people can actually use it. "Deployed to staging" means testers can reach it; "deployed to production" means customers can. A mature setup makes deploys boring: automatic, repeatable, and reversible in one click.
- Linter
- A tool that reads your code without running it and flags likely mistakes and style violations — unused variables, suspicious comparisons, inconsistent formatting. It runs in CI, so a whole class of problems is caught mechanically instead of burning review attention.
- Coverage (test coverage)
- The percentage of your code that the test suite actually executes. Useful as a floor — code no test ever touches is invisible risk — but not as a goal: 100% coverage with weak assertions proves nothing, which is why serious suites pair it with mutation testing.
- Non-functionals
- The qualities of software that aren't features: speed, accessibility, security, reliability, cost. A feature can visibly "work" and still fail every one of them — which is why the quality gates in Section 7 check the non-functionals explicitly instead of trusting a working demo.
- Feature flag
- A switch that turns a feature on or off in a running app without shipping new code. Lets you merge work early but reveal it gradually, and switch it off instantly if it misbehaves.
- Regression
- A bug where something that used to work breaks after unrelated new work lands. Regression tests exist to catch exactly this, automatically — every fixed bug becomes a test, so it can never quietly return.
- Flaky test
- A test that passes on one run and fails on the next without any code change. Quarantine it fast: tolerated flakiness teaches everyone — humans and agents alike — to ignore red.
- PWA (Progressive Web App)
- A website built to behave like an installed app — it can load offline, be added to the home screen, and feel native — while still being served from the web.
Foundations — how the model works
The harness — what turns a chatbot into a coder
The workflow — planning to shipping
Scaling & production
Existing code — rescue & legacy
Data protection, security testing & legal
Going live — payments, marketing & the wider web
Everyday engineering terms (for newcomers)