Harness Engineering: De volledige gids voor het bouwen van systemen die AI-agents echt laten werken

Maart 2026 — Als 2025 het jaar was waarin AI-agents bewezen dat ze code konden schrijven, dan is 2026 het jaar waarin we leerden dat de agent niet het moeilijke deel is — het harnas wel.

Het Codex-team van OpenAI heeft zojuist een productie-applicatie gebouwd met meer dan 1 miljoen regels code waarbij nul regels door mensenhanden zijn geschreven. De ingenieurs schreven geen code. Ze ontwierpen het systeem dat AI betrouwbaar code liet schrijven. Dat systeem — de beperkingen, feedbackloops, documentatie, linters en het levenscyclusbeheer — is wat de industrie nu een harnas (harness) noemt.

Harness engineering is de nieuwe discipline van het ontwerpen van deze systemen. En het verandert wat het betekent om een software engineer te zijn.

---

Wat is Harness Engineering?

De paardenmetafoor

De term "harnas" komt van de tuigage van een paard — teugels, zadel, bit — de complete set uitrusting om een krachtig maar onvoorspelbaar dier in de juiste richting te sturen. De metafoor is bewust gekozen:

• Het paard is het AI-model — krachtig, snel, maar het weet niet uit zichzelf waar het heen moet.
• Het harnas is de infrastructuur — beperkingen, vangrails, feedbackloops die de kracht van het model productief kanaliseren.
• De ruiter is de menselijke ingenieur — die de richting aangeeft, maar niet zelf rent.

Zonder harnas is een AI-agent als een volbloed paard in een open veld. Snel, indrukwekkend, en volledig nutteloos om ergens te komen.

De formele definitie

Harness engineering is het ontwerp en de implementatie van systemen die:

1. Beperken wat een AI-agent kan doen (architecturale grenzen, afhankelijkheidsregels).
2. Informeren van de agent over wat hij moet doen (context engineering, documentatie).
3. Verifiëren of de agent het correct heeft gedaan (testen, linting, CI-validatie).
4. Corrigeren van de agent wanneer het fout gaat (feedbackloops, zelfherstelmechanismen).

Martin Fowler beschrijft het als "de tooling en praktijken die we kunnen gebruiken om AI-agents in toom te houden" — maar het is meer dan alleen veiligheid. Een goed harnas maakt agents capabeler, niet alleen gecontroleerder.

---

Waarom Harness Engineering nu belangrijk is

Het model is een commodity. Het harnas is de slotgracht (Moat).

Hier is de ongemakkelijke waarheid waar de AI-industrie mee wordt geconfronteerd: het onderliggende model doet er minder toe dan het systeem eromheen.

LangChain heeft dit definitief bewezen. Hun coding-agent ging van 52,8% naar 66,5% op Terminal Bench 2.0 — een sprong van de Top 30 naar de Top 5 — door niets aan het model te veranderen. Ze veranderden alleen het harnas:

Wijziging	Wat ze deden	Impact
Zelfverificatie-loop	Pre-completion checklist middleware toegevoegd	Fouten opgespoord voor indiening
Context engineering	Directorystructuren in kaart gebracht bij opstarten	Agent begreep codebase vanaf het begin
Loop-detectie	Herhaalde bestandsbewerkingen bijgehouden	"Doom loops" voorkomen
Reasoning sandwich	Hoog redeneerniveau voor planning/verificatie, medium voor implementatie	Betere kwaliteit binnen tijdsbudgetten

Zelfde model. Ander harnas. Dramatisch betere resultaten.

OpenAI's bewijslast van 1 miljoen regels

Het experiment van OpenAI is tot nu toe het meest overtuigende bewijs:

• 5 maanden ontwikkeling.
• 1 miljoen+ regels code in het eindproduct.
• Nul handmatig geschreven regels — elke regel werd geproduceerd door Codex-agents.
• Gebouwd in ~1/10e van de tijd die mensen nodig zouden hebben gehad.
• Het product heeft interne dagelijkse gebruikers en externe alfatesters.
• Het wordt verzonden, uitgerold, gaat kapot en wordt gerepareerd — allemaal door agents binnen het harnas.

De taak van de ingenieurs? Het ontwerpen van het harnas. Het specificeren van de intentie. Het geven van feedback. Niet het schrijven van code.

---

De drie pijlers van Harness Engineering

Het framework van OpenAI verdeelt harness engineering in drie kerncategorieën:

