Skip to content
Spark.
Spark reference

AI coding, explained in plain English.

Clear explanations for the terms that come up when you ask AI to help you build, change, and review software.69 terms for practical work

69 terms in the dictionary

Models and requests

16
  1. AI

    Artificial intelligence is a broad name for systems that perform tasks associated with reasoning, perception, language, or decisions. An AI coding assistant is one application of that broader field.

    Example

    A code assistant reads a failing test and proposes a patch for the function under test.

  2. Model

    A model is a trained mathematical system that maps its input to a distribution of likely outputs. In coding tools, it commonly produces text, structured data, or tool-call instructions.

    Example

    Given a function and its tests, a model can suggest an implementation that satisfies the examples.

  3. Parameters

    Parameters are the learned numerical values inside a model that shape its output. They are adjusted during training and normally fixed while the model answers a request.

    Example

    After training, the same saved parameter set can be used to explain a TypeScript error for many users.

  4. Training

    Training is the process of updating a model’s parameters using data and an optimization objective. It happens before ordinary use of the model.

    Example

    A training run adjusts parameters so code-like text makes the next token more predictable.

  5. Inference

    Inference is using an already trained model to produce an output for a new input. It does not usually change the model’s learned parameters.

    Example

    Sending a stack trace and asking for likely causes is an inference request.

  6. Effort

    Effort is a product-level control that may allocate more or less computation to forming a response. Its meaning and available settings depend on the provider or coding harness.

    Example

    For a small rename, a harness can request lower effort; for a migration plan, it can request more effort.

  7. Token

    A token is a chunk of text a language model processes, such as part of a word, a word, punctuation, or code symbols. Token boundaries are chosen by a tokenizer and do not always match words.

    Example

    The code `user.id` may be represented as several tokens before the model predicts the next one.

  8. Next-token prediction

    Next-token prediction is the objective of estimating which token should follow the text seen so far. Repeating that step produces longer passages, code, and tool-call payloads.

    Example

    After `return user.`, the model assigns probabilities to possible following tokens such as `id` or `name`.

  9. Non-determinism

    Non-determinism means identical-looking requests can produce different outputs, often because the system samples among plausible tokens or includes variable execution state. Controls can reduce variation but do not guarantee identical behavior across every product.

    Example

    Two runs may choose different but valid variable names when asked to write the same helper.

  10. Model provider

    A model provider operates models and exposes a way to request inference. A harness can select, configure, and send work to one or more providers.

    Example

    A coding application sends its prompt and tool definitions to the provider selected for the task.

  11. Harness

    A harness is the surrounding application that gives a model its instructions, context, tools, permissions, and user interface. It turns model output into an actual coding workflow.

    Example

    A terminal-based harness lets an agent read files, run tests, and show the resulting diff.

  12. Model provider request

    A model provider request is the payload a harness sends for inference, including messages and often tool definitions or generation settings. The exact fields are provider-specific.

    Example

    A harness packages the system prompt, current turn, and available tools into one request before asking for a response.

  13. Input tokens

    Input tokens are the tokens supplied to a model for a request, including instructions, conversation history, source excerpts, and tool definitions. They consume part of the usable context window.

    Example

    Pasting a 400-line error log increases the input tokens for the next request.

  14. Output tokens

    Output tokens are tokens the model generates in response to a request. They can contain prose, code, structured data, or a request to invoke a tool.

    Example

    A generated patch explanation and its JSON tool-call arguments are output tokens.

  15. Prefix cache

    A prefix cache stores reusable computation for an identical or compatible beginning of a request. Whether it is available, matched, or billed separately is product-dependent.

    Example

    Repeated requests that share a long repository instruction block may reuse cached prefix work.

  16. Cache tokens

    Cache tokens are input tokens associated with a reusable prefix cache. Depending on the provider, usage may distinguish cache reads, cache writes, or both, with different accounting rules.

    Example

    A usage record can separately show cached reads and a cache write for an unchanged project brief.

Context and conversations

