~/map

Terminal

A text interface to your computer: you type a command and it runs immediately. Nearly every tool in this field is documented as a command first and a button second, so avoiding the terminal locks you out of the documentation, not just the tool.

Working directory

The folder a command considers itself to be "inside". Most "file not found" errors are not missing files at all: the file exists, and the command was simply run from somewhere else.

Traceback

The block of text a program prints when it stops. Read it from the bottom up: the last line names the error, and the lines above say which of your files led there, it is a map, not a punishment.

Taught in Getting Started: From Zero to Your First Commit

Virtual environment

A private copy of a language's packages, scoped to one project. Without one, two projects compete over the same installed versions and fixing the first quietly breaks the second.

Dependency file

A file listing exactly what a project needs in order to run, with versions. It is what turns "install some stuff" into a repeatable instruction another person, or a server, can follow without you.

"Works on my machine"

The failure class where the code is correct and still broken for someone else, because their environment differs: a missing variable, another version, a different time zone. Nothing is wrong with the logic, which is exactly why re-reading the logic never finds it.

Taught in Getting Started: From Zero to Your First Commit

Commit

A saved point in a project's history, with a message saying what changed. Its value is not backup: it is being able to ask "when did this break?" and get an answer instead of a memory.

Ignore list

The list of files version control must never record: secrets, local databases, build output. A key committed once stays in the history after you delete the file, so this list is written before the first commit rather than after the first leak.

Remote repository

A copy of the project living on a server rather than your laptop. It is what makes the work shareable, reviewable, and survivable, and for a portfolio it is the artefact an employer actually opens.

Taught in Getting Started: From Zero to Your First Commit

Project instruction file

A file in the repository telling an AI assistant the rules of this project: its stack, its conventions, what it must not touch. Without one you re-explain the project in every conversation and get a differently-shaped answer each time.

Verifying generated code

The habit of proving that generated code does what it claims: running it, reading it, trying the edge case it did not mention. A model produces plausible code, and plausible parts company with correct exactly where you stop looking.

Taught in Getting Started: From Zero to Your First Commit

Large language model

A program trained on an enormous amount of text to predict what comes next. Everything it appears to know follows from that single operation, which is why it sounds equally confident when it is right and when it is not.

Token

The unit a model reads and writes: roughly a word fragment, not a word. It matters because you are billed per token, limited per token, and truncated per token, so it is the currency of every decision here.

Context window

The maximum number of tokens a model can hold in view at once: your instructions, the conversation and any retrieved documents all share it. Go over it and the API refuses the request outright; the silent version is worse, because it is your own code trimming the oldest turn to make room.

Hallucination

A fluent, well-formed answer that is simply untrue. It is a property of prediction rather than a defect to be patched, so the engineering response is grounding and verification, not a sterner instruction.

Model selection

Choosing which model handles a given request, by task rather than by leaderboard. Sending a routing or classification job to the largest available model is the most common way an AI feature becomes expensive without becoming better.

Taught in Foundations: LLMs & Your First AI App

Inference API

The HTTP endpoint you send a prompt to and receive a completion from. Once you can see it as an ordinary request with a body, headers and a status code, most of the mystery around "calling an AI" is gone.

API key

The secret identifying your account to a provider, and the thing their invoice is attached to. It belongs in an environment variable read by the server, never in the source, never in anything the browser downloads.

System prompt

The instruction that sets a model's role and rules for a conversation, kept separate from whatever the user typed. Keeping the two apart is also the first line of defence for the moment a user's text starts issuing orders.

Streaming

Receiving an answer token by token as it is produced, instead of waiting for the whole thing. It does not make generation faster; it makes waiting visible, which is a different benefit and often a larger one.

Temperature

The dial controlling how much randomness is permitted when the next token is chosen. Keep it low for anything you intend to parse, and raise it only where variety is the point.

Taught in Working with LLM APIs

Token pricing

Providers charge per token sent and per token returned, usually at different rates. Do the multiplication by requests per day before you design anything, because the number that decides an architecture is monthly, not per-call.

Rate limit

A cap the provider places on how much you may send within a window. It arrives as an error in the middle of real traffic rather than as a warning beforehand, so the handling has to be written before you need it.

Exponential backoff

Retrying a failed request after a wait that doubles each attempt, with a random amount added on top. The doubling stops you hammering a struggling service; the randomness, jitter, is what stops every client that failed together retrying together and recreating the spike.

Local model

A model running on hardware you control instead of a provider's. It trades peak quality for no per-token cost, no data leaving the machine and no rate limit: a trade that turns out to be right more often than people expect.

Taught in Foundations: LLMs & Your First AI App · Working with LLM APIs

Prompt

Everything you send the model: the instruction, the examples, the retrieved context, the user's words. Treating it as a designed input rather than a question you type is where prompt engineering actually starts.

Few-shot prompting