1. Context Engineering

Context engineering gaat over het verzekeren dat de agent de juiste informatie op het juiste moment heeft.

Statische context:

• Repository-lokale documentatie (architectuurspecificaties, API-contracten, stijlgidsen).
• AGENTS.md of CLAUDE.md bestanden die projectspecifieke regels bevatten.
• Gelinkte ontwerpdocumenten gevalideerd door linters.

Dynamische context:

• Observability-data (logs, metrics, traces) toegankelijk voor agents.
• Mapping van directorystructuur bij opstarten van de agent.
• CI/CD pipeline-status en testresultaten.

De cruciale regel: Vanuit het perspectief van de agent bestaat alles waar hij geen toegang toe heeft in de context niet. Kennis in Google Docs, Slack-threads of in de hoofden van mensen is onzichtbaar voor het systeem. De repository moet de enige bron van waarheid (single source of truth) zijn.

2. Architecturale beperkingen

Dit is waar harness engineering het sterkst afwijkt van traditionele AI-prompting. In plaats van de agent te vertellen "schrijf goede code", dwing je mechanisch af hoe goede code eruitziet.

Afhankelijkheidslagen:

Types → Config → Repo → Service → Runtime → UI

Elke laag kan alleen importeren uit lagen aan de linkerkant. Dit is geen suggestie — het wordt afgedwongen door structurele tests en CI-validatie.

Tools voor het afdwingen van beperkingen:

• Deterministische linters — Aangepaste regels die schendingen automatisch markeren.
• LLM-gebaseerde auditors — Agents die de code van andere agents controleren op architecturale naleving.
• Structurele tests — Zoals ArchUnit, maar voor door AI gegenereerde code.
• Pre-commit hooks — Automatische controles voordat code wordt gecommit.

Waarom beperkingen de output verbeteren: Paradoxaal genoeg maakt het beperken van de oplossingsruimte agents productiever, niet minder. Wanneer een agent alles kan genereren, verspilt hij tokens aan het verkennen van doodlopende wegen. Wanneer het harnas duidelijke grenzen definieert, convergeert de agent sneller naar correcte oplossingen.

3. Entropy Management ("Garbage Collection")

Dit is de meest ondergewaardeerde component. Na verloop van tijd verzamelen door AI gegenereerde codebases entropie — documentatie wijkt af van de realiteit, naamgevingsconventies lopen uiteen, dode code hoopt zich op.

Harness engineering pakt dit aan met periodieke opschoon-agents:

• Documentatie-consistentie agents — Verifiëren of documentatie overeenkomt met de huidige code.
• Beperkingsschending-scanners — Vinden code die door eerdere controles is geglipt.
• Patroon-handhavingsagents — Identificeren en herstellen afwijkingen van gevestigde patronen.
• Dependency-auditors — Traceren en oplossen van circulaire of onnodige afhankelijkheden.

Deze agents draaien volgens schema's — dagelijks, wekelijks of getriggerd door specifieke gebeurtenissen — en houden de codebase gezond voor zowel menselijke reviewers als toekomstige AI-agents.

---

Harness Engineering in de praktijk: Hoe teams het echt doen

De OpenAI-aanpak: Nul menselijke code

De teamstructuur van OpenAI voor harness engineering:

Rol	Traditioneel	Harness Engineering
Code schrijven	Primaire taak	Nooit
Architectuur ontwerpen	Deel van de taak	Primaire taak
Documentatie schrijven	Bijzaak	Kritieke infrastructuur
PR's beoordelen	Code review	Review van agent-output + effectiviteit harnas
Debuggen	Code lezen	Analyseren van gedragspatronen van agents
Testen	Tests schrijven	Teststrategieën ontwerpen die agents uitvoeren

De Stripe-aanpak: Minions op schaal

De interne coding-agents van Stripe, genaamd Minions, produceren nu meer dan 1.000 samengevoegde pull-requests per week:

1. Developer plaatst een taak in Slack.
2. Minion schrijft de code.
3. Minion slaagt voor de CI.
4. Minion opent een PR.
5. Mens beoordeelt en merget.

Geen interactie van de ontwikkelaar tussen stap 1 en stap 5. Het harnas regelt alles — testuitvoering, CI-validatie, stijlnaleving en documentatie-updates.

De LangChain-aanpak: Middleware-First

