Harness Engineering Explained: From Vibe to Spec Coding and How to Overcome Context Rot

01 | Origin: From Vibe Coding to Spec Coding

Vibe Coding (2023‑2024) emerged after ChatGPT popularized AI programming, where developers describe requirements intuitively and AI generates code based on feeling. While it offers low startup cost and rapid prototyping, five critical issues appear when used for real engineering:

Uncontrollable: identical requests yield different code each time.

Inconsistent: similar specifications diverge across sessions.

Irreproducible: bugs cannot be traced back to AI’s reasoning.

Uncollaborative: multiple developers interacting with AI produce divergent solutions.

Unevolvable: over time even the AI loses track of its own code.

The deeper problem is that AI‑generated code looks like engineering output, but the creation process is not an engineering process.

Industry faced a choice at the end of 2024: should AI replace software engineers or augment them? The augmentation path won because compliance audits and collaborative production demand reliability beyond luck.

From 2025 onward, the ecosystem built engineering infrastructure around AI, including GitHub’s Spec‑Kit, fission‑ai’s OpenSpec, Anthropic’s Claude Code with Sub‑Agent support, and emerging tools such as GSD, ECC, and Trellis. This movement is known by three names: Spec‑Driven Development (SDD), Spec Coding, and the broad term Harness Engineering.

02 | What Is Harness Engineering?

“Harness” originally means a device that restrains and guides a horse; similarly, Harness Engineering constrains and guides AI agents to produce reliable software artifacts.

Harness Engineering is an AI‑programming era methodology that uses three strategies—structured documentation, staged processes, and atomic tasks—to constrain and guide AI coding agents, ensuring outputs meet software‑engineering standards.

Key differences from traditional software engineering are summarized as:

Collaboration entity: Human ↔ Human vs. Human ↔ AI ↔ Human.

Truth source: Code + Docs vs. Code + Docs + AI context.

Decision carrier: Meetings + Reviews + ADRs vs. Files + Processes + Commands.

Core tension: Complexity management vs. Complexity management + AI uncontrollability.

The most critical distinction is that traditional engineering only deals with human unreliability, whereas Harness Engineering must handle both human and AI unreliability, which follow completely different patterns.

03 | Core Problem: Deep Dive into Context Rot

Context Rot refers to the degradation of LLM output quality over time and information accumulation in long‑context or multi‑turn dialogues.

LLMs exhibit decreasing output quality as the context window grows and tokens accumulate.

Three main causes are identified:

Limited context window: Models like Claude Sonnet (200K tokens) and GPT‑4 (128K tokens) illustrate the ceiling, but the real issues lie in the next two causes.

Attention dilution: Self‑attention in Transformers has O(n²) complexity; as the context lengthens, each token’s attention weight shrinks, drowning key information. Stanford/Berkeley 2023 paper “Lost in the Middle” shows a U‑shaped recall curve where middle tokens are poorly retrieved.

Cumulative contamination: Errors, intermediate artifacts, and re‑writes from earlier turns remain in the context, occupying attention space and polluting later reasoning.

Symptoms are subtle, e.g., the AI suddenly switches from PostgreSQL to MongoDB code, repeats already‑implemented functionality, or degrades quality in later conversation turns.

Why isn’t a longer context the cure? Expanding the window to 1M tokens still suffers attention dilution; inference cost grows super‑linearly; more information does not guarantee better decisions—feeding 100 specs can be worse than a curated set of 5.

Harness Engineering’s solution bypasses the problem instead of enlarging the context:

Externalize decisions to files (space dimension): Store information in the file system and load on demand.

Structure workflow into stages (time dimension): Each stage focuses on a single decision, avoiding multi‑goal contamination.

Atomicize tasks into units (resource dimension): Each task runs in a clean context, isolated from others.

04 | Quick Reference of Core Concepts

Ten recurring concepts in the series include:

Spec‑Driven Development (SDD): Write specifications before code; frameworks like Spec‑Kit and OpenSpec enforce this.

Context Engineering: Actively manage LLM context windows, deciding what enters, when to clean, and how to allocate across instances—distinct from Prompt Engineering.

Constitution: Project‑level immutable constraints loaded at each session start (tech stack rules, coding standards, safety baselines).

Delta Spec: Describe only the differences (added/modified/removed) for each change, analogous to a Git diff.

Sub‑Agent: Independent task execution units launched by a main agent, providing context isolation, single responsibility, and parallelism.

Wave Execution: GSD’s scheduling model that parallelizes independent tasks in waves, compressing serial time to the critical‑path length.

Hooks: Event‑driven automation triggers (PreCommit, PostEdit, SessionStart) that run scripts automatically.

ADR (Architecture Decision Record): Document each architectural decision’s motivation, options, and impact; in Harness, proposal.md serves this role.

Lost in the Middle: Empirical finding that LLMs recall middle‑section information poorly, underpinning Context Rot.

Goal‑Backward Verification: Validate from the user’s perspective backward, rather than checking implementation details.

05 | Framework Ecosystem Panorama

Four major framework families address different dimensions:

Spec‑Driven (SDD): Spec‑Kit (five‑stage, Constitution + full spec, greenfield projects) and OpenSpec (three‑stage, Delta Spec, brownfield projects) and Kiro (AWS IDE integration).

Context Engineering: GSD (wave execution + Goal‑Backward verification, best practice for task atomicity).

Capability Enhancement: ECC (48 agents + 182 skills + red‑blue team audit) and OMC (19 team agents, zero‑config out‑of‑the‑box).

Orchestration: Classic stack combines OpenSpec (spec layer) + GSD (execution layer) + ECC (capability layer) to cover “what to do + how to do + with what”.

06 | Evolution: From Prompt Engineering to Harness Engineering

The progression can be visualized as three stages:

Prompt Engineering (2022‑2023): Focus on how to ask; techniques like few‑shot, chain‑of‑thought, role‑play; limited to single‑turn interactions.

Context Engineering (2024): Focus on what the AI knows; dynamic context loading, RAG, context compression, multi‑agent, but still detached from human engineering practices such as Git, CI, code review.

Harness Engineering (2025‑present): Focus on how AI works; decision externalization, staged workflows, atomic tasks, deep integration with Git/CI, forming a complete methodology.

Each stage contains the previous one; learning Harness does not discard Prompt Engineering, but adds layers to solve multi‑person, long‑term project collaboration.

Summary

Harness Engineering emerged inevitably as Vibe Coding’s five problems (uncontrollable, inconsistent, irreproducible, uncollaborative, unevolvable) drove the industry toward an engineering‑centric route.

Context Rot is the core contradiction: attention dilution and cumulative contamination in long contexts, not a lack of AI intelligence; larger windows do not solve it.

The three principles—decision externalization (space), staged workflow (time), and task atomicization (resource)—form the foundation of Harness Engineering.

The four framework families each address a dimension: SDD for specifications, context engineering for execution, capability enhancement for tools, and orchestration for coordination; the classic combination is OpenSpec + GSD + ECC.

The field is evolving: Prompt Engineering → Context Engineering → Harness Engineering, each step builds on and surpasses the previous.