[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-20":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":10,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":16,"starSnapshotCount":16,"syncStatus":27,"lastSyncTime":28,"discoverSource":29},20,"dictionary-of-ai-coding","mattpocock\u002Fdictionary-of-ai-coding","mattpocock","AI coding jargon, explained in plain English.","",null,"TypeScript",2126,244,12,3,0,122,692,86.17,false,"main",true,[],"2026-06-11 04:00:17","\u003C!--\n  GENERATED FILE — DO NOT EDIT.\n  Source: dictionary\u002F*.md, internal\u002FCurriculum.md, internal\u002FREADME.template.md\n  Regenerate: npm run generate\n-->\n\n\u003Cp>\n  \u003Ca href=\"https:\u002F\u002Fwww.aihero.dev\u002Fai-coding-dictionary\">\n    \u003Cpicture>\n      \u003Csource media=\"(prefers-color-scheme: dark)\" srcset=\"https:\u002F\u002Fres.cloudinary.com\u002Ftotal-typescript\u002Fimage\u002Fupload\u002Fv1777878285\u002Fdictionary-dark_2x.png\">\n      \u003Csource media=\"(prefers-color-scheme: light)\" srcset=\"https:\u002F\u002Fres.cloudinary.com\u002Ftotal-typescript\u002Fimage\u002Fupload\u002Fv1777878285\u002Fdictionary-light_2x.png\">\n      \u003Cimg alt=\"AI Coding Dictionary\" src=\"https:\u002F\u002Fres.cloudinary.com\u002Ftotal-typescript\u002Fimage\u002Fupload\u002Fv1777878285\u002Fdictionary-light_2x.png\" width=\"369\">\n    \u003C\u002Fpicture>\n  \u003C\u002Fa>\n\u003C\u002Fp>\n\n# AI Coding Dictionary\n\n**AI coding can feel like it's just for experts**. Unexplained jargon. Mysterious failures. Bills that don't seem to match the work.\n\nIt isn't, really. A lot of the confusion is manufactured: **there's a whole VC-funded economy that benefits from keeping it hard to understand**.\n\nThe basic terms of engagement are learnable in an afternoon. Once you have them, the whole thing stops feeling like guesswork.\n\nWhy does context degrade? Why is the bill so high? Why does the same prompt behave differently from one day to the next?\n\nEach has a clean answer, once someone tells you the words to use.\n\nThat's what this dictionary is for. **The vocabulary of AI coding, translated into plain English**.\n\n**Want more than the vocabulary?** Join 62,000+ developers at **[aihero.dev\u002Fnewsletter](https:\u002F\u002Fwww.aihero.dev\u002Fs\u002Fdictionary-newsletter)** for my latest skills, thinking on AI engineering, and the resources that'll keep you ahead of the curve.\n\n---\n\n## Table of contents\n\n\u003Cdetails>\n\u003Csummary>Section 1 — The Model\u003C\u002Fsummary>\n\n- [Model](#model)\n- [Parameters](#parameters)\n- [Training](#training)\n- [Inference](#inference)\n- [Token](#token)\n- [Next-token prediction](#next-token-prediction)\n- [Non-determinism](#non-determinism)\n- [Model provider](#model-provider)\n- [Harness](#harness)\n- [Model provider request](#model-provider-request)\n- [Input tokens](#input-tokens)\n- [Output tokens](#output-tokens)\n- [Prefix cache](#prefix-cache)\n- [Cache tokens](#cache-tokens)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 2 — Sessions, Context Windows & Turns\u003C\u002Fsummary>\n\n- [Stateless](#stateless)\n- [Context](#context)\n- [Context window](#context-window)\n- [Stateful](#stateful)\n- [Agent](#agent)\n- [System prompt](#system-prompt)\n- [Session](#session)\n- [Turn](#turn)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 3 — Tools & Environment\u003C\u002Fsummary>\n\n- [Environment](#environment)\n- [Filesystem](#filesystem)\n- [Tool](#tool)\n- [Tool call](#tool-call)\n- [Tool result](#tool-result)\n- [MCP](#mcp)\n- [Permission request](#permission-request)\n- [Permission mode](#permission-mode)\n- [Agent mode](#agent-mode)\n- [Sandbox](#sandbox)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 4 — Failure Modes\u003C\u002Fsummary>\n\n- [Sycophancy](#sycophancy)\n- [Hallucination](#hallucination)\n- [Parametric knowledge](#parametric-knowledge)\n- [Knowledge cutoff](#knowledge-cutoff)\n- [Contextual knowledge](#contextual-knowledge)\n- [Attention relationship](#attention-relationship)\n- [Attention budget](#attention-budget)\n- [Attention degradation](#attention-degradation)\n- [Smart zone](#smart-zone)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 5 — Handoffs\u003C\u002Fsummary>\n\n- [Clearing](#clearing)\n- [Handoff](#handoff)\n- [Handoff artifact](#handoff-artifact)\n- [Spec](#spec)\n- [Ticket](#ticket)\n- [Compaction](#compaction)\n- [Autocompact](#autocompact)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 6 — Memory and Steering\u003C\u002Fsummary>\n\n- [Memory system](#memory-system)\n- [AGENTS.md](#agentsmd)\n- [Progressive disclosure](#progressive-disclosure)\n- [Context pointer](#context-pointer)\n- [Skill](#skill)\n- [Subagent](#subagent)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>Section 7 — Patterns of Work\u003C\u002Fsummary>\n\n- [Human-in-the-loop](#human-in-the-loop)\n- [AFK](#afk)\n- [Automated check](#automated-check)\n- [Automated review](#automated-review)\n- [Human review](#human-review)\n- [Vibe coding](#vibe-coding)\n- [Design concept](#design-concept)\n- [Grilling](#grilling)\n\n\u003C\u002Fdetails>\n\n## Section 1 — The Model\n\n### Model\n\nThe [parameters](#parameters). [Stateless](#stateless) — does [next-token prediction](#next-token-prediction) and nothing else. \"Claude Opus 4.7\" and \"GPT-5\" are models. On its own a model can't do anything agentic; it has to be [harnessed](#harness).\n\n*Usage:*\n\n\"Should we switch the model from Sonnet to Opus for the planning step?\"\n\n\"Try it — but the harness is doing most of the lifting on this task. The model swap won't help if the [system prompt](#system-prompt) and [tools](#tool) are wrong.\"\n\n### Parameters\n\nThe numbers inside a [model](#model) — often billions of them — tuned during [training](#training). Everything the model \"knows\" lives in them. Training sets them; [inference](#inference) uses them unchanged. Also called *weights*.\n\n*Usage:*\n\n\"Can we fine-tune it on our codebase?\"\n\n\"That'd update the parameters — different model afterwards. For one project it's almost always cheaper to load the codebase as [context](#context) than to retrain.\"\n\n### Training\n\nThe process that sets a [model](#model)'s [parameters](#parameters), by exposing it to vast amounts of text and adjusting parameters to improve [next-token prediction](#next-token-prediction). A one-time, expensive process done by the [model provider](#model-provider). Encompasses both pre-training (the bulk run) and post-training (later refinements like instruction-following and safety); the distinction doesn't matter at this glossary's level.\n\n*Usage:*\n\n\"Can we get it to know our internal API?\"\n\n\"Not via training — that's a months-long process by the model provider. Load the API docs into [context](#context) instead, that's the lever you actually have.\"\n\n### Inference\n\nRunning a trained [model](#model) to generate output — what happens on every [model provider request](#model-provider-request). [Parameters](#parameters) stay fixed; the model just does [next-token prediction](#next-token-prediction) over the [context](#context) it's given. Cheap relative to [training](#training), but billed per [token](#token) and the dominant cost of using a model.\n\n*Usage:*\n\n\"Why does the bill scale with usage instead of being a flat license?\"\n\n\"You're paying for inference — every model provider request runs the model on the provider's hardware. Training already happened, but inference costs accrue per request, and a single [turn](#turn) can expand into many requests when [tools](#tool) are called.\"\n\n### Token\n\nThe atomic unit a [model](#model) reads and writes. Roughly word-sized but not exactly — common words are one token, rare or long ones split into several. [Context window](#context-window) size, cost, and latency are all counted in tokens.\n\n*Avoid:* \"word\" — token boundaries don't match word boundaries, and tokens-per-second \u002F tokens-per-dollar are the units that actually matter.\n\n*Usage:*\n\n\"How big is this prompt going to be?\"\n\n\"Run it through the tokenizer — the schema's compact but the JSON keys are weird, so they'll split into more tokens than you think.\"\n\n### Next-token prediction\n\nWhat the [model](#model) actually does. Given a [context](#context), it samples one next [token](#token), appends it, and runs again. Every output — a sentence, a [tool call](#tool-call), a thousand-line file — is built one token at a time. The model has no other mode of operation.\n\n*Usage:*\n\n\"How does the [agent](#agent) 'decide' to call a tool?\"\n\n\"It doesn't — it's next-token prediction all the way down. The tool call is just a structured string the [harness](#harness) parses out of the output stream.\"\n\n### Non-determinism\n\nThe same input can produce different output. Run a [model](#model) twice with identical [context](#context) and you may get two different answers — sometimes a word, sometimes a completely different approach. Nothing in your code has to change for this to happen.\n\nIt's a property of how models generate text, and how [model providers](#model-provider) serve [requests](#model-provider-request). There's no setting you can flip to make it go away.\n\nExpect a spread of results from an [agent](#agent) on the same task. Some days the model will feel sharp; some days it'll feel like it's lost the plot. Same task, different rolls of the dice.\n\nBe careful not to over-narrativize this. Humans are pattern-matching machines, and a string of bad runs can feel like proof that \"the model got worse this week.\" Usually it's just the distribution.\n\n_Usage:_\n\n\"Claude has been awful today. Did they ship a worse version?\"\n\n\"Probably not — model output is non-deterministic. You're going to have good days and bad days on the same task. Try again tomorrow before you go looking for a cause.\"\n\n### Model provider\n\nWhatever serves a [model](#model) for [inference](#inference). Usually a remote service (Anthropic, OpenAI, Google), but can also be local — Ollama, LM Studio, llama.cpp running on your own machine. The [harness](#harness) doesn't run the model itself; it asks a provider to.\n\n*Usage:*\n\n\"Can we run this offline for the air-gapped client?\"\n\n\"Swap the model provider to a local one — Ollama or llama.cpp on their box. The harness doesn't care, it just hits a different endpoint.\"\n\n### Harness\n\nEverything around the [model](#model) that turns it into an [agent](#agent): [tools](#tool), [system prompt](#system-prompt), [context-window management](#context-window), permissions, hooks. **Claude.ai** and **Claude Code** run on the same model but behave differently because their harnesses differ.\n\n*Usage:*\n\n\"Same model, why is Claude Code editing files and Claude.ai just answering questions?\"\n\n\"Different harnesses — Claude Code has [filesystem](#filesystem) tools, a different system prompt, and a permission layer. The model isn't the variable here.\"\n\n### Model provider request\n\nOne round-trip from the [harness](#harness) to the [model provider](#model-provider). The harness sends the current [context](#context); the provider returns one response (a [tool call](#tool-call) or a final answer). A single user message can spawn many model provider requests if the [agent](#agent) calls [tools](#tool) — each [tool result](#tool-result) triggers another request.\n\n*Usage:*\n\n\"One question burned forty thousand [tokens](#token)?\"\n\n\"Look at the tool calls — twelve grep, eight read, four edits. Each tool result spawns another model provider request, and the whole [session](#session) prefix re-sends every time.\"\n\n### Input tokens\n\n[Tokens](#token) the [harness](#harness) sends on each [model provider request](#model-provider-request). Billed at a lower rate than [output tokens](#output-tokens).\n\n*Usage:*\n\n\"Bill's high but the [agent](#agent)'s barely writing anything.\"\n\n\"It's the input tokens — every [turn](#turn) re-sends the whole [session](#session). Without the [prefix cache](#prefix-cache) you re-pay for the history each request.\"\n\n### Output tokens\n\n[Tokens](#token) the [model](#model) generates back. Billed at a higher rate than [input tokens](#input-tokens), since they cost more compute to produce.\n\n*Usage:*\n\n\"The refactor [session](#session) is burning through credit even though the inputs are small.\"\n\n\"[Agent](#agent)'s rewriting whole files instead of patching. Output tokens cost roughly five times the input rate — get it emitting edits and the bill drops.\"\n\n### Prefix cache\n\nThe [provider](#model-provider)-side store that lets consecutive [model provider requests](#model-provider-request) skip re-processing a shared prefix. When the start of a request matches the start of a recent one — same [system prompt](#system-prompt), same history up to some point — the provider reuses its prior work and bills those [tokens](#token) as [cache tokens](#cache-tokens) at a much lower rate.\n\nAnything that changes the prefix (reordering files, rewriting the system prompt mid-[session](#session), injecting a timestamp near the top) invalidates the cache from that point on, and the rest of the request bills at full [input token](#input-tokens) rate.\n\n_Usage:_\n\n\"Why did the bill spike halfway through the session?\"\n\n\"[Harness](#harness) started injecting the current time into the system prompt every [turn](#turn). Prefix cache breaks at the first changed token, so every request after that billed at full rate.\"\n\n### Cache tokens\n\n[Input tokens](#input-tokens) the [provider](#model-provider) has cached from a previous [model provider request](#model-provider-request) so it doesn't have to re-process them. When consecutive requests share a prefix, the provider reuses the work via its [prefix cache](#prefix-cache) and bills the cached portion at a much lower rate. The lever that makes long [sessions](#session) affordable — without it, every [turn](#turn) re-pays for the whole history.\n\n*Usage:*\n\n\"Cost on long sessions is brutal — eight bucks for a refactor.\"\n\n\"Check the cache tokens. If the [harness](#harness) is reordering the [system prompt](#system-prompt) or files between turns, the prefix breaks and you re-pay full input rate every request.\"\n\n## Section 2 — Sessions, Context Windows & Turns\n\n### Stateless\n\nCarries no information forward. The [model](#model) is stateless across [model provider requests](#model-provider-request) — each request resends the full [context window](#context-window), because the model has no way to see anything else. An [agent](#agent) is stateless across [sessions](#session) by default: a new session starts empty, with no trace of prior ones. Counterpart to [stateful](#stateful).\n\n*Usage:*\n\n\"Why does it forget the convention every time I [clear](#clearing)?\"\n\n\"The model's stateless — the new session starts empty. If you want it carried, write it to [AGENTS.md](#agentsmd) or a memory file the [harness](#harness) loads at session start.\"\n\n### Context\n\nThe relevant information the [agent](#agent) has access to right now. The abstract noun — not the raw input the model sees (that's the [context window](#context-window)), not the running history (that's the [session](#session)), but *what the agent knows that's pertinent to the task*. \"Loading something into context\" means making it part of this set; \"context engineering\" is the discipline of curating it.\n\n*Usage:*\n\n\"It keeps inventing fields that aren't in the type.\"\n\n\"The type file isn't in context — it's reading the call sites and guessing. Read the definition in first.\"\n\n### Context window\n\nEverything the [model](#model) sees on each [model provider request](#model-provider-request). Finite, model-specific, and the *only* surface through which the model perceives anything.\n\n*Avoid:* \"memory\" — the context window is working state and doesn't persist across [sessions](#session). [Memory](#memory-system) is a separate concept layered on top.\n\n*Usage:*\n\n\"Can I just paste the whole monorepo into the prompt?\"\n\n\"The context window's 200k [tokens](#token) — that's maybe a fifth of the repo. Pick the files the task touches, leave the rest behind a [tool call](#tool-call).\"\n\n### Stateful\n\nCarries information forward. A [session](#session) is stateful across [turns](#turn) — [context](#context) accumulates as the session runs, which is why long sessions drift into the [dumb zone](#smart-zone). An [agent](#agent) can be made stateful across **sessions** by adding a [memory system](#memory-system) that persists information into the [environment](#environment) and reloads it at the start of future sessions. The [model](#model) is never stateful; any apparent continuity is the [harness](#harness) re-feeding context. Counterpart to [stateless](#stateless).\n\n*Usage:*\n\n\"It remembered my preferences from yesterday — does that mean the model learned them?\"\n\n\"No, the agent's stateful because the harness wrote them to a memory file and reloaded them at session start. The model itself saw nothing of yesterday.\"\n\n### Agent\n\nA [model](#model) [harnessed](#harness) with [tools](#tool), a [system prompt](#system-prompt), and a [context window](#context-window), that takes [turns](#turn) with a user. *Claude Code is an agent. Cursor is an agent. Claude.ai is an agent.* An agent is what you actually talk to — it's the model in motion, configured for a purpose.\n\n*Avoid:* \"the AI\", \"the bot\" (too vague — they hide whether you mean the parameters or the harnessed thing).\n\n*Usage:*\n\n\"Which agent are you using for the migration?\"\n\n\"Claude Code locally, Cursor for the UI work — same model underneath, different harnesses.\"\n\n### System prompt\n\nThe instructions the [harness](#harness) prepends to every [model provider request](#model-provider-request) — the [agent](#agent)'s standing brief: who it is, how to behave, which [tools](#tool) it can call, what conventions to follow. Usually stable across a [session](#session).\n\n*Usage:*\n\n\"Two harnesses, same [model](#model), totally different behavior on the same prompt.\"\n\n\"Different system prompts. One's tuned for terse code edits, the other for explaining — that's where the divergence lives, before your message even arrives.\"\n\n### Session\n\nOne bounded run of interaction with an [agent](#agent). Starts empty, accumulates messages, [tool results](#tool-result), and files read, and ends when [cleared](#clearing), closed, or [compacted](#compaction) into a fresh session. The session is what *fills* the [context window](#context-window): if the context window is the box, the session is the stuff slowly filling it up. Work too large for a single context window must be split across sessions.\n\n*Usage:*\n\n\"How long can one session run before it falls apart?\"\n\n\"Depends on the work — a focused refactor stays sharp longer than open-ended research. Once the session bloats, [hand off](#handoff) or compact, don't push through.\"\n\n### Turn\n\nOne user message plus everything the [agent](#agent) does in response, up until it yields back to the user. Contains one or more [model provider requests](#model-provider-request) — many, if the agent calls [tools](#tool). A clarifying question closes the turn; your reply opens the next one. The hierarchy is [session](#session) **> Turn > Model provider request**.\n\n*Usage:*\n\n\"One turn took two minutes?\"\n\n\"It made fourteen [tool calls](#tool-call) inside that turn — each one is a separate model provider request. Latency stacks up before the agent finally yields back to you.\"\n\n## Section 3 — Tools & Environment\n\n### Environment\n\nThe world the [agent](#agent) acts on — anything outside the [harness](#harness) that the agent perceives through [tool results](#tool-result) and changes through [tool calls](#tool-call). The harness *runs* the agent; the environment is what the agent *works in*. A file like [`AGENTS.md`](#agentsmd) lives in the environment; the harness is what loads it into the [context window](#context-window). A [filesystem](#filesystem) is the most common kind of environment, but not the only one (a database, a remote API, a browser session can all be environments).\n\n*Avoid:* using \"environment\" for the runtime or the harness itself — the harness is the wrapper, the environment is the workspace.\n\n*Usage:*\n\n\"The agent can't see the staging DB schema.\"\n\n\"Wire it into the environment — give it a `psql` [tool](#tool) scoped to read-only on staging. The harness is fine, it just has nothing to act on.\"\n\n### Filesystem\n\nA tree of files and directories the [agent](#agent) reads from, writes to, and executes within — the default kind of [environment](#environment) for a coding agent. [AGENTS.md](#agentsmd), [skills](#skill), source code, build scripts, and [tool](#tool) configs all live in a filesystem. When a [harness](#harness) \"starts in your project,\" it's pointing the agent at a filesystem.\n\n*Usage:*\n\n\"Why isn't it picking up my AGENTS.md?\"\n\n\"It's running against a different filesystem — the [sandbox](#sandbox) mounted the parent dir, not the project root. Repoint the harness.\"\n\n### Tool\n\nA function the [harness](#harness) exposes for the [agent](#agent) to call — Read, Write, Bash, Search. Tools are how an agent perceives and acts on the [environment](#environment): it can't see the environment except through [tool results](#tool-result), and can't change it except through [tool calls](#tool-call). Each tool call costs an extra [model provider request](#model-provider-request), since the result has to go back to the model before it can decide what to do next.\n\n*Usage:*\n\n\"Can the agent query staging directly?\"\n\n\"Add a `psql` tool to the harness, scoped read-only on staging. Without a tool for it, the agent's blind to anything outside the [filesystem](#filesystem).\"\n\n### Tool call\n\nThe [model](#model)'s output naming a [tool](#tool) and its arguments — just structured text. It doesn't do anything on its own; the [harness](#harness) has to read it and execute. Produced by the model in one [model provider request](#model-provider-request).\n\n*Usage:*\n\n\"It said it ran the tests but the file timestamps haven't changed.\"\n\n\"Look at the transcript — did it actually emit a tool call, or just describe running them? The model produces the call, but if the harness didn't execute it, nothing happened.\"\n\n### Tool result\n\nWhat the [harness](#harness) sends back after executing a [tool call](#tool-call) — the file contents, the command output, the error. The [agent](#agent)'s only window onto the [environment](#environment). Travels back to the [model](#model) in the *next* [model provider request](#model-provider-request), where the model decides what to do with it. Tool call and tool result are two ends of the same exchange, both inside one [turn](#turn).\n\n*Usage:*\n\n\"It's reasoning about the file like it's empty.\"\n\n\"The tool result came back as a permission denial, not the contents. The model only saw the error string — it has no other window onto the file.\"\n\n### MCP\n\n**Model Context Protocol.** A protocol for plugging external tool servers into a [harness](#harness) — how an [agent](#agent) gets [tools](#tool) beyond what the harness ships with. The agent never \"calls MCP\"; it calls a tool, and the harness happens to have gotten that tool from an MCP server. Also exposes resources (read-only data) and prompts (reusable templates), but tool provision is the primary use.\n\n_Usage:_\n\n\"The agent needs to read tickets from Linear.\"\n\n\"Configure the harness to use the Linear MCP server — it exposes the Linear API as tools the agent can call. Saves you writing custom tool wrappers.\"\n\n### Permission request\n\nWhat the [harness](#harness) shows the user before executing a [tool call](#tool-call) that isn't pre-approved. The [model](#model) produces a tool call; instead of running it immediately, the harness pauses and asks. Approve and it runs; deny and the harness reports the denial back to the model as a [tool result](#tool-result). The mechanism by which a harness puts a human in the [loop](#human-in-the-loop) for risky or sensitive actions.\n\n*Usage:*\n\n\"It's been blocked on a permission request for ten minutes — I was in a meeting.\"\n\n\"That's the cost of human-in-the-loop. Pre-approve the safe [tools](#tool) so the request only fires on the actually-risky calls.\"\n\n### Permission mode\n\nThe permission-gating slice of an [agent mode](#agent-mode) — which [tool calls](#tool-call) trigger a [permission request](#permission-request) and which run automatically. The original purpose of mode systems before [harnesses](#harness) started bundling behavioral instructions on top.\n\n*Usage:*\n\n\"It paused on every grep — totally killed the [AFK](#afk) run.\"\n\n\"Loosen the permission mode for read-only [tools](#tool), keep prompting on writes and shell. Most permission requests on a research [session](#session) are noise.\"\n\n### Agent mode\n\nA preset that shapes how the [agent](#agent) operates at runtime — bundles a [permission mode](#permission-mode) with behavioral instructions injected into the [system prompt](#system-prompt). Examples: a default that prompts on risky calls, a **plan mode** that blocks edits and steers the agent toward research, an **accept-edits** mode that auto-approves edits, a **bypass permissions** mode (colloquially **YOLO mode**) that auto-approves everything. Can flip [mid-session](#session).\n\n*Vendor terms:* Claude Code calls these \"permission modes,\" Codex calls them \"approval modes\" — both predate behavioral bundling.\n\n*Usage:*\n\n\"It keeps editing files when I just want a plan.\"\n\n\"Switch to plan mode — it'll block writes and stay in research.\"\n\n\"What about for the [AFK](#afk) run later?\"\n\n\"Bypass mode, but only inside the [sandbox](#sandbox).\"\n\n### Sandbox\n\nAn isolated [environment](#environment) the [agent](#agent) runs inside — a container, VM, ephemeral [filesystem](#filesystem), or restricted-permission shell. Limits the blast radius of agent actions: even if the agent runs destructive commands or fetches something malicious, the damage is contained. The safety substrate that makes [AFK](#afk) practical.\n\n*Usage:*\n\n\"I want to let it run [bypass-permissions](#agent-mode) overnight but I'm not ready for that.\"\n\n\"Put it in a sandbox — fresh container, no credentials mounted, no network out. Worst case it nukes its own filesystem and you discard the container.\"\n\n## Section 4 — Failure Modes\n\n### Sycophancy\n\nConfidently agreeable [model](#model) output. Caused by [training](#training): the model was shaped to favor answers humans liked, and humans tend to like agreement more than they like being told they're wrong. So the model learned that agreeing is rewarded — even when the agreement is incorrect.\n\n_Surfaces as:_\n\n- _Caving under pushback_ — reverses a correct answer when you say \"are you sure?\".\n- _Praising bad input_ — agrees your broken plan is brilliant before analysing it.\n- _Biased framing_ — review skews positive when you signal you wrote it; negative when you signal someone else did. Same artifact, different verdict.\n- _Mimicry_ — repeats your mistakes back to you as confirmation.\n\n_Diagnostic test:_ would the model have said this without your steer? If the only thing that changed was your tone or framing, it's sycophancy, not a real shift in analysis.\n\n_Fix:_ hide your preferences. Phrase prompts neutrally — \"review this code\" not \"is this code good?\".\n\n_Avoid:_ using \"sycophancy\" for any wrong answer that happens to please you. Without the diagnostic test, the term has no more value than \"wrong.\"\n\n_Usage:_\n\n\"It said my refactor plan looked great, then I asked 'are you sure?' and it walked the whole thing back.\"\n\n\"Classic sycophancy — it agreed first because you sounded confident, then caved because you sounded doubtful. The plan's quality didn't change, your tone did. [Clear](#clearing) and re-ask without signalling either way.\"\n\n### Hallucination\n\nConfidently-wrong [model](#model) output. Two flavors with different causes and fixes:\n\n- *Factuality hallucination* — invented or wrong facts about the world (a function that doesn't exist, a wrong API signature, a fake citation). Caused by [parametric knowledge](#parametric-knowledge) gaps, often past the [knowledge cutoff](#knowledge-cutoff). Fix: load the right [contextual knowledge](#contextual-knowledge).\n- *Faithfulness hallucination* — output drifts from the **contextual knowledge** that's loaded, the user's instructions, or the model's own prior reasoning. Symptom of [attention degradation](#attention-degradation); worsens in the [dumb zone](#smart-zone). Fix: [clear](#clearing) or [compact](#compaction).\n\n*Avoid:* \"hallucination\" as a bare synonym for \"wrong\" — without naming the flavor, the term has no diagnostic value.\n\n*Usage:*\n\n\"It hallucinated a `parseAsync` method on the schema.\"\n\n\"Factuality or faithfulness?\"\n\n\"The method exists in the docs I pasted — it just stopped reading them after [turn](#turn) forty.\"\n\n\"Faithfulness then. Compact and reload, don't bother adding more docs.\"\n\n### Parametric knowledge\n\nWhat the [model](#model) \"knows\" from [training](#training), stored in its [parameters](#parameters). Frozen at training time — the model can't see its own parameters or update them. Detail is lost in the squeeze: billions of facts cram into a fixed number of parameters, and the rare ones blur. Source of fluency on common topics, and of fabrication on uncommon ones. Counterpart to [contextual knowledge](#contextual-knowledge).\n\n*Usage:*\n\n\"It writes flawless React but invents methods on our internal SDK.\"\n\n\"React is dense in the parametric knowledge — millions of training examples. Your SDK isn't, so the model fills in plausible-looking shapes. Load the SDK docs into [context](#context).\"\n\n### Knowledge cutoff\n\nThe date past which a [model](#model) has no [parametric knowledge](#parametric-knowledge). Libraries, APIs, and events from after the cutoff are fabrication traps unless their docs are loaded as [contextual knowledge](#contextual-knowledge). Each model release ships with its own cutoff.\n\n*Usage:*\n\n\"It keeps writing the v3 SDK syntax — we're on v5.\"\n\n\"v5 shipped after the knowledge cutoff. Load the v5 changelog as contextual knowledge, otherwise it'll keep fabricating from the older parametric version.\"\n\n### Contextual knowledge\n\nFacts the [agent](#agent) can read directly from the [context](#context) right now — the user's task, files the agent has read in, [tool results](#tool-result), [AGENTS.md](#agentsmd) content loaded at [session](#session) start. Counterpart to [parametric knowledge](#parametric-knowledge): parametric is *recalled* from the parameters; contextual is *read* from the [window](#context-window). [Hallucinations](#hallucination) are much less common when the agent works from contextual knowledge — the answer is right in front of it, not dredged up from a blurred memory.\n\n*Reach for this term* only when contrasting with parametric knowledge; otherwise just say **context**.\n\n*Avoid:* \"working memory\" — contextual knowledge is what's in the window *now*; a [memory system](#memory-system) is what gets cross-session content into it. Different scales, don't conflate.\n\n*Usage:*\n\n\"Why does it nail the API when I paste the docs and fabricate it when I don't?\"\n\n\"With the docs in, it's contextual knowledge — reading off the page. Without, it's parametric and the rare endpoints blur.\"\n\n### Attention relationship\n\nWhen predicting each [token](#token), the [model](#model) factors in every other token in the [context](#context) — some heavily, others barely at all. The pairing between two tokens is an **attention relationship**, and meaningful pairs (\"her\" with \"Sarah\", or a `getUser()` call with its `function getUser` definition) influence each other more than unrelated ones. A context of N tokens has on the order of N² relationships.\n\n*Usage:*\n\n\"It keeps confusing the two `user` symbols across the diff — sounds like we're in the [dumb zone](#smart-zone).\"\n\n\"Yeah, the attention relationship between each call site and its declaration is fighting the other one — same token shape, different bindings. Rename one and the pairings sharpen.\"\n\n### Attention budget\n\nEach [token](#token) has a finite amount of influence to distribute across the rest of the [context](#context). Heavy influence on [one relationship](#attention-relationship) leaves less for others. The budget is per-token and doesn't grow when the context does, which is why long [sessions](#session) dilute.\n\n*Usage:*\n\n\"Why does it keep ignoring the schema I pasted at the top?\"\n\n\"We're well into the [dumb zone](#smart-zone) — every token's attention budget is fixed, but the context kept growing. The signal on the schema is now competing with thousands of newer tokens.\"\n\n### Attention degradation\n\nAs a [session](#session) grows, each [token](#token)'s [attention budget](#attention-budget) is spread across more competitors. The signal on any one [meaningful relationship](#attention-relationship) shrinks; noise from irrelevant [context](#context) crowds in. Same [model](#model), same [parameters](#parameters) — just more mouths to feed from the same plate. Cause of the smart zone \u002F dumb [zone effect](#smart-zone).\n\n*Usage:*\n\n\"It's deep in the dumb zone — inventing generics that aren't in the type file.\"\n\n\"Attention degradation. The type definitions are still in context, but the signal on them is buried under everything we've added since. [Clear](#clearing) and reload.\"\n\n### Smart zone\n\nEarly in a [session](#session) the [agent](#agent) is in a \"smart zone\" — sharp, focused, recall is good. As the session grows it drifts into a \"dumb zone\": sloppier, forgetful, more mistakes — and more \\*\\*faithfulness [hallucinations](#hallucination). Same [model](#model), same [harness](#harness) — just more [context](#context). The felt effect of [attention degradation](#attention-degradation). On frontier models, the dumb zone commonly begins around 100,000 tokens - though this is debated. [Clear](#clearing) or [compact](#compaction) when the session bloats; don't push through.\n\n_Usage:_\n\n\"It nailed the first three components and just butchered the fourth.\"\n\n\"You're out of the smart zone — same model, just deep into the dumb zone now. Compact and reload the plan, the next component will land.\"\n\n## Section 5 — Handoffs\n\n### Clearing\n\nEnding the current [session](#session) and starting a fresh one. The next message begins with an empty session and an empty [context window](#context-window). Usually user-driven.\n\n*Usage:*\n\n\"It's stuck looping on the failing test.\"\n\n\"Just clear it — start a fresh session with the plan doc and the test file. No point fighting the existing [context](#context).\"\n\n### Handoff\n\nTransferring [agent](#agent) [context](#context) from one [session](#session) to another, with no return path. The carry mechanism varies — a written [handoff artifact](#handoff-artifact), an in-memory summary ([compaction](#compaction)), and others. Distinct from [clearing](#clearing) (no transfer at all). Reasons vary: switching roles (planner → implementer), kicking off an [AFK](#afk) run, fanning out to parallel sessions, or freeing up [context window](#context-window) room.\n\n*Usage:*\n\n\"Planning session is getting heavy — should I just keep going?\"\n\n\"Do a handoff. Write the decisions to a doc, clear, start the implementation in a fresh session reading from it.\"\n\n### Handoff artifact\n\nA document used as the carry mechanism for a [handoff](#handoff) — written by one [session](#session) to be read by another. One way among several (see also **compaction**, [compaction](#compaction)).\n\n*Usage:*\n\n\"How do I split this between the planning [agent](#agent) and the implementing one?\"\n\n\"Have the planner write a handoff artifact — file paths, decisions, constraints. The implementer's session opens with a pointer to the artifact and works from it as its brief.\"\n\n### Spec\n\nA [handoff artifact](#handoff-artifact) describing a multi-[session](#session) piece of work — what's being built, not how each session does its share. Mutates as work progresses. Made of [tickets](#ticket).\n\n*Usage:*\n\n\"Should this all be one session?\"\n\n\"No, write it up as a spec — break it into tickets, run each one in its own session. Trying to do the whole thing in a single [context](#context) will hit the [dumb zone](#smart-zone) before you're halfway.\"\n\n### Ticket\n\nA [handoff artifact](#handoff-artifact) scoping one [session](#session) of work. Stands alone, or hangs off a [spec](#spec) as one of its children. Tickets can block or be blocked by sibling tickets, so the order of work falls out of their dependency graph rather than a linear plan.\n\n*Usage:*\n\n\"Where do I start on the migration spec?\"\n\n\"Look at the ticket graph — the schema change blocks the backfill, the backfill blocks the API switch. Pick a leaf and run a session on it.\"\n\n### Compaction\n\nA [handoff](#handoff) done in-memory: the previous [session](#session)'s history is summarised and seeds a fresh session. Lossy — detail traded for headroom. Triggered manually by the user, or [automatically](#autocompact).\n\n*Usage:*\n\n\"[Context](#context)'s getting heavy and I still have the test pass to do.\"\n\n\"Compact before you start — write what's load-bearing into the summary prompt so the new session keeps the schema decisions and drops the exploration.\"\n\n### Autocompact\n\n[Compaction](#compaction) triggered automatically by the [harness](#harness) when the [context window](#context-window) approaches full.\n\n*Usage:*\n\n\"It doesn't seem to remember what we decided about the schema earlier.\"\n\n\"Autocompact fired between [turns](#turn) — the early decisions got summarised and we must have lost something. Reload the plan doc, or compact manually next time so you control what gets kept.\"\n\n## Section 6 — Memory and Steering\n\n### Memory system\n\nA system that attempts to make an [agent](#agent) [stateful](#stateful) across [sessions](#session). Persists information into the [environment](#environment) during a session and reloads it into the [context window](#context-window) at the start of future ones, so the agent carries continuity beyond the user [clearing](#clearing) the session.\n\n*Usage:*\n\n\"I keep having to re-tell it I'm on Postgres, not MySQL.\"\n\n\"Wire up a memory system — write what it learns to the [filesystem](#filesystem) on the first [turn](#turn), reload it at session start. The [model](#model) itself is [stateless](#stateless); the memory layer fakes continuity.\"\n\n### AGENTS.md\n\nA file in the [environment](#environment) that the [harness](#harness) loads into the [context window](#context-window) at [session](#session) start — the project's standing brief to the [agent](#agent). Cross-harness convention.\n\n*Avoid:* using AGENTS.md for content that should be [progressively disclosed](#progressive-disclosure) — anything in it pays a [token](#token) cost every [turn](#turn).\n\n*Usage:*\n\n\"Why is every session starting with 4k tokens already burned?\"\n\n\"Check AGENTS.md — someone pasted the entire style guide in there instead of putting it behind a [skill](#skill).\"\n\n### Progressive disclosure\n\nLoading only the [context](#context) an [agent](#agent) needs right now, with [context pointers](#context-pointer) to the rest. Borrowed from UI design.\n\n_Usage:_\n\n\"Should I dump the entire style guide into [AGENTS.md](#agentsmd)?\"\n\n\"No — progressive disclosure. Reference the style guide as a [skill](#skill) the agent loads when it actually needs to write a component. AGENTS.md pays the [token](#token) cost every [turn](#turn).\"\n\n### Context pointer\n\nA mention in one document that points to another, so the [agent](#agent) can pull it into the [context window](#context-window) only when the task calls for it. The unit [progressive disclosure](#progressive-disclosure) is built from.\n\n_Avoid:_ \"reference\" — too dry; doesn't convey that following it pulls more context in. \"Portal\" — too florid.\n\n_Usage:_\n\n\"AGENTS.md is getting huge.\"\n\n\"Most of it should be context pointers, not content. Keep the always-on rules inline; turn the deploy runbook and the style guide into [skills](#skill) and leave a context pointer behind.\"\n\n### Skill\n\nA teachable capability bundled as a unit — instructions and resources for doing one task well, kept in the [environment](#environment) until a [context pointer](#context-pointer) pulls it into the [context window](#context-window) for the task at hand. The unit of [progressive disclosure](#progressive-disclosure) in a [harness](#harness).\n\n_Avoid:_ \"[tool](#tool)\" — a tool is what the [agent](#agent) _calls_; a skill is instructions it _reads_.\n\n_Usage:_\n\n\"Where should I put the deploy runbook?\"\n\n\"As a skill — the agent loads it only when the task involves deploys. In [AGENTS.md](#agentsmd) it'd burn [tokens](#token) on every [turn](#turn) for something we use weekly.\"\n\n### Subagent\n\nAn [agent](#agent) spawned by another agent via a [tool call](#tool-call). Runs in its own [session](#session) with its own [context window](#context-window), and reports a single [tool result](#tool-result) back. Distinct from a [handoff](#handoff) — the parent specifically expects a return; a handoff has no return path. **Cannot spawn further subagents** — the tree is one level deep. Subagents exist to isolate [context](#context), not to compose hierarchies.\n\n*Usage:*\n\n\"The grep results are blowing out my context.\"\n\n\"Spawn a subagent to do the search — it'll burn its own context window on the noise and report back the two file paths you actually need.\"\n\n## Section 7 — Patterns of Work\n\n### Human-in-the-loop\n\nA working pattern where one or more humans pair with the [agent](#agent) during a [session](#session) — reviewing, redirecting, or collaborating in real time. The human is present and engaged, not just gating individual actions.\n\n*Usage:*\n\n\"Run this [AFK](#afk) overnight?\"\n\n\"No, schema migration — keep it human-in-the-loop. I want to see each step and steer if it picks the wrong column to backfill from.\"\n\n### AFK\n\nA working pattern where the user kicks off a [session](#session) and leaves the [agent](#agent) to run unattended. The throughput multiplier of AI coding — many AFK sessions can run in parallel while you sleep, eat, or work on something else. Usually requires a permissive [permission mode](#permission-mode) plus [sandboxing](#sandbox) to be safe.\n\n*Avoid:* \"background agent\" — centers the machine (\"running in the background\") rather than the human pattern (\"user has walked away\"). AFK is the load-bearing fact: the user isn't watching.\n\n*Usage:*\n\n\"I'm running this AFK — three sandboxed agents on the refactor, reviewing the PRs in the morning.\"\n\n\"[Bypass permissions](#agent-mode)?\"\n\n\"Yeah, read-only [filesystem](#filesystem), no network.\"\n\n### Automated check\n\nA deterministic verification that runs in the [environment](#environment) — tests, type checks, lints, build, pre-commit hooks. Pass\u002Ffail, no judgement. The signal an [agent](#agent) can self-correct from without involving anyone else. A flaky test is a broken check, not a non-check; automated checks are deterministic *by design*.\n\n*Avoid:* \"feedback loop\" \u002F \"backpressure\" — both lump checks together with [review](#automated-review). *Avoid:* \"test\" — tests are automated checks, but not all automated checks are tests.\n\n*Usage:*\n\n\"The agent keeps shipping broken code in the [AFK](#afk) runs.\"\n\n\"What automated checks are wired into the [sandbox](#sandbox)?\"\n\n\"Just the unit tests.\"\n\n\"Add typecheck and lint — it'll self-correct from those before the PR ever lands.\"\n\n### Automated review\n\nAn [agent](#agent) reviewing another agent's work, often with a different [model](#model) or [system prompt](#system-prompt). Non-deterministic: it forms a judgement. Runs anywhere — pre-merge on a PR, post-hoc on commit history, mid-session as a [subagent](#subagent). An LLM-as-judge in CI is automated review, not an [automated check](#automated-check); what the assertion *does* decides the category, not where it runs.\n\n*Avoid:* \"AI review\" \u002F \"agent review\" — too vague to distinguish from the working agent itself.\n\n*Usage:*\n\n\"We're getting too many bad PRs from the [AFK](#afk) runs.\"\n\n\"Add an automated review step before merge — different model, separate system prompt, scoped to security and contract changes.\"\n\n### Human review\n\nThe user reading the code the [agent](#agent) produced and forming a judgement on it. Reading the diff or the changed files counts; reading the agent's *description* of what it did does not — narration is not the artifact.\n\n*Avoid:* \"code review\" alone — ambiguous between human and [automated](#automated-review).\n\n*Usage:*\n\n\"I human-reviewed the [AFK](#afk) output.\"\n\n\"You read the diff or just the summary?\"\n\n\"Diff. The summary said it deleted dead code — turned out the function was called from a generated file.\"\n\n### Vibe coding\n\nA working pattern where the user accepts the [agent](#agent)'s code without [human review](#human-review). The diff is treated as opaque — what matters is whether the program behaves, not what's inside. [Automated review](#automated-review) and [automated checks](#automated-check) may still run; vibe coding is silent on both.\n\n*Avoid:* \"vibe coding\" as a synonym for \"low-quality AI coding\" — the term names the review stance, not the resulting code.\n\n*Usage:*\n\n\"Did you read what it changed in the auth flow?\"\n\n\"Vibe coded it — login still works, that's all I checked.\"\n\n\"Read the diff before you push, vibing on auth is how secrets leak into logs.\"\n\n### Design concept\n\nThe shared understanding of what's being built, held in common between user and [agent](#agent) but separate from any asset. Brookes' term (*The Design of Design*): the conversation, [handoff artifacts](#handoff-artifact), and the code are all assets that try to capture or reach the design concept, but none of them *are* it. Quality of the design concept is felt through the quality of the conversation that built it.\n\n*Usage:*\n\n\"It's writing exactly what I asked for and it's still wrong.\"\n\n\"You don't share a design concept yet — it's filling gaps with assumptions. Keep talking until cancellation, refunds, and partial fulfilment all line up between you before you let it write a [spec](#spec).\"\n\n### Grilling\n\nA technique for developing a [design concept](#design-concept) with an [agent](#agent): the agent interviews the user Socratically, one decision at a time, proposing a recommended answer for each. Slows the rush to a finished plan — no [handoff artifact](#handoff-artifact) is written until the concept stabilises.\n\n*Usage:*\n\n\"It went straight to writing the [spec](#spec) and got the cancellation logic wrong.\"\n\n\"Grill it first — make it ask you about partial cancels, refunds, and timing before it commits anything to the doc. Cheaper to resolve in conversation than in code.\"\n\n","这个项目是一个AI编程术语词典，用通俗易懂的语言解释了复杂的AI编程概念。其核心功能是提供了一个全面且易于理解的AI相关词汇表，涵盖了从模型基础到工具环境等多个方面，并且支持深色和浅色主题显示。项目采用TypeScript编写，确保了良好的类型安全性和代码可维护性。适合任何希望快速掌握AI领域基础知识的开发者、学生或对AI感兴趣的初学者使用，帮助他们消除技术障碍，更好地理解和应用AI技术。",2,"2026-06-11 02:30:28","CREATED_QUERY"]