Showing two or three worked input-output pairs instead of describing the format in words. Demonstration beats description for anything with a shape, and it costs fewer tokens than the paragraph it replaces.

Chain of thought

Asking a model to work through intermediate steps before committing to an answer. It helps on genuinely multi-step reasoning and costs tokens on everything else, so it is a purchase rather than a free upgrade.

Structured output

Constraining a model to answer in a machine-readable shape, normally JSON matching a schema you supply. This is the line between an AI demo and an AI feature, because the rest of a program can only consume shapes.

Output validation

Checking the model's answer against your schema and your rules before any of your code acts on it. The model is an untrusted input source that happens to be on your side.

Prompt injection

An attack where text the model reads (user input, a fetched page, an uploaded document) carries instructions the model then follows. It is why a system prompt is not a security boundary and why retrieved content must never be treated as trusted.

Prompt regression

A prompt edit that fixes the case in front of you and quietly breaks three that used to work. It is invisible without a fixed set of test cases, which is why prompting and evaluation are the same discipline in practice.

Taught in Working with LLM APIs · Prompt Engineering

Embedding

A list of numbers standing for a piece of text's meaning, arranged so that similar meanings land near each other. It is what lets a search match "how do I cancel" against "terminating your subscription" with no shared words.

Vector search

Finding the stored items whose embeddings sit nearest to the query's. Fast and forgiving, and it will always return something, including when nothing relevant exists at all.

Hybrid search

Running vector search alongside ordinary keyword search and merging the results. Vectors are weak on exact strings (error codes, part numbers, proper names) and keywords are weak on paraphrase, so each covers the other's blind spot.

Chunking

Splitting documents into pieces small enough to embed and retrieve usefully. Cut too large and the answer drowns in surrounding text; cut too small and the sentence that mattered loses whatever it was referring to.

Taught in Embeddings & Vector DBs · Retrieval-Augmented Generation

RAG

The pattern of retrieving relevant text first and handing it to the model to answer from. It is the standard response to hallucination because it changes the question from "what do you know?" to "what does this say?".

Grounding

Requiring an answer to come from the supplied sources, and to say so plainly when they do not contain it. "I don't know" is a correct output, and a system that cannot produce it will invent one instead.

Citation

Making an answer point at the passage it came from, so a reader can check it. Citations have to be verified against the retrieved text rather than trusted: a model asked for sources will happily produce one that looks right and refers to nothing.

Reranking

A second, more careful pass that reorders retrieved candidates before any of them reach the model. Cheap retrieval finds twenty plausible passages; reranking decides which five are worth spending the context window on.

Taught in Retrieval-Augmented Generation

Retrieval recall

The share of the genuinely relevant passages that retrieval actually returned. It is a ceiling on everything downstream: if the right passage never arrives, no prompt, model or setting can recover the answer.

Document ingestion

The pipeline turning real files (PDFs, pages, exports) into clean text you can chunk. It is where most retrieval projects quietly fail, because a scanned PDF indexes as zero characters without raising anything at all.

Taught in Retrieval-Augmented Generation

Tool calling

Giving a model a list of functions it may ask you to run, and running them yourself. The model never executes anything, it emits a request, which is exactly why the permission boundary is yours to draw and yours to get wrong.

The agent loop

The cycle of model, tool call, result, model again: repeated until the task is finished. Everything sold as an "agent" is some version of this loop plus the rules that decide when it stops.

Tool description

The text explaining what a tool does and when it should be used. It is a prompt rather than documentation: a vague description is the single most common reason an agent reaches for the wrong tool.

Stop condition

The budget that ends a loop: a step count, a token ceiling, a spend cap, a wall-clock limit. Without one a stuck agent does not fail: it keeps going and it keeps paying.

Idempotency

The property that performing an operation twice has the same effect as performing it once. It is what makes a retry safe; without it, the retry your error handling adds can charge a card or send an email twice.

MCP

An open protocol for exposing tools and data to models in a standard way, so a capability is written once instead of once per application. Same protocol, same caveat: a tool description arriving from elsewhere is untrusted text.

Workflow, not agent

The judgement that a task with fixed, known steps should be ordinary code. Agents earn their cost only where the next step genuinely depends on the last result; anywhere else they add latency, spend and non-determinism for nothing.

Taught in AI Agents & Tool Calling

Multimodal model

A model accepting more than text in the same request: images, audio, sometimes video. It changes both the shape of the request and the size of the bill, because an image is worth a surprising number of tokens.

Speech to text

Turning audio into text so the rest of a pipeline can treat it normally. Accuracy varies sharply with accent, background noise and domain vocabulary, which makes it a component to measure on your own recordings rather than assume.

Image generation

Producing an image from a description. Useful where the output is decorative or a draft, and hazardous where anyone might read it as a record of something that happened.

Taught in Multimodal AI

