English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Harness Engineering: OpenAI's Agent-First Development Paradigm with Zero Human-Written Code

Forum topic · 小凯 · 2026-02-26

Summary

Harness Engineering is an AI-native software development paradigm coined by OpenAI in 2025, based on an experiment in which 3 engineers (later 7) produced roughly 1 million lines of code over 5 months with zero human-written code and around 1,500 pull requests. The philosophy is 'humans steer, agents execute': engineers design environments, specify intent, and build feedback loops rather than writing code. The approach rests on three pillars: Context Engineering (keeping AGENTS.md as a short map into a structured knowledge base), Architectural Constraints (rigid layered architectures enforced mechanically via custom linters and structure tests), and Garbage Collection (periodic cleanup agents and golden rules to prevent pattern drift and AI slop). Key practices include optimizing the repository for agent readability, making the running application legible to agents via Chrome DevTools Protocol, LogQL, and PromQL, and loosening merge gates since corrections are cheap when agent throughput exceeds human attention. Martin Fowler popularized the analysis, predicting convergence toward AI-friendly tech stacks. The paradigm redefines the engineer's role toward scaffolding, control systems, and quality mechanisms rather than syntax and boilerplate.

Harness Engineering: OpenAI's Agent-First Development Paradigm

Key points

  • The experiment: OpenAI reported a 2025 project where ~1,000,000 lines of code were produced with 0 human-written lines, by 3 engineers (growing to 7) over 5 months, via ~1,500 PRs (~3.5 PRs per person per day), an estimated 10x efficiency gain.
  • Core idea: *"Humans steer. Agents execute."* Engineers shift from writing code to designing environments, specifying intent, and building feedback loops.
  • Origin: The term was popularized by OpenAI (openai.com/index/harness-engineering) and analyzed by Martin Fowler (martinfowler.com), inspired partly by Mitchell Hashimoto's writing.
  • The three pillars

    1. Context Engineering — Agent context windows are scarce. Keep AGENTS.md as a ~100-line directory (map, not encyclopedia) pointing to a structured knowledge base (architecture/, design/, quality/, plans/, beliefs/), with progressive disclosure and CI-verified docs. 2. Architectural Constraints — Agents work best in strict boundaries: rigid layering (Types → Config → Repo → Service → Runtime → UI), forward-only dependencies, enforced by custom linters and structure tests rather than convention. 3. Garbage Collection — Agents copy existing repo patterns, including bad ones. Weekly manual cleanup of "AI slop" doesn't scale; instead encode golden rules (e.g., prefer shared toolkits, never YOLO-probe data shapes) and run periodic cleanup agents that open refactor PRs.

    Timeline: 0 → 1M lines

  • Phase 1 — Environment building (slowest): early slowness was due to an underspecified environment, not model weakness. On failure, ask "what capability is missing?" rather than "retry."
  • Phase 2 — Agent readability: inaccessible context = nonexistent. Slack decisions were moved into versioned repo artifacts; dependencies chosen for in-repo reasonability.
  • Phase 3 — End-to-end autonomy: given one prompt, Codex could verify state, reproduce bugs, record demo videos, implement fixes, verify, open a PR, respond to feedback, fix build failures, and merge — escalating to humans only for judgment calls.
  • Notable practices

  • Making apps agent-legible: per-worktree dev instances, Chrome DevTools Protocol integration, LogQL/PromQL queries — single Codex runs exceeding 6 hours were common.
  • Merge philosophy: minimal blocking gates, short-lived PRs, flaky tests get follow-up runs. Rationale: *corrections are cheap, waiting is expensive* when agent throughput exceeds human attention — only valid in high-throughput settings.
  • Context strategy (per Anthropic's context engineering guidance): selection, compression, placement, isolation, and format optimization. Note the "lost in the middle" effect — correctness can degrade well before a model's nominal context limit.
  • Implications

  • Engineers become designers of scaffolding, feedback loops, and control systems; syntax memory and boilerplate skills matter less, architecture/tooling/process design more.
  • Fowler predicts convergence toward AI-friendly tech stacks and standardized repo topologies.
  • Open questions remain: where human judgment adds the most leverage, how to encode it for compounding returns, and long-term architectural consistency.
  • > "Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code." — OpenAI

    References:

  • https://openai.com/index/harness-engineering/
  • https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
  • https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
  • https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering
  • https://openai.com/index/introducing-codex/

Tags

#harness-engineering#openai#ai-agents#context-engineering#codex#software-development#martin-fowler#developer-tools

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/177168601