A–Z Reference: AI Development Terms

The glossary below defines the vocabulary of agentic engineering, the practice of building software with coding agents such as Claude Code, Codex and Cursor. It covers how agents run, what they know and may do, how they are extended, and how their output is proven. Each entry gives the meaning, each tool’s name for it, and the in-depth page.

A policy says the agent “may run unattended in a sandbox”. The developer reads that as auto mode, security reads it as network-off containers, and the Codex user sets approval_policy = "never" and believes the sandbox came with it. None of them is wrong about the words, but they have agreed to three different setups. This page is for the developer, tech lead, CTO or executive who needs one meaning per term before writing it into a spec, a policy or an AGENTS.md.

What this glossary settles for your team

• One spelling and one meaning per term, used across this site: “subagent”, not “sub-agent”; “Bugbot”, not “BugBot”.
• The Claude Code, Codex and Cursor name for the same idea, so a mixed-tool team can write one policy.
• The pairs of terms that cause real incidents when mixed up, with the fix for each.
• Two prompts and a CI check that hold your own repository to this vocabulary.

Tool facts on this page were checked on 2026-09-26 against Claude Code 2.1.283 (the latest channel) and Codex CLI 0.157.1. Cursor facts come from Cursor’s documentation as read on 2026-08-28, because cursor.com was unreachable from our environment on 2026-09-26.

Same idea, three names: how do Claude Code, Codex and Cursor name things?

Concept	Claude Code	Codex	Cursor
Project instructions	CLAUDE.md; reads AGENTS.md when there is no CLAUDE.md, from v2.1.277 (the latest channel)	AGENTS.md (/init creates one)	Rules
What the agent may do without asking	Permission mode (Manual, acceptEdits, plan, auto, dontAsk, bypassPermissions)	Approval policy plus sandbox or permission profile	Run modes
Automatic approval without prompting you	Auto mode (a classifier reviews actions)	Auto-review (--approve-for-me)	Auto-review for local tool calls
Plan before editing	Plan mode (/plan, Shift+Tab)	Plan mode (/plan)	Plan Mode
Parallel isolated checkout	--worktree	--worktree, /worktree	Worktrees
Delegated helper agent	Subagent (.claude/agents/)	Subagent (/subagents)	Subagents
Non-interactive run	claude -p	codex exec	Print mode (-p, --print)
Remote or scheduled work	--cloud, background sessions, Routines	Codex cloud, Automations	Cloud Agents, Automations
Code review by the agent	/code-review	/review, codex review	Bugbot (on pull requests)
Keep working until done	/goal	/goal	/goal (rolling out)
Installable bundle	Plugin (claude plugin)	Plugin (codex plugin)	Plugin

How do you hold your repository to one vocabulary?

A glossary helps only if the files agents read use it. Run these steps once, then keep the CI check.

1. Ask the agent to audit your instruction files and policies against this page with the first prompt below.
2. Ask the agent to translate your effective configuration into plain terms with the second prompt, and compare the answer with what your policy claims.
3. Add the terminology check to CI so retired terms cannot come back.

Copy-paste prompt: terminology audit of agent instructions

Read AGENTS.md, CLAUDE.md, every file under .cursor/rules/ and docs/ai-policy.md if they exist.
List every term that describes agent autonomy, permissions, sandboxing, review or "done"
(for example: unattended, auto, sandbox, approve, safe, verified, reviewed).
For each term, quote the sentence, say which concrete setting or check it maps to in this
repository (a permission mode, approval policy, sandbox mode, CI job or test suite), and flag it
when it maps to nothing or to two different things. Do not edit any file. Output a table:
term | file:line | maps to | problem | proposed wording.

Copy-paste prompt: explain what the configured autonomy allows

Inspect .claude/settings.json, .claude/settings.local.json, .mcp.json, .codex/config.toml and
~/.codex/config.toml if they exist. In plain language, tell me for each tool:
1. which permission mode or approval policy a session starts in,
2. what the sandbox or permission profile lets a shell command read, write and reach on the network,
3. which hooks run and on which events,
4. which MCP servers load and what each can change outside this repository.
Cite the file and key for every statement. If a value is not set, say which default applies and
that you are assuming it. Finish with the three settings a reviewer should check first.

The audit is verified without reading every line: each row cites file:line, so a reviewer spot-checks three rows and rejects the report if one is wrong. The configuration answer is verified by running the matching status commands yourself.