Fine-tuning

Training an existing model further on your own examples to change how it behaves. It teaches form far better than it teaches facts, for facts, retrieval is cheaper, correctable, and stays current.

LoRA

A fine-tuning method that freezes the original model and trains a small set of extra weights beside it: orders of magnitude fewer trainable parameters, and a memory footprint one person can rent. It is what moved fine-tuning off a cluster and onto a single borrowed GPU.

Quantization

Storing a model's weights at lower precision so it fits in less memory and runs faster. There is a quality cost and the only honest way to size it is to measure it on your own task, not to read someone else's chart.

Training data preparation

Building and cleaning the examples a fine-tune learns from, including stripping personal data out of them. It has to happen before training starts, because a model cannot be made to forget what it has already learned.

Taught in Fine-tuning & Open Models

Evaluation set

A fixed collection of inputs with agreed-good outputs, run after every change. Twenty rows written once is the whole difference between shipping on evidence and shipping on whichever example you happened to try last.

LLM as judge

Using a model to score another model's output against a written rubric. It tracks human judgement only when the rubric is specific to the task; asked plainly whether something is good, it agrees with almost everything.

Precision and recall

Two different ways of being wrong: precision is how much of what you returned was right, recall is how much of what was right you returned. A single accuracy figure hides which one you are failing, and improving either usually costs the other.

Golden example

A case whose correct output is agreed in advance and never quietly edited to match a regression. The moment you start updating the expected answer so the run passes, the evaluation set has become decoration.

Taught in Evaluation, Safety & Guardrails

Unit test

An automated check on one small piece of code, fast enough to run on every change. Its job is not proving the program correct: it is telling you which edit broke the thing that used to work.

End-to-end test

A test driving the whole product the way a person does, through the real screens and the real server. Slow, and worth it for the two or three flows that must never break: sign up, pay, submit.

Device and browser matrix

The written list of real devices and browsers a release is checked on, because your laptop is one configuration out of hundreds. Automation cannot see that the submit button sits behind the on-screen keyboard.

Regression

Something that used to work and no longer does. Most engineering effort in a live product goes into this category rather than into new features, which is what all the testing above is actually for.

Taught in Testing and Quality: Knowing It Works Before Anyone Else Does

Minimum viable product

The smallest version that delivers the core value to a real user. The skill is not choosing what to include: it is deciding what to leave out and being able to say why in one sentence.

Core loop

The single action a user repeats that makes the product worth returning to. If you cannot name it in a sentence, the roadmap is a list of features with nothing holding them together.

User flow

The ordered steps a person takes to finish one thing, from arrival to result. Drawing it is how the missing screens (the empty state, the failure, the confirmation) get found before they are needed rather than after.

Wireframe

A deliberately ugly layout sketch made before any styling exists. Its entire value is being cheap enough to throw away, which stops a bad structure surviving because someone already coloured it in.

Taught in Defining the Product: From Idea to a Buildable Spec

Client and server

The split between code running in the visitor's browser and code running on a machine you control. Everything the client says can be edited by the person holding it, and that is the single most consequential fact in application security.

HTTP status code

The three-digit verdict on a request: 2xx it worked, 3xx it moved, 4xx you sent something wrong, 5xx the server broke. Learning to read them turns "it doesn't work" into a question that has an answer, and the 4xx/5xx line decides whether retrying is sensible or pointless.

API endpoint

One addressable operation on your server, a URL plus a method, taking validated input and returning a defined shape. It is also the only place the rules of your product genuinely exist.

Browser developer tools

The network and console panels built into every browser, showing each request, its payload, its status and its timing. Most arguments about what is broken end within a minute of somebody opening them.

Interface states

The states a screen needs besides "working": empty, loading, error and invalid input. Designing only the happy path is how a product manages to feel broken while every test passes.

Taught in The Skeleton of an Application: Frontend, Backend, and the Wire Between

Schema

The tables, columns and relationships your data lives in. Cheap to change on day one and expensive on day two hundred, which is why it is worth an hour of drawing before a line of it is written.

Migration

A versioned, repeatable change to the schema, applied the same way in every environment. The alternative, editing the live database by hand, works right up until the day it does not, and that day has no undo.

Authentication

Establishing who somebody is: registration, sign-in, sessions, and storing passwords through a slow, salted password hash, not a general-purpose one, which is fast by design and therefore fast to crack. It answers only "who are you"; what they may do is a separate question with a separate answer.

Authorization

Deciding what an identified person may see and do, checked on the server for every single request. Hiding a button is not authorization: the request still works when it is typed out by hand.

OAuth sign-in

Signing in using an account held elsewhere, so you never handle the password at all. You receive a token and a small profile: you get exactly what the user consented to, and the redirect address has to match what you registered, character for character.

Data isolation

