Harness Engineering: Building Systems That Make AI Agents Actually Work

In March 2026, OpenAI’s Codex team published a post detailing a radical experiment: they built a production application with over 1 million lines of code where zero lines were written by human hands. The product has internal daily users and external alpha testers. It ships, deploys, breaks, and gets fixed — all by agents.

The engineers didn’t write code. They designed the system that let AI write code reliably.

That system — the constraints, feedback loops, documentation, linters, and lifecycle management — is what the industry now calls a harness. And the discipline of designing these systems is harness engineering.

What Is Harness Engineering?

The term “harness” comes from horse tack — reins, saddle, bit — the complete set of equipment for channeling a powerful but unpredictable animal in the right direction. The metaphor is deliberate: the AI model is the horse (powerful, fast, but directionless), the harness is the infrastructure around it, and the engineer is the rider providing direction.

Formally, harness engineering is the design and implementation of systems that:

  • Constrain what an AI agent can do (architectural boundaries, dependency rules)
  • Inform the agent about what it should do (context engineering, documentation)
  • Verify that the agent did it correctly (testing, linting, CI validation)
  • Correct the agent when it goes wrong (feedback loops, self-repair mechanisms)

Why Harness Engineering Matters Now

Here’s the uncomfortable truth the AI industry is confronting: the underlying model matters less than the system around it.

LangChain proved this definitively. Their coding agent went from 52.8% to 66.5% on Terminal Bench 2.0 — jumping from Top 30 to Top 5 — by changing nothing about the model. They only changed the harness:

  • Self-verification loop: Added pre-completion checklist middleware — caught errors before submission
  • Context engineering: Mapped directory structures at startup — agent understood the codebase from the start
  • Loop detection: Tracked repeated file edits — prevented “doom loops”
  • Reasoning sandwich: High reasoning for planning/verification, medium for implementation — better quality within time budgets

Same model. Different harness. Dramatically better results.

OpenAI’s Million-Line Proof Point

Ryan Lopopolo, Member of the Technical Staff at OpenAI, documented the experiment in detail. The team started with an empty git repository in late August 2025. Five months later, they had shipped a product where every line of code — application logic, tests, CI configuration, documentation, observability, and internal tooling — had been written by Codex.

They estimate they built it in about 1/10th the time it would have taken to write the code by hand. Humans steered. Agents executed.

The key insight: when a software engineering team’s primary job is no longer to write code, the scarce resource becomes human time and attention. Every decision about what to put in the harness has to be measured against that constraint.

The Three Pillars of Harness Engineering

1. Context Engineering

Ensuring the agent has the right information at the right time.

Static context: Repository-local documentation (architecture specs, API contracts, style guides), AGENTS.md or CLAUDE.md files encoding project-specific rules, and cross-linked design documents validated by linters.

Dynamic context: Observability data (logs, metrics, traces) accessible to agents, directory structure mapping at startup, and CI/CD pipeline status.

The critical rule: from the agent’s perspective, anything it can’t access in-context doesn’t exist. The repository must be the single source of truth.

2. Architectural Constraints

Instead of telling the agent “write good code,” you mechanically enforce what good code looks like:

  • Dependency layering: Types → Config → Repo → Service → Runtime → UI. Each layer can only import from layers to its left, enforced by structural tests and CI.
  • Deterministic linters: Custom rules that flag violations automatically
  • LLM-based auditors: Agents that review other agents’ code for architectural compliance
  • Structural tests: Like ArchUnit, but for AI-generated code

Paradoxically, constraining the solution space makes agents more productive. When an agent can generate anything, it wastes tokens exploring dead ends.

3. Entropy Management

The most underappreciated component. AI-generated codebases accumulate entropy — documentation drifts from reality, naming conventions diverge, dead code accumulates. Harness engineering addresses this with periodic cleanup agents that verify documentation, scan for constraint violations, enforce patterns, and audit dependencies — keeping the codebase healthy for both human reviewers and future AI agents.

How Teams Actually Do This

OpenAI: Zero Human Code

Traditional engineering is about writing code. In a harness engineering model, that’s never the primary job. The engineer’s role shifts to designing architecture, writing documentation as critical infrastructure, reviewing agent output and harness effectiveness, analyzing agent behavior patterns, and designing test strategies that agents execute.

Stripe: Minions at Scale

Stripe’s internal coding agents, called Minions, produce over 1,000 merged pull requests per week. The workflow: developer posts a task in Slack → Minion writes the code → Minion passes CI → Minion opens a PR → human reviews and merges. No developer interaction between step 1 and step 5.

LangChain: Middleware-First

LangChain structures their harness as composable middleware layers: LocalContextMiddlewareLoopDetectionMiddlewareReasoningSandwichMiddlewarePreCompletionChecklistMiddleware. Each layer adds a specific capability without modifying the core agent logic.