Claude Code

Run /status for the version, model and account, /permissions for allow and deny rules, /hooks for hook configuration, /mcp for servers, and /context for what fills the context window.

Codex

Run /status for the session configuration and token usage, /permissions for what Codex is allowed to do, /debug-config for config layers and requirement sources, /mcp for tools, and /hooks for lifecycle hooks.

Cursor

Cursor documents Rules, Hooks, MCP and Run modes as separate settings pages (checked 2026-08-28). Open each one and compare it with the agent’s answer; menu paths change between releases, so we do not list them here.

The CI check fails the build when a retired term reappears in the files agents read:

# Runs in CI. Globs skip missing paths, --hidden reaches .cursor/rules/,
# and the step fails when the search prints a match or rg itself errors. The patterns target the
# retired usage only; if your docs quote a retired term as a negative example,
# add an allow-list (for example a --glob '!docs/terminology.md' exclusion).
rc=0
hits=$(rg -n --hidden --no-messages \
  -e 'codex[^`]*--full-auto' -e 'BugBot' -e 'Background Agent' \
  -e 'approval_policy *= *"on-failure"' -e '(-a|--ask-for-approval) on-failure' \
  -g 'AGENTS.md' -g 'CLAUDE.md' -g '.cursor/rules/**' -g 'docs/**' .) || rc=$?
[ "$rc" -le 1 ] || { echo "rg failed with exit $rc"; exit 2; }
if [ -n "$hits" ]; then echo "$hits"; exit 1; fi

Which terms describe agents and how they run?

Agent (coding agent)

A model running in a loop with tools: it reads files, runs commands, edits code and checks results until it decides the task is done. Claude Code, Codex and Cursor are agents; the model is one part of each. See AI coding agents.

Agent loop

The repeated cycle of plan, act, observe and correct inside one session. A loop runs unattended only when an automated check, not the agent’s own opinion, decides when it stops.

Agentic engineering

Building software by specifying behaviour, delegating implementation to agents and verifying the result with evidence instead of reading every line. See the agentic engineering term page and how it compares with 20 other names.

Autonomy ladder

Dan Shapiro’s six-level scale, Level 0 to Level 5, for how much code agents write and how much humans still read. See the autonomy ladder.

Background and cloud agents

Sessions that keep running while you do something else. Claude Code has background sessions (--bg, managed with claude agents) and cloud sessions (--cloud). Codex has Codex cloud. Cursor calls its remote agents Cloud Agents, which run in isolated VMs; the older name “Background Agents” is retired. See background agents.

Goal

A completion condition the agent keeps working toward across turns. /goal exists in Claude Code and Codex, and Cursor lists it as rolling out. See the /goal command.

Headless mode

Running an agent without an interactive session, usually in CI: claude -p, codex exec, or Cursor’s print mode. In Claude Code 2.1.283 (the latest channel), -p skips the workspace trust dialog, so run it only in directories you trust. See headless mode.

Routine and automation

Saved agent runs started by a schedule or an event. Claude Code calls them Routines (/schedule, research preview); Codex and Cursor call them Automations.

Software factory

A pipeline in which agents pull work from a queue, build and verify it, and open pull requests with little or no human reading the diff. See software factories and the software factory term page.

Subagent

A helper agent the main agent starts for one subtask, with its own context window, so the parent’s context stays small. Claude Code ships built-in Explore, Plan and general-purpose subagents and reads custom ones from .claude/agents/. Codex manages them with /subagents; Cursor calls them Subagents. See subagents.

Agent team

In Claude Code, a lead session plus peer sessions that share a task list and message each other. It is experimental and off by default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Unlike subagents, teammates are full sessions.

Which terms describe what the agent knows?

Context window

Everything the model can see in one request, measured in tokens: instructions, conversation, file contents and tool output. Limits differ by model and tool; the models hub lists them. See context windows and the context window term page.

Token

The unit models read, write and bill by. Word-to-token ratios vary by tokenizer: Anthropic states that its Claude 4.7 and later tokenizer produces roughly 30% more tokens for the same text than earlier models (pricing page, checked 2026-09-26).

Compaction

Summarising the conversation so far to free context. Claude Code and Codex compact automatically near the limit and on demand with /compact; both expose PreCompact and PostCompact hook events. Compaction drops detail, so durable facts belong in instruction files, not the chat.

