The words this section leans on, defined the way its pages use them. Each entry opens with a definition that stands on its own, then says what the term means for the work and links the page that covers it. Where an entry says where a term comes from, it links the source.
Acceptance criterion
A single condition a piece of work must meet to count as done, written so that a test or a reviewer can answer yes or no. A task's acceptance criteria are the check that closes it.
This section treats them as the part of a brief an agent must not be left to invent. A behaviour handed over without its acceptance criterion gets one made up, and the change that comes back is judged against the agent's own description of it instead. Autonomous coding agents shows a brief that carries them, and Writing requirements an AI coding agent can build from covers writing them.
Agent
A program that uses a model to work towards a goal in steps: it reads, decides what to do, acts through tools such as editing files or running commands, looks at the result and goes again. In this section an agent usually means a coding agent working in a repository.
How much you hand an agent is much of what separates the rungs. On Agent in the editor you watch each change as it is made. On Delegated execution you hand over a whole task and review what comes back. On AI-native engineering the agent is part of the product rather than a way of building it.
Brief
The written instructions an agent starts a task from: what to build, what it must satisfy, what to leave alone and the check that says it is done. For an agent working unattended, the brief is the whole specification.
Whatever a brief leaves out, the agent decides, plausibly and without saying so, which is why a brief that leaves little to invent is usually a page rather than a sentence. Autonomous coding agents has a short example, and Multi-agent software engineering has one that holds an agent to its seam. Writing a brief for an unattended agent builds one in full.
Category
One of the eighteen kinds of AI-assisted development this section maps, such as AI app builders or terminal agents. Each category has a page saying what it is for, who it suits and what it costs you later.
Twelve categories sit on a layer of the pyramid, and the other six are cross-cutting practices. Categories are named for the kind of work rather than for any product, so a renamed tool never moves a page. The hub lists all eighteen.
Characterisation test
A test that records what existing code does today, quirks included, rather than what it ought to do. It pins the current behaviour, so a later change that alters it fails a test instead of passing unnoticed.
These pages ask for characterisation tests before an agent touches code you inherited or a prototype you are taking over, because a refactor without them can quietly change behaviour while looking like a tidy-up. AI code review, refactoring and maintenance sets out the order of work, Prompt to app applies it to stepping off that rung, and Taking over a generated prototype shows two written against a checkout.
Cloud development environment
A development setup that runs on a remote machine, with the editor, terminal, dependencies and build reached from a browser or a thin client. A file in the repository describes it, so it can be rebuilt from scratch in minutes.
It changes where the work happens, not how much of the engineering you take on, so this section files it as a practice rather than a rung. It matters most when your own machine, power or connection is the constraint, and when delegated agents need somewhere to run that is not your laptop. Cloud development environments covers what it costs you.
Connector
A piece of software that gives a model or an agent access to an outside tool or data source, such as an issue tracker, a database, a browser or a set of documentation. Many follow a shared protocol, so one connector can serve several editors and agents.
A connector runs with whatever access you give it. The protocol defines how the two sides talk, not what the connector is allowed to do, which is why these pages say a protocol is not a sandbox. What a connector returns can also carry instructions, the risk described under prompt injection. AI IDEs covers scoping each one to the least it needs.
Context
Everything a model has in front of it when it answers: the instructions, the conversation so far, the files it was shown and what its tools returned. The most it can take in at once is called its context window.
Context does not carry from one session to the next unless it is written down, and in a long session the instructions given at the start are the first to slip. These pages call the work of keeping it right the context tax: a rules file to write and maintain, and the cost of loading rules a task does not need. Context engineering for AI coding agents covers what belongs in it.
Contract
A written agreement about how two parts of a system talk to each other, such as the requests and responses between a client and a server. Both sides build against it, so each side can be checked on its own.
When several agents build parts of one change, the contract is what they share, not the conversation. It has to exist before either side starts, and changing it during a round of work means checking everyone's work against the new version. Multi-agent software engineering covers why it becomes load-bearing.
Cross-cutting practice
One of six categories that apply at every rung of the pyramid rather than belonging to one: testing and debugging, code review, DevOps, cloud development environments, voice, and reverse engineering. Together they form a seventh group, deliberately not drawn as a rung.
Code review is the clearest case. It matters more near the top, where more of the code was written by something other than you, but it never stops applying, and a rung of its own would suggest you could climb past it. Cross-cutting practices covers all six.
Delegation
Handing a whole task to an agent and reviewing the result, rather than watching each step as it happens. How much you delegate, and whether you are present while the work is done, is a large part of what separates one rung from the next.
Delegation pays when a task can be described completely in advance and checked mechanically afterwards. It costs you when it cannot, because every gap in the brief becomes a decision the agent makes for you. Delegated execution is the rung built on it.
EARS
Easy Approach to Requirements Syntax: a small set of sentence patterns for writing requirements, each built on a keyword such as WHEN, WHILE, WHERE, or IF and THEN, followed by what the system shall do. Each pattern makes the writer name the trigger, state or condition the requirement depends on.
The notation was first published in 2009 by Alistair Mavin and colleagues. This section uses it because a requirement in that form is one an agent can build from and a test can check. Voice and conversational coding shows a dictated rule rewritten in it, and Writing requirements an AI coding agent can build from goes through each pattern.
Embedding
A list of numbers a model produces to represent a piece of text, arranged so that texts with similar meanings sit close together. Comparing embeddings is how retrieval finds the passages closest to a question, even when they share no words with it.
Embeddings are part of how a product grounds its answers in its own documents, so they inherit the documents' problems. A stale page is found as readily as a current one, and nothing in the numbers says who is allowed to read the text behind them. AI-native software engineering covers what retrieval costs.
Evaluation
Checking a model-backed feature against a saved set of real cases, each with a description of what a good answer looks like, and scoring the results. It takes the place of exact-match tests, which cannot hold when the same input can produce different outputs.
This section treats evaluation as ongoing work rather than a launch step. The cases run on every change to a prompt, a model, a routing rule or the retrieved content, and they are kept current as the product changes. Without them, every release is judged on impressions. AI-native engineering sets out what that costs.
Handoff
The point where work passes from one agent, tool or person to the next, such as a plan moving from the tool that wrote it to the agent that builds it. Whatever was decided and not written down stays behind.
On the Orchestration rung, handoffs are where intent leaks. The remedy these pages give is to hand over files rather than conversations: the requirements, the design and the tasks, kept in the repository where every tool in the chain can read them. AI-orchestrated development covers it.
Idempotency key
A unique value sent with a request so that, if the same request arrives twice, the system can recognise the repeat and act only once. It is what stops a retried payment or refund from being recorded twice.
It appears in the briefs and tests on these pages because a request sent twice is one of the cases an agent will not think of unless someone names it. AI testing and debugging turns it into a property: for any refund request sent twice with the same key, exactly one refund is recorded.
Layer
One rung of the pyramid: a way of building software with AI, placed by how much of the engineering you take on. There are six, from prompt to site at the base to AI-native engineering at the top, and these pages use layer and rung for the same thing.
Higher is not better. A higher layer means more of the work is yours, and more of what ships is yours to maintain. Each layer page says how to tell you are on it and what the step up would ask of you. The hub lists all six.
Model routing
Sending each request to one of several models by a rule, for example sending simpler requests to a cheaper model. It saves money, and it changes the answers.
These pages treat a routing rule as a quality decision as well as a cost one, so it gets the same saved cases and scores as any other change. Otherwise the saving is paid for in quality nobody measured. AI-native software engineering covers it alongside fallbacks.
Orchestration
Coordinating several agents or tools across one piece of work, so the parts come back together as one coherent change. Whoever orchestrates decides how the work splits, what does each part and how the results are checked.
It is the fifth rung, and it takes two forms. In multi-agent software engineering, agents take separate roles on the same work. In AI-orchestrated development, one piece of work passes through a different tool at each stage. Both are the problem of keeping one intention intact across hands that share no memory, and Orchestration covers when that is worth taking on.
Prompt injection
An attack in which text a model reads carries instructions the model then follows, overriding what its builder or its user intended. The text can be typed in directly, or hidden in a web page, a file, an email or a tool's response.
OWASP puts it first in its top ten risks for applications built on large language models, and separates direct injection, in what a user types, from indirect injection, in content the model is given to read. The defence these pages give is structural: check permissions in ordinary code outside the model, and be most careful with anything that can both read untrusted content and take consequential actions. AI-native engineering and AI IDEs cover it.
Property-based test
A test that states a rule which must hold for every input, then checks it against many generated inputs instead of a few written by hand. When it fails, it reports the smallest failing input it can find.
Example tests check the cases someone thought of. A property is a requirement restated so it can be checked against the inputs nobody thought of, which is where the edge cases that pass review and break in production tend to be. AI testing and debugging has three written for a refund flow.
Pyramid
This section's map of the ways to build software with AI: six layers ordered by how much of the engineering you take on, from website builders at the base to AI-native engineering at the top. It is for finding where you work and seeing what the next step would ask of you.
Six categories do not fit that ordering, and they sit beside the pyramid as cross-cutting practices rather than on it. The hub draws the pyramid, with each layer linked to its page.
Retrieval-augmented generation
Answering a question by first retrieving relevant passages from a store of documents, then giving them to the model with the question, so the answer rests on those documents rather than only on what the model learned in training. Often shortened to RAG.
The name comes from a 2020 research paper by Patrick Lewis and colleagues. In a product, retrieval answers only from what it finds, so a stale document gives a confident stale answer, and retrieval that ignores permissions can put one user's document into another user's answer. AI-native software engineering covers both.
Rules file
A plain file kept in the repository that tells an agent the project's conventions, commands and boundaries, and is read at the start of every session. It is how what the agent needs to know carries from one session to the next.
A rules file then needs maintaining like code. A rule loaded into every request costs context on every request, and a file describing the conventions you wish you had is followed as faithfully as one describing those you have. Tools give these files different names, among them rules, instructions and steering files, and keeping them as plain files any tool can read is what lets you switch. AI IDEs covers scoping them, Terminal and CLI agents what a setup around one looks like, and Writing and scoping a rules file how to write one.
Seam
A boundary along which a piece of work splits cleanly, so each part can be built and checked on its own, such as the line between client and server where a contract sits. A real seam already exists in the system; an invented one is drawn only to allow parallel work.
Where the seam is real, parts built separately meet at a point defined in advance. Where it is invented, they meet somewhere nobody planned, usually in the review queue. Orchestration and Multi-agent software engineering cover how to tell the difference.
Specification
A written description of what a piece of software must do and how it is to be built, usually requirements, a design and a list of tasks, kept where every person and tool working on it can read it. In this section it is the document an agent builds from and a reviewer checks against.
When the plan lives in a specification rather than in a conversation, any tool or person can pick up the work, and a change can be judged against what it was meant to do. Working this way is often called spec-driven development, the subject of Spec-driven development. AI-orchestrated development shows why it matters most when work passes between tools.
Stand-in
A temporary substitute an agent builds when a task needs something that does not exist yet, such as a fake service, a hardcoded response or a placeholder table, so that it can carry on. Agents often build one without saying so.
A stand-in is usually found later, when the real thing arrives and disagrees with it. The cheapest defence is one line in the brief: if something the task needs does not exist, stop and say so. Delegated execution and Autonomous coding agents cover it.
Tool calling
A model's ability to ask the program around it to run a named function, such as a search, a database query or a change to a record, and to use the result in its answer. The program runs the call; the model only asks for it.
That split is where permissions belong. A model with tools acts on what it reads, and what it reads can be written by anyone, so the program checks who is asking before any tool runs, whatever the model requested. AI-native software engineering covers it, and connectors are how agents in the editor get their tools.
Vibe coding
Building software by describing what you want, accepting what the model returns and moving on, without reading or fully understanding the code. It is quick for prototypes and throwaway scripts.
It is how most work on the Prompt to app rung starts, and AI app builders are the category that made it famous. The cost arrives when the prototype becomes the product and nobody can explain the code. Vibe coding builds fast, but can you explain it later? makes the case.