# Glossary Key terms and definitions for harness engineering. Terms are listed alphabetically. --- ### Agent Configuration File The top-level file that provides initial context to an AI coding agent. For GitHub Copilot, the primary surfaces are `.github/copilot-instructions.md` (repo-wide, loaded on every Copilot Chat request) and `AGENTS.md` (universal, read by Copilot Coding Agent). Should be approximately 100 lines and function as a table of contents, not a comprehensive manual. See: [Context Engineering](context-engineering.md#agentsmd-as-table-of-contents) --- ### Agent Legibility The degree to which a codebase is understandable by AI agents. High legibility means explicit naming, conventional structure, clear type annotations, and thorough doc comments. Low legibility means abbreviated names, non-standard layouts, implicit types, and tribal knowledge. See: [Principles: Optimize for Agent Legibility](principles.md#9-optimize-for-agent-legibility) --- ### Agent Session A single interaction between a human and an AI coding agent, from task assignment through code output. Sessions are typically isolated -- each session starts with a fresh context window and no memory of previous sessions. This isolation is a feature (no contamination) and a constraint (no accumulated knowledge). --- ### Agentic Coding A development paradigm where AI agents read files, execute commands, run tests, interpret results, and iterate on solutions -- as opposed to simple code completion or chat-based assistance. The agent operates with significant autonomy within defined boundaries. --- ### Architectural Constraint An automated, enforceable rule that prevents structurally incorrect code from being merged. Constraints are implemented as custom linter rules, structural tests, pre-commit hooks, or CI checks. Unlike instructions (which are suggestions), constraints are mechanically enforced. See: [Architectural Constraints](architectural-constraints.md) --- ### Boring Technology Technology that is well-established, widely-adopted, extensively documented, and unlikely to introduce breaking changes. Boring technology produces higher-quality AI-generated code because models have seen more examples of it during training. The term is borrowed from Dan McKinley's "Choose Boring Technology." See: [Architectural Constraints: Boring Technology](architectural-constraints.md#boring-technology-selection-criteria) --- ### Context Engineering The practice of curating, structuring, and delivering the right information to AI agents at the right time. One of the three pillars of harness engineering. Context engineering is to harness engineering what memory management is to operating systems. See: [Context Engineering](context-engineering.md) --- ### Context Overload An anti-pattern where too much information is provided to the agent, diluting its attention and displacing relevant context from the context window. Often caused by placing all instructions in a single large config file. See: [Anti-Patterns: The 1,000-Page Instruction Manual](anti-patterns.md#1-the-1000-page-instruction-manual) --- ### Context Window The total amount of text (measured in tokens) that a language model can process in a single interaction. Functions as the "working memory" of the AI agent. All input (system prompts, agent config, source code, conversation history) must fit within this window. --- ### Deterministic Edges The principle that AI-generated code should be bounded by deterministic verification at its inputs (structured context) and outputs (automated tests, linters, structural checks). The interior is probabilistic; the edges are not. See: [What Is Harness Engineering: Probabilistic Inside, Deterministic at the Edges](what-is-harness-copilot.md#probabilistic-inside-deterministic-at-the-edges) --- ### Doc-Gardening Agent An automated agent that verifies documentation accuracy by cross-referencing docs with actual code, checking link validity, identifying stale references, and flagging contradictions. A key component of entropy management. See: [Entropy Management: Doc-Gardening Agents](entropy-management.md#doc-gardening-agents) --- ### Dynamic Context Context that is generated at runtime rather than pre-written. Includes test output, linter errors, runtime logs, browser screenshots, and observability data. Dynamic context provides information that static docs cannot. See: [Context Engineering: Dynamic Context](context-engineering.md#dynamic-context) --- ### Entropy In the context of software engineering, the natural tendency of a codebase to become more disordered over time. Manifests as dead code, stale documentation, inconsistent patterns, unused dependencies, and accumulated technical debt. AI-generated code accelerates entropy due to higher velocity and session isolation. --- ### Entropy Management The practice of actively fighting codebase decay through garbage collection agents, doc-gardening, quality grade tracking, and scheduled maintenance. One of the three pillars of harness engineering. See: [Entropy Management](entropy-management.md) --- ### Execution Plan A concrete, ordered list of steps that an agent will take to implement a specification. More detailed than a spec (which says *what*) but less detailed than code (which says *how exactly*). An intermediate artifact in specification-driven development. See: [SDD: Execution Plans](specification-driven-development.md#execution-plans-as-first-class-artifacts) --- ### Execution Session An agent session focused on implementing a specification. No design decisions are made during execution. The agent reads the spec, follows the plan, produces code, and runs verification. Contrasted with planning sessions. See: [SDD: Planning vs. Execution Sessions](specification-driven-development.md#planning-vs-execution-sessions) --- ### Feedback Loop The iterative cycle by which harness engineering improves: agent produces output, human reviews, human diagnoses systematic issues, human improves the harness, future agent sessions benefit. The speed and consistency of this loop determine the rate of harness improvement. See: [Principles: Agent Failure Is Harness Failure](principles.md#10-agent-failure-is-harness-failure) --- ### Garbage Collection (Codebase) The periodic process of removing dead code, unused imports, orphaned tests, stale documentation, and other forms of codebase entropy. Named by analogy with memory garbage collection in runtime systems. See: [Entropy Management: The Garbage Collection Pattern](entropy-management.md#the-garbage-collection-pattern) --- ### Harness The complete system of context, constraints, and verification loops that surrounds an AI model and enables it to produce reliable code. Includes agent configuration files, documentation, linter rules, structural tests, pre-commit hooks, CI checks, and entropy management processes. Analogous to an operating system for AI agents. See: [What Is Harness Engineering?](what-is-harness-copilot.md) --- ### Harness Engineering The discipline of designing, building, and maintaining harnesses for AI coding agents. Encompasses context engineering, architectural constraints, and entropy management. The successor to prompt engineering for agentic workflows. See: [What Is Harness Engineering?](what-is-harness-copilot.md) --- ### Instruction Rot The gradual degradation of agent instructions as the codebase evolves but the instructions do not. Instructions that were accurate when written become misleading or incorrect over time. A specific form of entropy that affects the context engineering pillar. See: [Context Engineering: Anti-Patterns](context-engineering.md#anti-patterns-in-context-engineering) --- ### Invariant A property that must always be true about a codebase, regardless of implementation. Examples: "Services never import from the API layer," "Every public function has a doc comment," "No function exceeds 50 lines." Invariants are enforced by architectural constraints. See: [Principles: Enforce Invariants, Not Implementations](principles.md#3-enforce-invariants-not-implementations) --- ### Layering Model A dependency rule that defines which modules may depend on which other modules, typically arranged in numbered layers where dependencies flow downward only. Enforced by structural tests and custom linter rules. See: [Architectural Constraints: The Layering Model](architectural-constraints.md#the-layering-model) --- ### Mega-Session An anti-pattern where a single agent session is tasked with a large, multi-component task. Mega-sessions exhaust the context window, compound errors, produce unreviewable diffs, and lack recovery checkpoints. See: [Anti-Patterns: "Draw the Owl" Mega-Sessions](anti-patterns.md#7-draw-the-owl-mega-sessions) --- ### MCP (Model Context Protocol) A protocol for providing AI models with structured access to external tools and data sources. MCP servers expose capabilities (file access, database queries, API calls) that agents can invoke during sessions. A mechanism for providing dynamic context. --- ### Planning Session An agent session focused on producing a specification or design, not code. The human provides intent and constraints; the agent asks questions, identifies edge cases, and proposes solutions. Contrasted with execution sessions. See: [SDD: Planning vs. Execution Sessions](specification-driven-development.md#planning-vs-execution-sessions) --- ### Progressive Disclosure The practice of providing information in layers -- general first, specific on demand. The top-level agent config provides a map; linked documents provide detail. Keeps the context window focused on relevant information. See: [Context Engineering: Progressive Disclosure](context-engineering.md#progressive-disclosure) --- ### Providers Pattern A design pattern where cross-cutting concerns (logging, authentication, error handling, metrics) are implemented once in a `providers/` directory and used consistently across the codebase. Prevents agents from implementing cross-cutting concerns ad-hoc. See: [Architectural Constraints: Cross-Cutting Concerns](architectural-constraints.md#cross-cutting-concerns-via-the-providers-pattern) --- ### Quality Grade A letter grade (A through F) assigned to a codebase module based on measurable criteria: test coverage, type coverage, documentation completeness, TODO count, and structural test compliance. Used to track codebase health over time and prioritize improvement efforts. See: [Entropy Management: Quality Grades](entropy-management.md#quality-grades-tracking) --- ### Ralph Wiggum Loop A self-review pattern where the agent reviews its own output against project standards before submitting it. Named humorously after the Simpsons character. Despite the name, it is effective because models are often better at evaluating code than generating it. See: [Entropy Management: The Ralph Wiggum Loop](entropy-management.md#the-ralph-wiggum-loop-self-review-pattern) --- ### Relocating Rigor The concept, articulated by Chad Fowler, that rigor does not disappear when AI writes code -- it relocates from the act of authorship to the act of evaluation. Engineers shift from writing correct code to building systems that make incorrect code impossible to merge. See: [What Is Harness Engineering: Relocating Rigor](what-is-harness-copilot.md#relocating-rigor) --- ### Remediation Instruction The "how to fix it" message attached to a linter rule or structural test failure. Without remediation instructions, agents see errors but do not know how to resolve them. With remediation instructions, agents can self-correct without human intervention. See: [Architectural Constraints: Custom Linters](architectural-constraints.md#custom-linters-with-remediation-instructions) --- ### Session Handoff The practice of passing context from one agent session to another when a task requires more continuity than a single session provides. Techniques include summary documents, checkpoint files, and structured state artifacts. --- ### Specification-Driven Development (SDD) A workflow where the specification is the primary engineering artifact and code is its expression. Specifications are precise, structured, and verifiable documents that agents can implement directly. See: [Specification-Driven Development](specification-driven-development.md) --- ### Structural Test A test that verifies properties of the codebase structure rather than runtime behavior. Examples: "every service has a test file," "no circular dependencies exist," "API handlers are under 30 lines." Structural tests are fast, deterministic, and catch violations that unit tests miss. See: [Architectural Constraints: Structural Tests](architectural-constraints.md#structural-tests-archunit-style) --- ### Three Pillars The three foundational practices of harness engineering: (1) Context Engineering, (2) Architectural Constraints, and (3) Entropy Management. Articulated by Martin Fowler and Birgitta Böckeler. A complete harness requires all three. See: [What Is Harness Engineering: The Three Pillars](what-is-harness-copilot.md#the-three-pillars) --- ### Verification Loop The automated process by which agent output is validated against deterministic checks (type checking, linting, testing, structural tests). The verification loop is the mechanism that makes "probabilistic inside, deterministic at the edges" operational. See: [Getting Started: Set Up Basic Verification](getting-started.md#step-3-set-up-basic-verification) --- ## Further Reading - [What Is Harness Engineering?](what-is-harness-copilot.md) -- Start here for core concepts. - [Principles](principles.md) -- The mental models behind these terms. - [Getting Started](getting-started.md) -- Apply these concepts in practice.