8
  1. Stateless

    A stateless interaction keeps no memory between requests unless the caller sends prior information again. The model only has access to the current request payload.

    Example

    A script that sends each error message independently is stateless unless it includes earlier messages.

  2. Context

    Context is the information available to the model while it generates a response, including instructions, messages, files, and tool results. It determines what the model can directly reason from in that turn.

    Example

    Including the failing test and the implementation gives the model context for a bug fix.

  3. Context window

    A context window is the maximum amount of tokenized input and output a request can hold together. Its practical limit depends on the model and the request configuration.

    Example

    When a long conversation approaches the window limit, a harness may summarize older turns before continuing.

  4. Stateful

    A stateful system retains information between interactions and can use it later without the caller resending every detail. State may live in the harness, a database, or an external service rather than inside the model.

    Example

    An agent session that remembers which files it already changed is stateful.

  5. Agent

    An agent is a system that uses a model to pursue a goal through one or more steps, often choosing tools and reacting to their results. The surrounding harness defines its capabilities and limits.

    Example

    An agent searches for a symbol, edits its call sites, runs tests, and reports the outcome.

  6. System prompt

    A system prompt is high-priority instruction text supplied by the application to guide model behavior. Its precise precedence and enforcement are product-dependent.

    Example

    A system prompt can instruct an agent to avoid editing files outside an assigned directory.

  7. Session

    A session is a bounded period of interaction that groups related turns and may retain working state. Its persistence and reset behavior are determined by the harness.

    Example

    A coding session can keep the selected repository and prior test results while a bug is investigated.

  8. Turn

    A turn is one exchange in an interaction, usually a user request followed by an assistant response and any associated tool work. A turn can contain multiple model calls in an agentic harness.

    Example

    “Fix this test” and the agent’s patch plus test output make one turn.

Tools and execution

10
  1. Environment

    An environment is the runtime setting where code or tools execute, including its operating system, dependencies, credentials, network rules, and working directory. Environment differences can change a command’s result.

    Example

    A test passes in a container with the required database service but fails on a laptop without it.

  2. Filesystem

    A filesystem organizes files and directories that tools can read or write. An agent’s view is often limited to specific workspace paths.

    Example

    A file-editing tool reads `src/lib/config.ts` before applying a focused patch.

  3. Tool

    A tool is an operation the harness makes available to an agent, such as reading a file, running a command, querying an API, or editing code. Each tool has an input contract and a result.

    Example

    A search tool finds every import of a function before it is renamed.

  4. Tool call

    A tool call is one requested invocation of a tool with particular arguments. The harness validates and executes it according to the tool’s permissions and contract.

    Example

    The agent calls a test tool with `bun test tests/auth.test.ts`.

  5. Tool result

    A tool result is the information returned after a tool call, such as file contents, command output, an error, or a structured response. It becomes new context for the agent’s next decision.

    Example

    A test result reports one failing assertion, which the agent uses to locate the regression.

  6. MCP

    Model Context Protocol is a protocol for exposing tools and resources to AI applications through a common interface. A specific client and server determine which capabilities are actually available.

    Example

    An MCP server can expose a repository search operation for a coding harness to call.

  7. Permission request

    A permission request asks a person or policy system to allow an operation beyond the agent’s current authority. It should identify the action and its scope clearly enough to assess.

    Example

    Before downloading a dependency, the harness asks to allow network access for the package command.

  8. Permission mode

    Permission mode is the policy setting that controls which operations can run automatically and which require approval. Names and exact behavior vary by harness.

    Example

    A restrictive mode may allow reading project files but require approval before writing outside the workspace.

  9. Agent mode

    Agent mode is a product-specific operating mode in which the assistant can plan and carry out multi-step work, often with tools. Its autonomy and safeguards depend on the harness.

    Example

    In agent mode, the assistant can inspect a failing test, patch the code, then run the test again.

  10. Sandbox

    A sandbox is an isolated execution boundary that restricts access to files, network, processes, or other resources. It limits the possible impact of code and tool calls.

    Example

    A sandboxed command can write inside the project directory while being blocked from changing system files.

Reliability and knowledge