AGENTS.md

An open Markdown format for agent instructions: build commands, conventions, boundaries. Codex reads it before doing any work; Claude Code reads it when a project has no CLAUDE.md, from v2.1.277 (the latest channel). See AGENTS.md.

CLAUDE.md

Claude Code’s instruction file, loaded from the project root and ~/.claude/CLAUDE.md at session start, and from a subdirectory when the agent works there. /init drafts one, /memory edits it, and @path/to/file imports another file into it. See CLAUDE.md.

Rules

Cursor’s name for project and user instructions the agent follows. See Cursor project rules.

Memory

Knowledge that survives between sessions. Claude Code has instruction files plus auto memory, which records learnings on its own. Codex has memories, stable but off by default in 0.157.1 (/memories).

Codebase indexing and agentic search

Two ways an agent finds code. Indexing builds a searchable embedding of the repository ahead of time; agentic search reads and greps files on demand. See codebase indexing.

Intent, spec and plan

The first three files of the artifact chain: intent.md says why the work matters, spec.md says what “done” means in testable terms, and plan.md says how the agent will get there. See the artifact chain.

Which terms describe what the agent may do?

Permission mode

Claude Code’s setting for which actions run without asking: default (shown as Manual), acceptEdits, plan, auto, dontAsk and bypassPermissions. Shift+Tab cycles them. See permissions and sandboxing.

Auto mode

The Claude Code permission mode in which a classifier model reviews each action instead of you. From v2.1.283 on the latest channel it is the starting mode for interactive terminal and VS Code sessions on supported models; claude -p, the Agent SDK and unsupported models such as Haiku still start in Manual.

Approval policy

Codex’s setting for when it asks before acting: untrusted, on-request (the default), granular or never. On the command line, -a accepts only on-request and never in 0.157.1, and it goes before the subcommand: codex -a never exec.

Sandbox

An operating-system boundary on what agent commands can read, write and reach on the network. Claude Code sandboxes Bash with Seatbelt on macOS and bubblewrap on Linux and WSL2. Codex offers --sandbox read-only, workspace-write or danger-full-access. See sandbox.

Permission profile

Codex’s newer, preferred way to set the sandbox, in beta: default_permissions in config.toml, with built-ins such as :read-only and :workspace. OpenAI states that profiles and the legacy --sandbox flag do not compose, so pick one.

Plan mode

A read-only mode in which the agent investigates and proposes a plan, and edits stay blocked until you approve it. See plan mode.

Worktree

A second Git checkout of the same repository in its own directory, so parallel agents do not overwrite each other. See Git worktrees.

Bypass mode

Running with every permission check off: --dangerously-skip-permissions in Claude Code, --dangerously-bypass-approvals-and-sandbox in Codex. Claude Code recommends it only for sandboxes with no internet access; Codex reserves it for environments that are already externally sandboxed (checked in 2.1.283 / 0.157.1 help). Use it nowhere else. “YOLO mode” is the informal name; do not put it in policies.

Checkpoint

A saved point you can return to. Claude Code’s /rewind (or Esc twice on an empty prompt) restores earlier code and conversation. Treat Git commits as the checkpoint of record.

Prompt injection

Instructions hidden in content the agent reads, such as an issue, a web page or a dependency README, that redirect it. See the agent threat model.

What are MCP servers, skills, plugins and hooks?

MCP (Model Context Protocol)

An open protocol that connects agents to tools and data. The current specification is dated 2026-07-28, and Anthropic donated MCP to the Agentic AI Foundation in December 2025. See MCP and the 2026-07-28 spec.

MCP server

A process that exposes tools, resources or prompts over MCP. Add one with claude mcp add or codex mcp add. Each server adds tool definitions to the context; Claude Code and Codex load them on demand through tool search, which is on by default. See essential MCP servers.

Agent Skills

An open format for reusable instructions: a folder with a SKILL.md whose name (at most 64 characters) and description (at most 1,024) are always visible to the agent, and whose body loads only when the task matches. The spec lists 46 compatible clients (checked 2026-09-26). The skills CLI (1.7.0 on npm) installs them across agents with npx skills add OWNER/REPO. See Agent Skills.

Slash command

A /name shortcut typed in the session. In Claude Code, custom commands are now skills. See slash commands.