LangChain structureert hun harnas als samenstelbare middleware-lagen:

Agent Aanvraag
  → LocalContextMiddleware (brengt codebase in kaart)
  → LoopDetectionMiddleware (voorkomt herhaling)
  → ReasoningSandwichMiddleware (optimaliseert rekenkracht)
  → PreCompletionChecklistMiddleware (dwingt verificatie af)
  → Agent Respons

Elke middleware-laag voegt een specifieke capaciteit toe zonder de kernlogica van de agent te wijzigen. Deze modulaire aanpak maakt het harnas testbaar en evolueerbaar.

---

Je eerste harnas bouwen: Een praktisch framework

Niveau 1: Basis harnas (Individuele ontwikkelaar)

Als je Claude Code, Cursor of Codex gebruikt voor individuele projecten:

Wat in te stellen:

• CLAUDE.md of .cursorrules bestand met projectconventies.
• Pre-commit hooks voor linting en opmaak.
• Een testsuite die de agent kan uitvoeren voor zelfverificatie.
• Duidelijke directorystructuur met consistente naamgeving.

Installatietijd: 1-2 uur Impact: Voorkomt de meest voorkomende fouten van agents.

Niveau 2: Team-harnas (Klein team)

Voor teams van 3-10 ontwikkelaars die een codebase delen:

Toevoegen aan Niveau 1:

• AGENTS.md met teambrede conventies.
• Architecturale beperkingen afgedwongen door CI.
• Gedeelde prompt-templates voor veelvoorkomende taken.
• Documentatie-als-code gevalideerd door linters.
• Code review checklists specifiek voor door agents gegenereerde PR's.

Installatietijd: 1-2 dagen Impact: Consistent agent-gedrag binnen het team.

Niveau 3: Productie-harnas (Engineering-organisatie)

Voor organisaties die tientallen gelijktijdige agents draaien:

Toevoegen aan Niveau 2:

• Aangepaste middleware-lagen (loop-detectie, redeneringsoptimalisatie).
• Observability-integratie (agents lezen logs en metrics).
• Entropy management agents op geplande tijden.
• Harnas-versiebeheer en A/B-testen.
• Dashboards voor het monitoren van agent-prestaties.
• Escalatierichtlijnen voor wanneer agents vastlopen.

Installatietijd: 1-2 weken Impact: Agents opereren als autonome bijdragers.

---

Veelvoorkomende fouten bij Harness Engineering

1. Over-engineering van de Control Flow

"Als je de control flow te complex maakt, zal de volgende modelupdate je systeem breken."

Modellen verbeteren snel. Mogelijkheden die in 2024 complexe pipelines vereisten, worden nu afgehandeld door een enkele prompt in het contextvenster. Bouw je harnas "verwijderbaar" (rippable) — je moet in staat zijn om "slimme" logica te verwijderen wanneer het model slim genoeg wordt om het niet meer nodig te hebben.

2. Het harnas als statisch behandelen

Het harnas moet mee-evolueren met het model. Wanneer een nieuwe modelrelease het redeneren verbetert, kan je middleware voor redeneringsoptimalisatie contraproductief worden. Beoordeel en update harnascomponenten bij elke grote modelupdate.

3. De documentatielaag negeren

De meest impactvolle harnasverbetering is vaak de eenvoudigste: betere documentatie. Als je AGENTS.md vaag is, zal de output van je agent vaag zijn. Investeer in nauwkeurige, machineleesbare documentatie die dient als de bron van waarheid voor de agent.

4. Geen feedbackloop

Een harnas zonder feedback is een kooi, geen gids. De agent moet weten wanneer hij slaagt en wanneer hij faalt. Bouw in:

• Zelfverificatiestappen voor voltooiing van de taak.
• Testuitvoering als onderdeel van de workflow van de agent.
• Statistieken over succespercentages van agents per taaktype.

5. Documentatie alleen voor mensen

Als je architecturale beslissingen in de hoofden van mensen zitten of in Confluence-pagina's waar de agent niet bij kan, heeft het harnas een gat. Alles wat de agent nodig heeft, moet in de repository staan.

---

Harness Engineering vs. Gerelateerde Concepten

Concept	Reikwijdte	Focus
Prompt Engineering	Enkele interactie	Opstellen van effectieve prompts
Context Engineering	Contextvenster model	Welke informatie het model ziet
Harness Engineering	Gehele agent-systeem	Omgeving, beperkingen, feedback, levenscyclus
Agent Engineering	Agent-architectuur	Intern agent-ontwerp en routering
Platform Engineering	Infrastructuur	Uitrol, schaling, operaties