9
  1. Sycophancy

    Sycophancy is a tendency to agree with or reinforce a user’s stated belief even when the evidence does not support it. It can make confident but incorrect coding advice feel persuasive.

    Example

    If a user says a migration is safe, a sycophantic response may agree instead of checking for data-loss risks.

  2. Hallucination

    A hallucination is generated content presented as fact even though it is unsupported, invented, or wrong. It can include nonexistent APIs, files, command output, or citations.

    Example

    An assistant claims a package exports `parseConfig` without checking the installed package.

  3. Parametric knowledge

    Parametric knowledge is information encoded in a model’s learned parameters from training. It can be useful but may be incomplete, outdated, or difficult to trace to a source.

    Example

    A model may recall the general shape of a SQL join but still need the local schema to write a correct query.

  4. Knowledge cutoff

    A knowledge cutoff is the point after which a model’s training data may not include later events or changes. It does not limit information supplied in current context or retrieved by tools.

    Example

    For a newly released library API, the agent reads the installed documentation instead of relying on training knowledge.

  5. Contextual knowledge

    Contextual knowledge is information made available in the current request through messages, files, tool results, or retrieved sources. It can be current and task-specific if the source is reliable.

    Example

    The current repository’s lockfile gives contextual knowledge about which package version is installed.

  6. Attention relationship

    An attention relationship describes how a model can weigh one part of its context against another while generating a token. It is a technical mechanism, not a guarantee that the model will follow the most relevant instruction.

    Example

    While editing a function, the model can relate its parameter type to a constraint written earlier in the prompt.

  7. Attention budget

    Attention budget is an informal metaphor for the limited practical capacity to use all supplied context well. It is not a standard fixed model setting, and performance depends on the task and model.

    Example

    A concise bug report plus relevant files can be easier to use than hundreds of unrelated log lines.

  8. Attention degradation

    Attention degradation describes the observed tendency for a model to use some relevant context less reliably as prompts become long, noisy, or contradictory. The severity varies by model and task.

    Example

    A key acceptance criterion buried among stale notes may be missed when the agent writes a patch.

  9. Smart zone

    Smart zone is an informal term for the part of a task where an AI system has enough clear, relevant context and reliable checks to work effectively. It is a planning heuristic, not a measurable model boundary.

    Example

    Generating a unit-test table from a documented API is often in the smart zone when the API and expected outputs are provided.

Handoffs and source material

9
  1. Clearing

    Clearing starts with fresh active conversation context instead of carrying a prior conversation forward. Saved files and external state generally persist, subject to the harness, so key sources can be reloaded deliberately.

    Example

    An engineer saves a handoff, starts a fresh session, then reloads the issue, failing test, and current diff.

  2. Handoff

    A handoff transfers responsibility and the information needed to continue work from one person or agent to another. A good handoff identifies current state, evidence, ownership, and next decisions.

    Example

    A developer hands off a migration with the tested command, rollback notes, and the remaining production approval.

  3. Primary source

    A primary source is direct evidence closest to the subject being described, such as source code, a test result, a signed-off requirement, or an authoritative system record. It is usually stronger than a summary of that evidence.

    Example

    The failing CI log is a primary source for the failure, while a chat summary of it is secondary.

  4. Secondary source

    A secondary source interprets, summarizes, or reports information from primary sources. It can be useful for orientation but should be checked when exact behavior or ownership matters.

    Example

    A project wiki note says a service uses Redis, then the agent verifies it in the deployment configuration.

  5. Handoff artifact

    A handoff artifact is a durable item that records what a new owner needs to continue, such as a note, checklist, patch, runbook, or decision log. It should link to the primary evidence it relies on.

    Example

    A release handoff artifact lists the commit, passing checks, known risk, and the dashboard to watch.

  6. Spec

    A spec states the intended behavior, constraints, and acceptance conditions for work. It gives implementation and review a shared target.

    Example

    A spec requires an endpoint to reject expired tokens and return a documented error shape.

  7. Ticket

    A ticket is a tracked work item that records a problem, request, or deliverable along with its status and ownership. Its quality depends on the evidence and acceptance criteria it contains.

    Example

    A ticket links the bug report, expected behavior, assigned owner, and regression test.

  8. Compaction

    Compaction condenses prior conversation or state into a shorter representation so work can continue with less context. It can preserve important facts but may omit detail, so critical sources should remain reachable.

    Example

    After a long investigation, the harness keeps a concise list of confirmed causes and test commands for the next turn.

  9. Autocompact

    Autocompact is a product-specific feature that performs compaction automatically, often when a conversation grows large. Its timing and summary quality depend on the harness.

    Example

    Near a context limit, a harness automatically summarizes earlier turns before sending the next model request.

Steering an agent