Plugin

An installable bundle of skills, subagents, hooks and MCP configuration, distributed through a marketplace. See plugins.

Hook

A script or handler that runs on an agent lifecycle event and can block the action. Claude Code documents 33 events; Codex 0.157.1 has 12 and asks you to trust a hook before it runs. See hooks.

Harness

Everything around the model: context, tools, permissions, hooks, skills, plugins and environment. See the harness and harness engineering.

Which terms describe how agent output is proven correct?

Acceptance criteria (executable)

Each requirement written as a Given/When/Then scenario with a test that fails before the code exists. See acceptance criteria.

Oracle and oracle strength

The oracle is whatever decides a change is correct. Oracle strength is how likely it is to fail when the code is wrong, measured with mutation score, behaviour coverage, test provenance and flake rate. See oracle strength.

Protecting the oracle

Making tests and CI configuration impossible for the agent to change in the task they judge. See protect the oracle.

Evidence bundle

A structured block in an agent’s pull request that maps each acceptance criterion to a check that ran. CI blocks the merge when it is incomplete. See the evidence bundle.

Eval

A fixed set of real tasks run against two agent configurations and scored by code. See evals for coding agents.

Model-graded check

A CI gate in which a different model grades an artifact against a rubric. See model-graded checks.

Fitness function

An automated structural rule, such as no layer violations or a complexity budget, that fails the build. See fitness functions.

Characterization test

A test that records what existing code does today, so an agent can refactor against it. See characterization tests.

Slop

Agent-written code that compiles, passes its tests and reads well but is wrong, such as swallowed errors or weakened tests. See slop detection.

Human in the loop

The four decisions a person keeps: intent, spec, evidence and risk class. See human in the loop.

Risk class

A label on a change that decides whether a human must read the code, for example auth, money, schema or migrations.

Vibe coding

Accepting agent output without verifying it. Fine for throwaway prototypes, and the opposite of what this site teaches for production code. Andrej Karpathy introduced the term on 2 February 2025. See vibe coding.

Which terms describe models, effort and cost?

Default model

The model a tool uses when you choose nothing. On 2026-09-26 that was Claude Opus 5.5 in Claude Code (v2.1.280+ on the latest channel) and GPT-6 Astra in Codex. Prices and the full lineup live on the models hub.

Effort

How much reasoning the model spends per step. Claude Code takes low, medium, high, xhigh and max through /effort or --effort, and Opus 5.5 defaults to medium. Codex sets effort with /model, and GPT-6 Astra defaults to low. Raise effort before switching model.

Fast mode

A faster serving tier at a higher cost per token: fast mode in Claude Code, the Fast service tier in Codex.

Usage limits

Subscription allowances. Claude Code and Codex both meter usage in rolling five-hour and weekly windows.

Open-weight model

A model whose weights you can download and host. See open-weight models.

Which terms describe the method?

AI-native SDLC

A looped lifecycle in which agents do the mechanical work at every stage and humans decide at gates. Also called the agentic SDLC or the AI SDLC. See the AI-native SDLC and the AI SDLC term page.

Artifact chain

The versioned files each stage hands to the next: intent, spec, plan, diff and tests, pull request, incident record. See the artifact chain.

Spec-driven development

Keeping spec.md authoritative, with a spec delta in every behaviour-changing pull request. See spec-driven development and the spec-driven development term page.

Which names describe ways of working with AI, and how do they differ from vibe coding?

The pillar article Vibe coding vs agentic engineering: 21 terms compared gives each name’s origin, a dated quote and its contrast with vibe coding. The entries below are the short versions.

Agentic coding

Using a tool in which an AI agent plans, writes, runs and tests code in a loop toward a goal. The term names what the tool does, not how carefully you use it, so you can vibe code with it. See agentic coding.

Agentic software development

Software delivery in which autonomous agents work across the whole lifecycle and humans stay accountable at gates (Forrester, 8 June 2026). Its scope is the lifecycle, not one session. See agentic software development.

Vibe engineering

Simon Willison’s proposed name (7 October 2025) for professionals who use LLMs while staying accountable for what ships. On 23 February 2026 he wrote that “agentic engineering” was coming out on top. See vibe engineering.

Augmented coding