Harness engineering omvat context engineering en put uit prompt engineering, maar het opereert op een hoger niveau — het gaat om het complete systeem dat agents betrouwbaar maakt, niet alleen de inputs voor een enkele interactie.

---

Wat dit betekent voor Software Engineers

De baan verandert

Harness engineering vertegenwoordigt een echte evolutie in wat software engineers doen:

Voorheen	Nu
Code schrijven	Omgevingen ontwerpen waarin AI code schrijft
Code debuggen	Gedrag van agents debuggen
Code reviewen	Review van agent-output + effectiviteit harnas
Tests schrijven	Teststrategieën ontwerpen
Documentatie bijhouden	Documentatie bouwen als machineleesbare infrastructuur

Dit betekent niet dat ingenieurs minder technisch worden. Integendeel, harness engineering vereist dieper architecturaal denken — je ontwerpt systemen die moeten werken zonder je constante tussenkomst.

De vaardigheden die er toe doen

Gebaseerd op wat we hebben gezien bij het bouwen van AI-aangedreven producten bij NxCode:

1. Systeemdenken — Begrijpen hoe beperkingen, feedbackloops en documentatie op elkaar inwerken.
2. Architectuurontwerp — Grenzen definiëren die afdwingbaar en productief zijn.
3. Specificaties schrijven — Intentie nauwkeurig genoeg verwoorden zodat agents deze kunnen uitvoeren.
4. Observability — Monitoring bouwen die gedragspatronen van agents onthult.
5. Iteratiesnelheid — Snel testen en verfijnen van harnas-configuraties.

Onze ervaring: Wat werkt in de praktijk

We hebben AI-aangedreven webapplicaties gebouwd met behulp van meerdere agent-systemen (Claude Code, Codex, Cursor). De patronen die voor ons het grootste verschil hebben gemaakt:

• Repository-first documentatie: Elke architecturale beslissing, naamgevingsconventie en deployment-proces staat in de repo. Niets leeft in Slack of Google Docs.
• Incrementele opbouw van beperkingen: Begin met basis-linting, voeg architecturale beperkingen toe naarmate patronen ontstaan, probeer niet vooraf het perfecte harnas te ontwerpen.
• Agent-specifieke review checklists: Door AI gegenereerde code heeft andere foutmodi dan menselijke code. Ons reviewproces houdt rekening met veelvoorkomende agent-patronen (over-abstractie, onnodige foutafhandeling, documentatiedrift).
• Multi-provider harnasontwerp: Ons harnas werkt met Claude-, GPT- en Gemini-modellen. Provider-agnostisch ontwerp betekent dat we van model kunnen wisselen zonder het hele systeem opnieuw te hoeven bouwen.

---

Belangrijkste punten

1. Harness engineering is de nieuwe discipline van het ontwerpen van systemen die AI-agents betrouwbaar maken — beperkingen, feedbackloops, documentatie en levenscyclusbeheer.
2. Het model is een commodity; het harnas is de slotgracht — LangChain sprong van de Top 30 naar de Top 5 op benchmarks door alleen het harnas te veranderen.
3. OpenAI bouwde 1M+ regels met nul menselijke code — wat bewijst dat harness engineering werkt op productieschaal.
4. Drie pijlers: Context engineering, architecturale beperkingen en entropy management.
5. Begin eenvoudig: Een goede AGENTS.md en pre-commit hooks hebben meer impact dan complexe middleware.
6. De taak van de ingenieur evolueert — van het schrijven van code naar het ontwerpen van omgevingen waar AI code schrijft.
7. Bouw verwijderbare (rippable) harnassen — over-engineering faalt wanneer modellen verbeteren; houd het aanpasbaar.

---

Gerelateerde bronnen

• The Agentic Web uitgelegd: AGENTS.md, MCP vs A2A — De protocollaag waar harness engineering op voortbouwt.
• Cursor Cloud Agents: Autonoom coderen op virtuele machines — Cloud-gebaseerde agent-harnassen in de praktijk.
• Claude Code Remote Control: Terminal Handoff Gids — Agent-sessies op afstand beheren.
• Bouw je website met NxCode — AI-gestuurde webontwikkeling met multi-provider harnas-architectuur.