Van harness naar harness engineering
Eerder schreven we wat een AI-harness is: de software rond een taalmodel die er een werkende agent van maakt. De loop, de tools, het contextbeheer en de guardrails. Dat stuk legde uit wat een harness is, en de bekendste AI-harnesses zet op een rij welke er zijn. Dit stuk gaat over het werk dat je eraan doet.
Harness engineering is het inrichten van de omgeving waarin een AI coding agent werkt, zodat hij werk oplevert dat je kunt vertrouwen. Instructiebestanden die hij elke sessie leest, tests en checks die hij zelf moet halen, tools die veelgemaakte fouten onmogelijk maken en een mens die tekent voor wat live gaat. Het model kies je bij een leverancier. Die omgeving bouw je zelf.
Waar de term vandaan komt
Harness engineering sloeg begin 2026 snel aan. Mitchell Hashimoto, medeoprichter van HashiCorp, beschreef in februari hoe AI een vaste plek kreeg in zijn werk. Eén stap noemde hij het engineeren van de harness: maakt een agent een fout, neem dan de tijd om iets te bouwen waardoor die fout nooit meer voorkomt.
Kort daarna publiceerde OpenAI hoe een klein team in vijf maanden een product bouwde waarvan alle code door Codex-agents was geschreven. De engineers typten zelf geen regel. Zij bouwden de omgeving waarin de agents dat konden.
Wat erachter zit is minder nieuw dan het klinkt. Tests, linters, code review en goede documentatie bestaan al decennia. Nieuw is dat je ze inricht voor een collega die elke ochtend alles vergeten is.
Een nieuwe collega die elke dag opnieuw begint
Denk aan hoe je een nieuwe developer inwerkt. Je geeft toegang tot de repo, een document met de afspraken, een testsuite die laat zien wat kapot is en iemand die de eerste pull requests nakijkt. Na een paar weken kent die developer de afspraken uit het hoofd.
Een coding agent is die nieuwe developer, elke sessie opnieuw. Snel, belezen en zonder herinnering aan gisteren. Wat hij gisteren leerde, moet dus in de omgeving staan. Daar houdt de vergelijking ook op: een mens onthoudt een correctie, een agent pas als jij die correctie vastlegt op een plek die de volgende sessie leest.
De vijf lagen van een goede harness
Instructies die de agent elke sessie leest
Een kort bestand in de repo, zoals AGENTS.md of CLAUDE.md, met de stack, de conventies en wat verboden is. Houd het kort: elke regel kost context, en een instructiebestand van duizend regels leest geen model goed.
Tools die de fout onmogelijk maken
Maakt de agent steeds dezelfde fout met een commando, geef hem dan een eigen commando dat die fout afvangt. Een regel in tekst kan de agent vergeten. Een tool die het verkeerde pad blokkeert, vergeet niets.
Checks die niet onderhandelen
Tests, typechecks, linters en een build die moet slagen. Ze geven elke keer hetzelfde antwoord, hoe overtuigd het model ook klinkt.
Feedback die de agent zelf kan lezen
Foutmeldingen, testoutput, logs en screenshots die terugkomen in de loop. Een agent die ziet dat de build faalt, herstelt dat zelf voordat een mens er tijd aan kwijt is.
Grenzen en een mens die tekent
Permissies en hooks bepalen wat de agent zelf mag. Voor alles wat live gaat of niet terug te draaien is, kijkt een mens mee en beslist.
Een instructie is een verzoek. Een check is een voorwaarde. Harness engineering verhuist zoveel mogelijk regels van de eerste soort naar de tweede.
De kernregel: elke fout wordt een wijziging in de omgeving
Maakt een agent een fout, dan is de reflex om de prompt bij te sturen en door te gaan. Dat helpt voor die ene keer. Volgende week, in een nieuwe sessie, gebeurt het opnieuw.
Harness engineering vraagt bij elke herhaalde fout wat er in de omgeving ontbrak. Het antwoord heeft een vaste rangorde, van zwak naar sterk.
Een regel in het instructiebestand
De snelste ingreep, en de zwakste. Het model leest de regel en kan hem halverwege een lange taak alsnog laten liggen.
Een check die faalt
Een test of lintregel die rood wordt zodra de fout terugkomt. De agent ziet het zelf en herstelt het in dezelfde loop.
Een tool of blokkade die de fout onmogelijk maakt
Het verkeerde pad bestaat niet meer. Dit kost het meeste werk en houdt het langst stand.
Kies de sterkste vorm die de moeite loont. Een fout die één keer voorkwam, verdient hooguit een regel. Een fout die elke week terugkomt, verdient een check of een tool.
Hoe dit er bij ons uitziet
Growthdesk, het groeisysteem achter de site die je nu leest, is zo’n harness. AI agents werken er elke dag aan websites van klanten: content, techniek en advertenties. Dit zijn een paar dingen die we onderweg leerden, telkens volgens de regel hierboven.
Werkinstructies per soort taak
De agent leest per taak een eigen instructieset in, met de afspraken en de bekende valkuilen. Wat voor één klant geldt, staat in de repo van die klant.
Eén browsercommando
Agents maakten bij het testen in de browser steeds dezelfde handvol fouten. Nu is er één commando dat die fouten afvangt, en een hook blokkeert de kale variant. De agent hoeft de valkuilen niet meer te onthouden.
Geen push zonder groene build
Een push zet de wijziging direct live, dus de build is de poort. Wat de agent over zijn eigen werk zegt, telt daar niet mee.
Voor en na, naast elkaar
Elke zichtbare wijziging komt terug als screenshot van de pagina ervoor en erna, met de wijziging gemarkeerd. Een mens beoordeelt dat beeld en keurt het pas dan goed.
Wrijving wordt een ticket
Loopt een agent vast op een onduidelijke instructie of een commando dat zich vreemd gedraagt, dan meldt hij dat in een backlog. Mensen beoordelen die meldingen en passen de harness aan.
Achter dat laatste punt zit een verhaal. Een agent meldde ooit dat hij een instructie had verbeterd. Het bestand was onaangeroerd, en iedereen ging ervan uit dat het probleem was opgelost. Sindsdien past een agent zijn eigen instructies nooit zelf aan, en gaat elke wijziging aan de harness langs een mens.
Wat een agent over zijn eigen werk zegt, is een mening. Een groene build, een geslaagde test en een mens die de diff heeft gezien, dat is bewijs.
Waar harness engineering misgaat
Eén gigantisch instructiebestand
Elke fout wordt een extra alinea, tot het bestand zo lang is dat het model de helft mist. Houd het hoofdbestand kort en verwijs naar losse bestanden per onderwerp.
Regels die een check hadden moeten zijn
In het instructiebestand staat: draai altijd de tests. Laat die tests draaien in een hook of in CI, dan hoeft niemand erop te vertrouwen dat de agent het onthoudt.
De agent keurt zijn eigen werk goed
Een model dat zijn eigen code reviewt, vindt die meestal prima. Laat een check, een tweede model of een mens oordelen.
Steigers voor het model van vorig jaar
Modellen worden snel beter. Een omweg voor een zwakte die al verdwenen is, maakt de harness alleen trager en lastiger te onderhouden. Ruim regelmatig op.
Waar je begint
Schrijf een kort instructiebestand
Je stack, je conventies, hoe de tests draaien en wat verboden is. Eén scherm lang is genoeg om mee te beginnen.
Laat de agent zichzelf controleren
Tests, typecheck en build moeten met één commando te draaien zijn, zodat de agent zijn fouten ziet voordat jij ze ziet.
Houd een lijst bij van herhaalde fouten
Zie je dezelfde fout twee keer, zet hem dan om in een regel, een check of een tool. De rangorde hierboven helpt bij het kiezen.
Zet grenzen rond onomkeerbare acties
Deploys, databasemigraties en alles wat klanten zien: daar tekent een mens voor. Leg dat vast in permissies, zodat het ook geldt als de agent de instructie mist.
Review de diff, elke keer
De checks vangen wat een machine kan zien. Of het resultaat doet wat de bedoeling was, beoordeelt een mens.
Die mens heeft iets nodig om tegen te toetsen. Daarom begint goed werk met agents vaak met opschrijven wat de software moet doen, en daarover gaat spec-driven development.
Conclusie: het model levert snelheid, de harness levert vertrouwen
Harness engineering is het werk dat een coding agent van een indrukwekkende demo naar een betrouwbare collega brengt. Het model bepaalt hoe snel er code komt. De omgeving bepaalt of je die code kunt vertrouwen. Die omgeving bouwen we ook voor klanten: AI agents en automatisering die blijven werken, ook als de modellen eronder veranderen.
Leg elke les vast
Een agent vergeet alles na de sessie. Wat hij moet weten, staat in de repo.
Checks boven instructies
Een test die faalt houdt meer tegen dan een regel die gelezen moet worden.
Een mens tekent
Automatische checks vangen de slordigheden. Of het werk klopt, beslist een mens.
Begin klein, met één instructiebestand en een build die de agent zelf kan draaien. Laat de harness daarna groeien met de fouten die je werkelijk tegenkomt.
Wat is harness engineering?
Wat is het verschil tussen een harness en harness engineering?
Waar komt de term harness engineering vandaan?
Hoe verschilt harness engineering van prompt engineering en context engineering?
Hoe begin je met harness engineering?
Is harness engineering nog nodig als modellen beter worden?
AI agents die werk opleveren dat je kunt vertrouwen?
Wij bouwen de omgeving rond je agents: de instructies, de checks, de tools en de grenzen die zorgen dat wat live gaat ook klopt. Van eerste opzet tot beheer.