Kent Beck’s name for coding with an AI “genie” while caring about the code, its complexity and its tests. It began as his word for vibe coding (18 April 2025) and became its contrast on 25 June 2025. It is not Gartner’s AI-augmented development. See augmented coding.

AI-assisted coding

The umbrella for every way of using AI to help write software, from autocomplete to agents to vibe coding. Willison calls vibe coding its “less responsible subset”. See AI-assisted coding.

AI pair programming

Treating the AI as a second programmer whose suggestions you read as they appear, popularised by GitHub Copilot on 29 June 2021. On this site’s autonomy ladder it is Level 2. See AI pair programming.

Prompt engineering

Writing effective instructions for a model. It concerns the quality of the input and says nothing about reviewing the output. See prompt engineering and prompt engineering for Claude Code.

Context engineering

Deciding what information, tools and instructions a model sees at each step. Tobi Lütke and Andrej Karpathy popularised the name in June 2025. See context engineering and context management.

Harness engineering

Turning each recurring agent mistake into a permanent control: an instruction, a tool, a test or a linter rule. Mitchell Hashimoto named the practice in writing on 5 February 2026. See harness engineering.

Compound engineering

Every’s method, and plugin, for making each change leave the next one easier: the compound step writes each lesson into files the next run reads. Kieran Klaassen introduced it on 18 August 2025. See compound engineering.

AI engineering

The discipline and job of building applications on foundation models, popularised by swyx on 30 June 2023. It is a different job from agentic engineering, which uses coding agents to build any software; some pages on this site use the phrase in the second sense. See AI engineering.

Agentic workflows

LLM applications designed so the model works in several passes, with reflection, tools or other agents, popularised by Andrew Ng in March 2024. GitHub Agentic Workflows is a separate product. See agentic workflows.

Agent orchestration

Coordinating several agents on one body of work: split it, run the pieces in parallel or in sequence, then merge. It multiplies whatever review discipline already exists. See agent orchestration and orchestration patterns.

AI-driven development

A generic label for AI leading the work, with no single owner. Its strongest anchor is AWS’s AI-Driven Development Lifecycle. See AI-driven development.

AI-DLC

AWS’s AI-Driven Development Lifecycle, introduced by Raja SP on 31 July 2025: AI proposes, and the team validates in “Mob Elaboration” and “Mob Construction”. See AI-DLC and the AI-DLC comparison.

AI-native development

A posture in which a team redesigns its process around AI instead of adding AI to the old process, popularised by Tessl on 6 July 2024. See AI-native development.

Which glossary terms do teams confuse, and what breaks?

Confused pair	What breaks	Recovery
Approval policy and sandbox (Codex)	approval_policy = "never" is read as “safe”; commands then run with whatever sandbox was already set	Set both in the same config block, and state both in the policy
Auto mode, auto-review and Auto-review	Three vendors, three similar names, three different mechanisms; a policy approving “auto” approves an unknown one	Name the tool and setting: “Claude Code auto permission mode”, “Codex --approve-for-me”
CLAUDE.md and AGENTS.md	From v2.1.277 (the latest channel), Claude Code reads AGENTS.md only when there is no CLAUDE.md, so adding a CLAUDE.md silently hides your AGENTS.md	Keep rules in AGENTS.md and make CLAUDE.md import it with @AGENTS.md
Skill, MCP server and plugin	A team builds an MCP server for what a 30-line skill does, or installs the same skill twice through a plugin and npx skills	Skill for instructions, MCP server for live tools, plugin to ship both together
Subagent and agent team	Expecting subagents to coordinate with each other; they report only to the parent	Use an agent team or an orchestration script when workers must talk
Tests pass and oracle is strong	The agent wrote the tests it then passed	Lock tests before implementation and measure oracle strength
“Default model” from memory	Claude Code’s stable channel still had older defaults on 2026-09-26	Check /status or /model in the session, not a blog post
Cursor “Background Agent” and “BugBot”	Old names break search in Cursor’s docs	Write Cloud Agents and Bugbot

Where to go next with the vocabulary

• The AI coding glossary: a free page for each term, with the three tools compared.
• Vibe coding vs agentic engineering: 21 terms compared: the origin of each name and how it differs from vibe coding.
• Command reference and configuration reference: the exact flags and keys behind these terms.
• The harness: how permissions, hooks, skills and plugins fit together.
• Start your role track: developer, tech lead, CTO or executive.