Harness Engineering: Bouw systemen rond AI-agents (2026)

TL;DR

Wat is Harness Engineering?

Harness engineering is de discipline van het bouwen van systemen, tools, beperkingen en feedbackloops rond AI-coding-agents om ze betrouwbaar en productief te maken.

De term werd bedacht door Mitchell Hashimoto (medeoprichter van HashiCorp) en kreeg mainstream aandacht toen OpenAI hun Codex-artikel over dit onderwerp publiceerde begin 2026.

Het kernidee is simpel:

Agent = Model + Harness

Het model biedt intelligentie. De harness maakt die intelligentie nuttig. Een betere harness is vaak belangrijker dan een beter model.

Waarom het nu belangrijk is

In 2025 adopteerde elk team AI-coding-agents. In 2026 zijn de winnende teams degenen die hun agent-omgevingen hebben ge-engineerd — en niet alleen het beste model hebben gekozen.

Het leidende principe van Mitchell Hashimoto:

"Elke keer dat je merkt dat een agent een fout maakt, neem je de tijd om een oplossing te engineeren zodat de agent die fout nooit meer maakt."

Dit is geen prompt engineering. Het is systems engineering voor AI.

Het bewijs: Harness > Model

LangChain voerde een gecontroleerd experiment uit op Terminal Bench 2.0. Zonder het onderliggende model te veranderen, verbeterden ze de nauwkeurigheid van hun coding-agent van 52,8% naar 66,5% — een verbetering van 26% — door alleen de harness te verbeteren.

De wijzigingen omvatten:

• Betere contextbestanden (AGENTS.md)


• Gestructureerde output-beperkingen


• Zelfverificatie-loops


• Tool-optimalisatie

De 7 componenten van een Harness

1. Context Engineering

Context engineering is de fundering. Hier geef je de agent een kaart van je codebase, je conventies en je beperkingen.

• CLAUDE.md / AGENTS.md bestanden in de root van je repo
• Directory-maps en architectuuroverzichten
• Regels voor codeerstijl en naamgevingsconventies

# CLAUDE.md example
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. Architecturale beperkingen

In plaats van te hopen dat de agent de juiste architectuur kiest, moet je deze afdwingen.

• Rigide gelaagde architecturen gevalideerd door linters
• Structurele tests die falen als patronen worden geschonden
• Importbeperkingen via ESLint-regels of aangepaste scripts

3. Tools & MCP-servers

Agents hebben tools nodig om effectief te zijn. De beste harnesses ontsluiten interne tooling via:

• CLI-wrappers — geef de voorkeur aan bekende CLI's (git, docker, npm) boven maatwerktools
• MCP (Model Context Protocol) servers — laat agents je interne API's, databases en services aanroepen
• Toegang tot het bestandssysteem — beperkt tot specifieke mappen om onbedoelde schade te voorkomen

4. Sub-agents & Context-firewalls

Langlopende agent-sessies stapelen context op die uiteindelijk de prestaties verslechtert — dit wordt context-rot genoemd.

De oplossing: sub-agents met context-firewalls.

• Splits complexe taken op in discrete subtaken
• Elke subtaak draait in zijn eigen sessie met een schone context
• Geef alleen gestructureerde resultaten door tussen agents, geen ruwe conversaties

1. Initializer Agent — plant het werk, maakt een lijst met features
2. Coding Agent — voert elke feature afzonderlijk uit

5. Hooks & Back-pressure

Geautomatiseerde feedbackloops die fouten opvangen voordat ze zich opstapelen:

• Pre-commit hooks — type-checking, linting, formatting
• Test runners — agents moeten tests draaien na elke wijziging
• Build-verificatie — faal snel bij kapotte builds

6. Zelfverificatie-loops

Dwing agents om hun eigen werk te verifiëren voordat ze taken als voltooid markeren:

• Draai de testsuite na wijzigingen
• Controleer of de build slaagt
• Verifieer of de output overeenkomt met de specificatie
• Maak een screenshot en vergelijk (voor UI-werk)

7. Voortgangsdocumentatie

Voor langlopende taken (30+ minuten):