Making certain one user's query can never return another user's rows. The bug is rarely dramatic: it is one query that forgot its user filter, on a screen nobody thought was sensitive.

Taught in Data and Identity: Storing Things, and Knowing Who Asked

Bot traffic

Automated requests hitting your public forms and endpoints, arriving within days of launch no matter how few humans know the address. Planning for it is not paranoia; it is the ordinary condition of a public URL.

Honeypot field

A form field hidden from people and visible to naive automation; anything that fills it is discarded. It costs a real visitor nothing at all, which is why it is the first defence to add and the last to remove.

CAPTCHA

A challenge asking a visitor to prove they are a person. Effective, and expensive in patience and accessibility, so it belongs on the endpoint actually being abused rather than across the whole site.

Throttling

Limiting how often a single caller may act, counted by address, account or key. It turns an automated attack from a catastrophe into a nuisance, and it is also what stops one enthusiastic user exhausting your model budget for everyone.

Taught in Abuse and Security: Spam, Bots, Second Factors and Leaks

Input validation

Checking every incoming value for type, size and shape before it reaches your logic, on the server, every time, including where the browser already checked. The browser's check is a courtesy to the user, not a control.

The server is the only truth

The rule that any fact which matters (price paid, permission held, score earned) is decided on the server and never accepted from the client. Whatever the browser can assert, a person can assert.

Webhook signature

The cryptographic proof that a callback claiming to come from a payment provider genuinely did. Without it, the endpoint that marks orders as paid is a public one that anyone can call.

Upload safety

Treating uploads as hostile: verify the real content type rather than the extension, cap the size, store the file outside the served directory, and never reuse the name the user supplied.

Taught in Abuse and Security: Spam, Bots, Second Factors and Leaks

Secret

A key, token or password that grants access to something. The failure mode is almost never theft: it is habit: committed to version control, pasted into a screenshot, written to a log, shipped to the browser.

Two-factor authentication

Requiring a second proof beyond the password, usually a rotating code from an app. The part people skip is recovery codes, which is how a security feature turns into a support queue full of locked-out users.

Error message leak

A user-facing error that hands over internals: a stack trace, a query, a file path, a library version. Log the detail where you can read it and show the visitor a reference number instead.

Security headers

Response headers telling the browser what your page is permitted to load and do. A small, boring piece of configuration that removes whole categories of attack before anyone attempts them.

Taught in Abuse and Security: Spam, Bots, Second Factors and Leaks

Environment variable

Configuration handed to a program from outside its code: keys, database addresses, which mode it is in. It is what lets identical code run against test data and live data without a single edit.

Dev, staging, production

Keeping development, rehearsal and live as separate systems with separate data, separate keys and separate databases. Everything else on this map can be fixed by deploying again; a stray command against live user data cannot, which is why the separation is structural rather than a habit.

Hosting platform

The service that runs your application for you. The real question is never which is best but which fits this shape (an always-on server, an on-demand function, static files) and what it charges once traffic actually arrives.

DNS

The system translating your domain name into the address of the machine serving it. Changes take time to spread across the internet, which is why a site is "still broken" for an hour after you fixed it.

HTTPS

HTTP carried over TLS: the traffic is encrypted so nobody in between can read or alter it, and the certificate is what proves the server really belongs to that domain. Free and automatic on every serious host now, and its absence is shown to every visitor before they read a word.

CI/CD

A pipeline running your tests on every push and deploying when they pass. Its point is not speed: it is that running the tests is no longer something a tired person can decide to skip.

Taught in Shipping and What Comes After

Page metadata

The title and description every page reports to search engines and chat clients. It is the sentence a person reads before deciding whether to click, so it is product copy, not configuration.

Share cards

The image and text a link displays when pasted into a social app or a messenger. Missing them breaks nothing, and it makes every share of your product look like a broken link.

Sitemap and robots

The two files telling crawlers what exists on your site and what to leave alone. On a paid product they also decide which pages are the shop window and which stay behind the counter.

Taught in Shipping and What Comes After

Observability

The logs, error reports and metrics that let you answer "what happened?" without asking the user. The bar is embarrassingly low and rarely met: knowing before they tell you.

Caching

Storing an answer so the expensive work behind it is not repeated. In an AI product it is among the few levers that move cost by a large factor rather than a few percent, and the difficult part is never the storing: it is deciding when a stored answer has gone stale.

Cost ceiling

A hard cap on spend per user and per day, enforced by your own code rather than hoped for. Providers bill for whatever happens, and "whatever happens" includes a loop you did not intend to write.

Funnel metric

The counted steps from arrival to the outcome you care about, so you can see which step people fall out at. Without it, product decisions get made from whichever email complained loudest.

Postmortem

The written account of a failure: what happened, why, and which change makes it impossible next time. It has to be written without blame, or it stops being written at all and the same outage returns.

Taught in Shipping and What Comes After · Deployment & Production