Building Your First Harness

  • Level 1 (Single developer): A CLAUDE.md file with project conventions, pre-commit hooks for linting, a test suite the agent can run, and a clear directory structure. Set up in 1-2 hours.
  • Level 2 (Small team): An AGENTS.md with team-wide conventions, architectural constraints enforced by CI, shared prompt templates, documentation-as-code validated by linters, and code review checklists for agent-generated PRs. Set up in 1-2 days.
  • Level 3 (Engineering organization): Custom middleware layers, observability integration, entropy management agents, harness versioning and A/B testing, and agent performance monitoring. Set up in 1-2 weeks.

Common Mistakes

  1. Over-engineering the control flow: Models improve rapidly. Build your harness to be rippable — you should be able to remove “smart” logic when the model gets smart enough.

  2. Treating the harness as static: Review and update harness components with every major model update.

  3. Ignoring the documentation layer: The most impactful improvement is often better documentation. If your AGENTS.md is vague, your agent output will be vague.

  4. No feedback loop: The agent needs to know when it’s succeeding and failing. Build in self-verification, test execution, and success metrics.

  5. Human-only documentation: Everything the agent needs must be in the repository — not in Slack threads, Confluence pages, or people’s heads.

What This Means

Harness engineering represents a genuine evolution in what software engineers do. The job shifts from writing code to designing environments where AI writes code. This doesn’t mean engineers become less technical — if anything, it requires deeper architectural thinking. You’re designing systems that must work without your constant intervention.

The model is commodity. The harness is moat.


Sources: NxCode — Harness Engineering: The Complete Guide and OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World

Harness Engineering: Construyendo Sistemas Que Hacen Que los Agentes de IA Funcionen de Verdad

En marzo de 2026, el equipo de Codex de OpenAI publicó un post documentando un experimento radical: construyeron una aplicación de producción con más de 1 millón de líneas de código donde cero líneas fueron escritas por manos humanas. El producto tiene usuarios internos diarios y testers alpha externos. Ship, deploy, se rompe y se arregla — todo por agentes.

Los ingenieros no escribieron código. Diseñaron el sistema que permitió que la IA escribiera código de forma confiable.

Ese sistema — las restricciones, loops de retroalimentación, documentación, linters y gestión del ciclo de vida — es lo que la industria ahora llama un harness (arnés). Y la disciplina de diseñar estos sistemas es harness engineering.

¿Qué Es Harness Engineering?

El término “harness” viene del equipo de un caballo — riendas, silla, bocado — el conjunto completo para canalizar a un animal poderoso pero impredecible en la dirección correcta. La metáfora es deliberada: el modelo de IA es el caballo (poderoso, rápido, pero sin dirección), el harness es la infraestructura a su alrededor, y el ingeniero es el jinete dando dirección.

Formalmente, harness engineering es el diseño e implementación de sistemas que:

  • Restringen lo que un agente de IA puede hacer (límites arquitectónicos, reglas de dependencias)
  • Informan al agente sobre lo que debe hacer (ingeniería de contexto, documentación)
  • Verifican que el agente lo hizo correctamente (tests, linting, validación en CI)
  • Corrigen al agente cuando se equivoca (loops de retroalimentación, mecanismos de auto-reparación)

Por Qué Harness Engineering Importa Ahora

Aquí está la verdad incómoda que la industria de IA está enfrentando: el modelo subyacente importa menos que el sistema a su alrededor.

LangChain lo demostró definitivamente. Su agente de codificación pasó de 52.8% a 66.5% en Terminal Bench 2.0 — saltando del Top 30 al Top 5 — sin cambiar nada del modelo. Solo cambiaron el harness:

  • Loop de auto-verificación: Middleware de checklist pre-completado — atrapó errores antes de enviar
  • Ingeniería de contexto: Mapeo de estructura de directorios al inicio — el agente entendió el codebase desde el principio
  • Detección de loops: Rastreo de ediciones repetidas — previno “doom loops”
  • Sándwich de razonamiento: Razonamiento alto para planificar/verificar, medio para implementar — mejor calidad dentro de presupuestos de tiempo

Mismo modelo. Harness diferente. Resultados dramáticamente mejores.

La Prueba del Millón de Líneas de OpenAI

Ryan Lopopolo, Miembro del Staff Técnico de OpenAI, documentó el experimento en detalle. El equipo comenzó con un repositorio vacío en agosto de 2025. Cinco meses después, habían lanzado un producto donde cada línea de código — lógica de aplicación, tests, configuración de CI, documentación, observabilidad y herramientas internas — había sido escrita por Codex.

Estiman que lo construyeron en aproximadamente 1/10 del tiempo que habría tomado escribir el código a mano. Humanos dirigían. Agentes ejecutaban.

La idea clave: cuando el trabajo principal de un equipo de ingeniería ya no es escribir código, el recurso escaso se convierte en tiempo y atención humana. Cada decisión sobre qué poner en el harness tiene que medirse contra esa restricción.

Los Tres Pilares del Harness Engineering

1. Ingeniería de Contexto

Asegurar que el agente tenga la información correcta en el momento correcto.