• Houd een voortgangsbestand bij dat voltooide stappen bijhoudt
• Commit werk regelmatig zodat volgende sessies verder kunnen gaan
• Gebruik gestructureerde takenlijsten, geen vrije notities

Resultaten uit de praktijk

OpenAI Codex Team

3 engineers produceerden een codebase van een miljoen regels met nul handmatig geschreven code over een periode van 5 maanden. Ze haalden gemiddeld 3,5 gemergede PR's per engineer per dag — een doorloop die onmogelijk is zonder een volwassen harness.

Hun harness bevatte: strikte commit-conventies, geautomatiseerde testen op elke PR, en agent-aware CI/CD-pipelines.

Stripe's "Minions"

Het interne systeem van Stripe produceert 1.000+ gemergede PR's per week met behulp van AI-agents. Hun harness omvat:

• Nauw gedefinieerde taakdefinities
• Verplichte code-review door mensen
• Geautomatiseerde regressietesten
• Rollback-automatisering

Anthropic's architectuur met twee agents

Anthropic publiceerde hun aanpak voor effectieve harnesses voor langlopende agents:

• Gestructureerde feature-lijsten als het overdrachtsformaat tussen agents
• Op Git gebaseerde voortgangsregistratie zodat agents na een onderbreking kunnen hervatten
• Expliciete exit-criteria zodat agents weten wanneer ze moeten stoppen

Hoe begin je met het bouwen van je Harness

Stap 1: Maak je contextbestand

Voeg een CLAUDE.md (of AGENTS.md) toe aan de root van je project:

# Project: [Your Project]

## Stack
[Framework, language, database, hosting]

## Architecture
[Directory structure with one-line descriptions]

## Rules
[5-10 hard rules the agent must follow]

## Common Tasks
[How to run tests, build, deploy]

Stap 2: Voeg structurele beperkingen toe

# Voorbeeld: ESLint-regel die directe DB-imports in componenten voorkomt
# .eslintrc — no-restricted-imports rule

Stel pre-commit hooks in die je regels automatisch afdwingen.

Stap 3: Bouw verificatieloops

Zorg ervoor dat je agent het volgende kan:

1. Tests draaien (npm test, pytest, etc.)


2. Types controleren (tsc --noEmit, mypy)


3. Linting uitvoeren (eslint ., ruff check)

Stap 4: Beperk de scope van agent-sessies

Geef een agent niet je hele backlog. In plaats daarvan:

• Eén feature per sessie
• Eén bugfix per sessie
• Duidelijke acceptatiecriteria voor elke taak

Stap 5: Itereer op de harness

Elke keer dat een agent een fout maakt:

1. Identificeer de bronoorzaak
2. Voeg een regel, beperking of hook toe die dit voorkomt
3. Test de oplossing

Harness Engineering vs. Prompt Engineering

Prompt engineering is nog steeds nuttig, maar het is slechts een klein deel van het geheel. Harness engineering is de multiplier.

De opkomende rol: De Harness Engineer

Engineering splitst zich in twee helften:

1. Environment Building — het creëren van structuur, tools, beperkingen en feedbackloops
2. Work Management — het plannen, beoordelen en orkestreren van parallelle agent-sessies

Niet te verwarren met: Harness.io

Als je zocht op "Harness Engineering" op zoek naar het DevOps-platform — Harness.io is iets heel anders. Het is een door AI aangedreven CI/CD-platform gewaardeerd op $5,5 miljard (per december 2025) dat continue integratie, levering, feature flags, cloudkostenbeheer en beveiligingstests biedt.

Hoewel Harness.io en harness engineering een naam delen, lossen ze verschillende problemen op. Hoewel er een interessante overlap is: de door AI aangedreven DevOps van Harness.io is aantoonbaar een toepassing van harness engineering-principes op de deployment-pipeline.

Conclusie

Het model is de motor. De harness is de auto. Niemand wint een race met alleen een motor.

Als je in 2026 AI-coding-agents gebruikt en niet investeert in je harness, laat je het grootste deel van de waarde liggen. Begin met een contextbestand, voeg beperkingen toe, bouw verificatieloops en itereer elke keer dat er iets kapot gaat.

De teams die het snelst shippen, gebruiken geen betere modellen. Ze gebruiken betere harnesses.