6
  1. Memory system

    A memory system stores selected information across sessions so an agent can retrieve relevant history later. It should distinguish durable decisions from temporary working notes.

    Example

    A project memory records the approved deployment workflow so later agents do not invent a different one.

  2. AGENTS.md

    AGENTS.md is a repository convention for instructions that guide coding agents in a project or directory. Its exact discovery and precedence rules depend on the harness.

    Example

    An AGENTS.md file tells an agent to run Bun checks and avoid deploying without approval.

  3. Progressive disclosure

    Progressive disclosure provides information in layers, beginning with the minimum needed and retrieving more detail when the task requires it. It helps keep context focused while preserving access to source material.

    Example

    An agent reads a short project guide first, then opens the referenced API document only when editing that integration.

  4. Context pointer

    A context pointer is a concise reference that directs an agent to relevant source material instead of embedding all of it in every prompt. It can be a path, URL, identifier, or exact search term.

    Example

    “See `docs/auth.md` under Token rotation” points the agent to the authoritative procedure.

  5. Skill

    A skill is a reusable package of instructions, tools, and sometimes scripts for a recurring type of task. It narrows a workflow around known conventions and checks.

    Example

    A spreadsheet skill explains how to preserve formulas while updating a workbook.

  6. Subagent

    A subagent is an agent assigned a bounded part of a larger task by another agent. Clear file ownership and expected evidence make parallel work safer to integrate.

    Example

    A parent agent assigns one subagent to map affected files and another to review a completed patch.

Working practice

11
  1. Human-in-the-loop

    Human-in-the-loop means a person remains involved in decisions, approvals, review, or correction while an AI system assists. The human’s role should match the consequence of the action.

    Example

    An agent drafts a database migration, and an engineer reviews it before it is applied to production.

  2. AFK

    AFK means away from keyboard: the person is not actively watching or responding. In agent workflows, it usually calls for bounded authority, clear stop conditions, and durable status updates.

    Example

    Before going AFK, a developer asks the agent to run read-only analysis and leave a handoff artifact.

  3. Automated check

    An automated check is a repeatable machine-run validation, such as a test, type check, linter, build, or schema validation. Passing checks provide evidence for the behavior they actually cover.

    Example

    A type check catches a renamed property still referenced by an old component.

  4. Automated review

    Automated review evaluates code or changes against rules, patterns, or models without a person examining each result. It can catch recurring issues but needs human oversight for false positives and gaps.

    Example

    A pull-request bot flags a changed API response that no longer matches the declared schema.

  5. Human review

    Human review is a person assessing a change for correctness, intent, risk, and fit with the real situation. It adds judgment where automated checks cannot establish the full outcome.

    Example

    A reviewer confirms that a passing migration preserves the customer records the product team cares about.

  6. Vibe coding

    Vibe coding is an informal term for relying on AI-generated behavior through prompts and iteration without closely reviewing or understanding the generated implementation. It can accelerate exploration, but verification is still needed before real use.

    Example

    A developer iterates on an app through prompts and screenshots without inspecting its generated code, then verifies it before release.

  7. Design concept

    A design concept is a coherent proposal for how a product or interface should solve a user problem. It expresses an intended experience before implementation details are settled.

    Example

    A design concept proposes a single review queue where managers approve AI-drafted account updates.

  8. Grilling

    Grilling is a deliberate, rigorous challenge of a plan’s assumptions, evidence, tradeoffs, and failure cases. It is used to expose weak reasoning before a costly commitment.

    Example

    Before approving an agent workflow, the team asks what happens if a tool returns stale customer data.

  9. Prototyping

    Prototyping builds a small, deliberately limited version of an idea to learn whether it works. A prototype should answer a stated question rather than quietly becoming production software.

    Example

    A team builds a local click-through flow to test whether users understand the approval step.

  10. DX

    Developer experience is how easy, clear, and reliable it is for developers to build, test, and maintain software. Good DX reduces avoidable friction in the development workflow.

    Example

    A one-command local setup and actionable test failures improve DX for new contributors.

  11. AX

    Agent experience is how clear and effective a development environment is for AI agents working within it. The term is informal and can include instructions, tools, feedback, and safe boundaries.

    Example

    Focused repository instructions, reliable tests, and explicit file ownership improve AX for a coding agent.