Contexto estático: Documentación local del repositorio (specs de arquitectura, contratos de API, guías de estilo), archivos AGENTS.md o CLAUDE.md con reglas específicas del proyecto, y documentos de diseño con referencias cruzadas validados por linters.

Contexto dinámico: Datos de observabilidad (logs, métricas, trazas) accesibles para agentes, mapeo de estructura de directorios al inicio, y estado del pipeline CI/CD.

La regla crítica: desde la perspectiva del agente, cualquier cosa que no pueda acceder en contexto no existe. El repositorio debe ser la única fuente de verdad.

2. Restricciones Arquitectónicas

En lugar de decirle al agente “escribe buen código,” aplicas mecánicamente cómo se ve el buen código:

  • Capas de dependencias: Tipos → Config → Repo → Servicio → Runtime → UI. Cada capa solo puede importar de capas a su izquierda, enforced por tests estructurales y CI.
  • Linters determinísticos: Reglas personalizadas que detectan violaciones automáticamente
  • Auditores basados en LLM: Agentes que revisan el código de otros agentes para cumplimiento arquitectónico
  • Tests estructurales: Como ArchUnit, pero para código generado por IA

Paradójicamente, restringir el espacio de soluciones hace a los agentes más productivos. Cuando un agente puede generar cualquier cosa, gasta tokens explorando callejones sin salida.

3. Gestión de Entropía

El componente más subestimado. Los codebases generados por IA acumulan entropía — la documentación se desvía de la realidad, las convenciones de nombres divergen, el código muerto se acumula. El harness engineering aborda esto con agentes de limpieza periódicos que verifican documentación, escanean violaciones de restricciones, aplican patrones y auditan dependencias — manteniendo el codebase saludable tanto para revisores humanos como para futuros agentes de IA.

Cómo lo Hacen los Equipos en la Práctica

OpenAI: Cero Código Humano

La ingeniería tradicional se trata de escribir código. En un modelo de harness engineering, ese nunca es el trabajo principal. El rol del ingeniero cambia a diseñar arquitectura, escribir documentación como infraestructura crítica, revisar output de agentes y efectividad del harness, analizar patrones de comportamiento de agentes, y diseñar estrategias de test que los agentes ejecutan.

Stripe: Minions a Escala

Los agentes internos de Stripe, llamados Minions, producen más de 1,000 pull requests fusionados por semana. El flujo: el desarrollador publica una tarea en Slack → Minion escribe el código → Minion pasa CI → Minion abre un PR → humano revisa y mergea. Sin interacción del desarrollador entre el paso 1 y el paso 5.

LangChain: Middleware First

LangChain estructura su harness como capas de middleware componibles: LocalContextMiddlewareLoopDetectionMiddlewareReasoningSandwichMiddlewarePreCompletionChecklistMiddleware. Cada capa añade una capacidad específica sin modificar la lógica central del agente.

Construyendo Tu Primer Harness

  • Nivel 1 (Desarrollador individual): Un archivo CLAUDE.md con convenciones del proyecto, pre-commit hooks para linting, un suite de tests que el agente pueda ejecutar, y una estructura de directorios clara. Setup en 1-2 horas.
  • Nivel 2 (Equipo pequeño): Un AGENTS.md con convenciones del equipo, restricciones arquitectónicas enforceadas por CI, plantillas de prompt compartidas, documentación como código validada por linters, y checklists de code review para PRs generados por agentes. Setup en 1-2 días.
  • Nivel 3 (Organización de ingeniería): Capas de middleware personalizadas, integración de observabilidad, agentes de gestión de entropía, versionado de harness y A/B testing, y monitoreo de rendimiento de agentes. Setup en 1-2 semanas.

Errores Comunes

  1. Sobre-ingeniería del flujo de control: Los modelos mejoran rápido. Construye tu harness para que sea removible — deberías poder eliminar lógica “inteligente” cuando el modelo se vuelva lo suficientemente inteligente.

  2. Tratar el harness como estático: Revisa y actualiza los componentes del harness con cada actualización importante del modelo.

  3. Ignorar la capa de documentación: La mejora más impactante suele ser mejor documentación. Si tu AGENTS.md es vago, el output del agente será vago.

  4. Sin loop de retroalimentación: El agente necesita saber cuándo está teniendo éxito y cuándo está fallando. Incorpora auto-verificación, ejecución de tests y métricas de éxito.

  5. Documentación solo para humanos: Todo lo que el agente necesita debe estar en el repositorio — no en hilos de Slack, páginas de Confluence o cabezas de personas.

Qué Significa Esto

El harness engineering representa una evolución genuina en lo que hacen los ingenieros de software. El trabajo pasa de escribir código a diseñar entornos donde la IA escribe código. Esto no significa que los ingenieros se vuelvan menos técnicos — si acaso, requiere un pensamiento arquitectónico más profundo. Estás diseñando sistemas que deben funcionar sin tu intervención constante.

El modelo es commoditie. El harness es el moat.


Fuentes: NxCode — Harness Engineering: The Complete Guide y OpenAI — Harness Engineering: Leveraging Codex in an Agent-First World