Requirements Engineering (RE) and the AI engineering stack of Prompt Engineering (PE), Context Engineering (CE), and Harness Engineering (HE) share a deep structural homology. Both are iterative design processes that convert vague intent into machine‑executable specifications, manage boundaries between environment and system, structure knowledge through hierarchical refinement, externalize mental models, and rely on feedback loops for validation. This report synthesizes findings across software engineering, cognitive science, and organizational psychology to delineate the common pattern and its limitations.
Five fundamental properties are common to RE and the PE–CE–HE continuum.
Vague stakeholder needs or ambiguous human intent are progressively converted into precise, verifiable artifacts. RE does this through elicitation → analysis → specification → verification; PE/CE/HE does it through prompting strategies → context enrichment → harness orchestration → evaluation.
Both disciplines explicitly separate the environment (given constraints, existing systems, human behavior) from the engineered artifact (software machine or AI agent’s responsibility). Jackson & Zave’s “problem frames” in RE, and the demarcation between user intent, context window content, and agent‑orchestration logic in Harness Engineering, illustrate identical boundary‑setting operations.
A three‑layer abstraction is present in both.
Goal‑oriented RE (KAOS, i*) and the Spec‑Context‑Harness model map onto each other precisely.
RE’s core challenge is externalizing distributed mental models of stakeholders into shared artifacts (vision videos, requirement documents). CE’s “Write Out” technique and HE’s Sprint Contracts externalize implicit knowledge so that multiple AI components or human‑AI teams share a common operational picture.
Both follow a plan‑do‑evaluate cycle. RE employs validation and verification loops; HE uses Planner → Generator → Evaluator pipelines. Feedback from evaluation triggers re‑planning or re‑elicitation, making the processes structurally identical.
PE techniques (Few‑shot, Chain‑of‑Thought) are systematically applied to RE tasks such as requirement extraction, specification, and traceability, confirming that the two domains can be fused into a single methodology without architectural mismatch.
Product managers and engineers report that crafting a good prompt maps one‑to‑one to writing a requirements document: purpose, user context, constraints, evaluation criteria, and output format are homologous elements.
The recent three‑layer model for AI‑era development re‑organizes traditional RE into Spec Engineering (designing specifications as AI agent context) and Harness Engineering (engineering the control plane that surrounds agents). This directly mirrors the PE→CE→HE layering.
Organizational psychology’s finding that specific, challenging goals improve human performance aligns with the PE principle that explicit, structured prompts elicit better LLM outputs. The universality of the “specificity–performance” link supports the homology.
Both requirement specifications and structured prompts act as boundary objects that bridge disparate communities of practice (business/developers, human/AI), requiring interpretive flexibility and a common structure.
RE manages intrinsic/extraneous/germane cognitive load for human engineers; CE manages context‑window load for LLMs. Both are forms of limited‑capacity resource allocation, tackled with compression, selection, and decomposition.
| Dimension | Requirements Engineering | Prompt/Context/Harness Engineering |
|---|---|---|
| Primary goal | Convert stakeholder needs into verifiable specs | Convert intent into reliable LLM output |
| Target agent | Human development team | Single LLM call / multi‑agent system |
| Layering | Goal → Constraint → Specification | Prompt → Context → Harness |
| Boundary | Environment (given) vs Machine (designed) | User intent vs context window vs orchestration |
| Pipeline | Elicitation → Analysis → Specification → Verification | Prompt design → context curation → agent orchestration → evaluation |
| Externalization | Shared mental models → requirement artifacts | Implicit knowledge → explicit context blocks / sprint contracts |
| Iteration | Spiral, agile feedback loops | Planner‑Evaluator feedback loops |
| Quality dimensions | Verification (internal) and validation (external) | Internal code quality and external user‑need alignment |
| Failure modes | Ambiguous reqs → wrong implementation | Ambiguous prompts → irrelevant output; context degradation; self‑evaluation bias |
The homology is structural, not complete identity. Key differences stem from the nature of the target agents.
These differences do not refute the homology; they refine it into a family of related design patterns parameterized by agent type.
Requirements Engineering and the Prompt/Context/Harness Engineering stack exhibit a strong structural homology: they are both instantiations of a universal intent‑translation design pattern. This pattern encompasses transformation, boundary definition, hierarchical refinement, externalization, and iterative feedback. Differences are attributable to agent‑specific characteristics and do not undermine the underlying common architecture. Recognizing this homology enables mutual enrichment of the two disciplines and suggests a consolidated theoretical framework for designing all human‑to‑system and human‑to‑AI communication.