TL;DR: Harness engineering is de praktijk om alles rond een AI-model heen te ontwerpen — prompts, tools, sandbox, tests en reviewloops — zodat coding agents betrouwbaarder werken. Kernformule: Agent = Model + Harness. Voor agencies is het een senior specialisme; voor opdrachtgevers een governancevraag. Dit is niet het CI/CD-bedrijf Harness.io. Peildatum: 5 november 2026.
Nederlandse digital agencies en IT-opdrachtgevers gebruiken steeds vaker AI coding agents. De vraag die ertoe doet is niet of je AI inzet, maar hoe je de kwaliteit van die output borgt.
Wat is harness engineering?
Harness engineering is het ontwerpen van de omgeving rond AI coding agents: system prompts, tools en MCP-koppelingen, sandbox, orkestratie, hooks, geheugen, tests en reviewstappen. Het model levert de intelligentie; de harness maakt die intelligentie bruikbaar en stuurbaar.
Zoekmachines mengen twee termen door elkaar:
| Term | Betekenis |
|---|---|
| Harness (Harness.io) | Commercieel CI/CD- en software delivery-platform |
| Harness engineering | Discipline: omgeving rond AI-agents ontwerpen zodat output betrouwbaarder wordt |
Dit artikel gaat over dat tweede.
Wat is een agent harness?
De korte formule die je bij LangChain en bij Birgitta Böckeler (Thoughtworks / martinfowler.com) terugziet:
Agent = Model + Harness
Een los model is nog geen agent. Pas als de harness state, tools, feedback en grenzen toevoegt, wordt het een werkbare agent.
Böckeler vernauwt de term voor coding agents: een deel van de harness zit al in het product (system prompt, code retrieval). Teams bouwen daarnaast een outer harness voor hun eigen codebase en werkwijze — dat is waar het verschil zit.
Wat zijn guides en sensors?
Böckeler splitst die outer harness in twee richtingen:
| Richting | Rol | Voorbeelden |
|---|---|---|
| Guides (feedforward) | Sturen vóór de actie | AGENTS.md, skills, bootstrap-scripts, coding conventions |
| Sensors (feedback) | Checken ná de actie | Tests, linters, type-checkers, structurele checks, AI-code review |
Alleen feedback → agent herhaalt dezelfde fouten. Alleen feedforward → regels zonder te weten of ze werken. Beide samen vormen een stuurloop.
Twee uitvoeringsvormen binnen sensors:
- Computational: deterministisch en snel (CPU) — tests, linters, type-checkers. Betrouwbaar genoeg om bij elke wijziging mee te draaien.
- Inferential: semantisch en probabilistisch (vaak GPU/NPU) — AI-review, “LLM as judge”. Duurder, trager, minder deterministisch, bruikbaar voor rijkere sturing.
Het menselijke werk zit in de steering loop: dezelfde fout komt vaker terug → verbeter de harness. Niet “probeer harder”, maar een betere guide of een scherpere sensor.
Concreet: een harness is geen fancy prompt. Het is het systeem van conventies, checks en feedback waardoor AI-output vóór menselijke review al een filter passeert.
Waarom telt harness engineering voor agencies?
Voor agencies verschuift de waarde. Uren besteden aan code kloppen blijft bestaan, maar het verschil zit steeds vaker in het ontwerpen en onderhouden van de harness: conventies, tests, architectuurgrenzen, reviewloops en contextbeheer.
Sam Black (Towards Data Science): de verbetering komt vaak harder aan als je de harness versterkt dan als je alleen een iets beter model forceert. Domeinkennis zit in de workflow: hoe je werk opknipt, waar je checkpoints zet, wat “klaar” betekent.
Praktische lessen uit productieteams (o.a. Study Notes / snowan):
- Begin klein. Eerst een werkende loop, dan pas extra infrastructuur.
- Minder tools kan beter werken. Een scherpere toolset presteert vaak beter dan “overal toegang”.
- Beheer context, state en observability. Wat in context zit, wat op schijf leeft, en of je elke toolcall kunt traceren, bepaalt of je een agent kunt verbeteren.
Dat maakt harness engineering een senior specialisme — vergelijkbaar met wanneer je een senior vs. medior developer kiest: je moet weten hoe het systeem hoort te werken, welke fouten je accepteert, en welke checks afdwingbaar zijn. Junior prompten ≠ stuurbaar leverproces bouwen.
Wat agencies concreet doen
- Maak harness-werk zichtbaar in offertes en sprints:
AGENTS.md, structurele tests, pre-commit checks, reviewgates. - Meet terugkerende fouten. Elke herhaalde fout = ontbrekende guide of sensor.
- Behandel Claude Code, Codex of vergelijkbare tools als startpunt, niet als eindstation. De outer harness voor jouw codebase maak je zelf.
Wat moeten opdrachtgevers hun leverancier vragen?
“Gebruiken jullie AI?” is een zwakke vraag. Die zegt niets over kwaliteit, traceerbaarheid of reviewlast.
Een harness is ook governance. Wie AI-output in productie laat landen zonder tests, linting, architectuurchecks en een heldere reviewroute, koopt snelheid zonder rem.
Vragen die je kunt stellen:
- Welke checks draaien automatisch voordat een AI-wijziging bij een mens belandt (tests, types, linters, architectuurregels)?
- Waar staan jullie conventions (
AGENTS.md, skills, service-templates) en wie houdt die bij? - Kunnen jullie een wijziging traceren? Welke toolcalls, welke falende checks, welke herstelpogingen?
- Wie mag verwachtingen wijzigen? Als de agent code én tests schrijft, hoe voorkomen jullie dat dezelfde mislezing in beide landt?
- Wat gebeurt er bij herhaalde fouten? Verbeteren jullie dan de harness, of blijft iemand handmatig opruimen?
Je hoeft geen ML-team te zijn om dit te vragen. Je vraagt naar hetzelfde als bij elke serieuze leverancier: hoe borgen jullie kwaliteit als het volume omhooggaat — ook als je snel wilt schalen.
Werkt een sterke harness met een goedkoper model?
HastCode beschrijft een experiment van Naresh Jain (Specmatic). Coding agents bouwden dezelfde API-service, met en zonder harness. De harness gebruikte specificaties (OpenAPI/AsyncAPI), voorbeelden en contractchecks; een aparte suite van 178 acceptatietests die de harness niet zag, beoordeelde elk resultaat.
Met een kosten-geoptimaliseerd model:
| Conditie | Resultaat |
|---|---|
| Zonder harness | 3 van 10 runs geaccepteerd |
| Met harness | 10 van 10 runs geaccepteerd |
| Tokens (met harness) | ~3,9× meer (ruim 5,8M → bijna 23M gemiddeld) |
Dit is één experiment: tien gepaarde runs op één greenfield Java-service. Geen algemene wet. Wel een bruikbaar signaal: bij een zwakker of goedkoper model kan de harness het verschil zijn tussen “vaak bijna” en “structureel voldoende”. In dezelfde tabel haalde een sterker model 10/10 ook zonder die harness, met minder tokens. Les: niet “altijd meer tokens”, maar “meet of jouw harness het model beter maakt voor jouw taak”.
Hoe begin je klein met een outer harness?
Je hoeft geen platformteam van twintig. Minimale outer harness:
- Guides: korte, door mensen geschreven projectregels (
AGENTS.md), plus skills voor terugkerende taken. - Snelle sensors links: type-check, linter, gerichte tests vóór of bij commit.
- Zwaardere sensors later: bredere review, mutation testing of AI-review in CI — niet bij elke toetsaanslag.
- Observability: log toolcalls, falende checks en tokengebruik, anders kun je de harness niet verbeteren.
- Steering: elke herhaalde reviewopmerking wordt een regel of een check.
Grens (Böckeler): functioneel gedrag blijft lastig. Groen op AI-geschreven tests ≠ bewijs dat de applicatie doet wat jij bedoelde. Houd verwachtingen (contracts, fixtures, featurelijsten) buiten bereik van de agent waar dat kan.
Kernpunten om te onthouden
- Agent = Model + Harness — het model alleen is niet genoeg.
- Guides + sensors samen vormen de stuurloop; één van beide is onvoldoende.
- Outer harness maak je zelf voor jouw codebase — tooling is startpunt.
- Herhaalde fouten zijn ontbrekende guides of sensors, geen reden om harder te prompten.
- Opdrachtgevers vragen naar checks, conventions, traceerbaarheid — niet alleen “gebruiken jullie AI?”.
Tot slot
Harness engineering brengt AI coding agents van demo naar leverproces. Voor agencies: nieuw senior vak. Voor opdrachtgevers: governancevraag over kwaliteit van AI-output.
Digital Tribes werkt met Nederlandse senior freelance specialisten — inclusief AI-developers — via contractuele tussenkomst of directe bemiddeling, en met teams onder jouw regie.
Zoek je een senior specialist die een harness in jouw stack opzet of de AI-werkwijze van je leverancier beoordeelt? Plan een intake.
Bronnen
- Birgitta Böckeler, Harness engineering for coding agent users (2 april 2026)
- Vivek Trivedy / LangChain, The Anatomy of an Agent Harness (10 maart 2026)
- Sam Black, What Is Harness Engineering? A Hands-On Introduction (Towards Data Science, 29 oktober 2026)
- Mira Vance / HastCode, Harness engineering: steering coding agents with guides and sensors (29 oktober 2026) — Specmatic-/Jain-experiment
- Study Notes (snowan), How to Build an Agent Harness