01 · Software bouwen met AI, onder kwaliteitscontrole

Harness Engineering

Een coding agent is meer dan een model. Het is een model plus zijn harness: de tools, hooks, checks, reviewloops en het geheugen eromheen. Harness Engineering is de term die de branche daarvoor gebruikt. Op deze pagina staat onze versie ervan, uitgeschreven, inclusief de regels waar we onszelf aan houden.

Snelle code moet ook goede code zijn.

AI maakte code schrijven goedkoop: minuten in plaats van dagen. Daarmee is het knelpunt verschoven, niet verdwenen. De vraag is niet meer of de code gemaakt kan worden, maar of je kunt vertrouwen op wat er gemaakt is.

Dat is geen promptprobleem maar een systeemprobleem, en systeemproblemen zijn precies waar software-engineers voor zijn. Toevallig vinden we ze ook nog leuk.

Het getal dat ons overtuigde
Buiten de top 30 top vijf

LangChain bracht zijn Deep Agents op Terminal-Bench 2.0 van buiten de top dertig naar de top vijf door alleen het harness aan te passen. Zelfde model, zelfde gewichten. Hun resultaat, niet het onze. We noemen het omdat het veranderde waar we onze eigen engineeringinzet op richten.

LangChain · Terminal-Bench 2.0
De productielijn

Van work item naar pull request. Een engineer beslist.

Zo bouwt de SaaS Factory, voor elk product en elke klant. Agents doen het routinewerk van work item tot pull request: lezen, sorteren, de test schrijven, de code schrijven, elke suite draaien. Onze engineers houden de besluiten, de review en het laatste woord.

01Werk komt binnenUit je backlog, op een schema of op verzoek.
02SorterenEen snel model leest het item en de code: klaar, al opgelost, dubbel, of informatie mist.
03ControlerenEen sterker model toetst elk oordeel voordat er iets gebeurt.
04Eén vraag, als iets mistDe agent stelt zijn vraag één keer en wacht. Een mens antwoordt.
05Klaar om te bouwenAlleen items met een duidelijke scope en een getoetst oordeel gaan door.

Van klaar naar samengevoegd

06Bouwen, test eerstIn een schone sandbox schrijft de agent eerst de falende test, dan de code, en draait elke testsuite.
07BewijzenEen aparte job bouwt de wijziging opnieuw op vanaf nul. De nieuwe tests moeten falen vóór en slagen ná.
08Tweede reviewEen model van een andere leverancier beoordeelt de wijziging. Hooguit twee reparatierondes.
09Pull requestEen geteste wijziging in jouw repository, gekoppeld aan het work item, met het bewijs erbij.
10Een engineer keurt goedEen van onze engineers beoordeelt en voltooit elke merge. Geen agent kan dat.

Bij elke twijfel, fout, onenigheid of overschreden budget stopt de lijn en gaat het item naar een mens. Nooit een retry-lus, nooit een merge.

hier handelt een mens

De grenzen zijn afgedwongen in de omgeving, niet in een document, dus ze houden ook als een agent zijn instructies negeert. Elke run is begrensd en gelogd, en een mens kan elke stap met één schakelaar stoppen.

EIGEN MACHINEElke run start in een schone sandbox van een vastgezet image, in onze Azure-omgeving in West-Europa, en wordt daarna gewist.
SECRETS ERBUITENDe agent ziet nooit een sleutel. Een proxy voegt ze toe op weg naar buiten.
NETWERK DICHTAlleen hosts op een lijst. Al het andere wordt geweigerd en gelogd.
MAIN ONBEREIKBAARDe agent kan alleen een pull request voorstellen. De branchpolicy weigert elke directe push, en zijn identiteit kan geen merge voltooien.
a.

De schrijver en de reviewer zijn twee verschillende agents.

Agents zijn goed in code schrijven. Alleen is iedereen, mens of agent, te mild voor eigen werk. Daarom is de regel simpel: de schrijver beoordeelt nooit zijn eigen werk.

Generator

Bouwt volgens de spec. Heeft de context, de tools en het geheugen, maar geen enkele bevoegdheid om iets goed te keuren.

Evaluator

Toetst het kritisch aan onze definition of done en stuurt het terug. Die lus draait door tot aan alle criteria is voldaan.

De deterministische checks draaien de hele tijd mee, bij elke commit. Samen met de evaluatorloop bepalen ze wanneer een wijziging klaar is om bekeken te worden. Pas dan kijkt er een mens naar, sneller en met meer signaal, want de ruis is er al uit. De gate maakt menselijke review beter. Het laatste woord blijft bij de mens.

b.

Code wordt samengevoegd als de gate het zegt.

Elke wijziging gaat langs dezelfde vier controlepunten voordat hij wordt samengevoegd: twee automatische checks die continu draaien, één AI-agent en één mens. Geen sluiproutes, en niets wordt samengevoegd op gevoel.

AUTOBuild, tests & mutationDeterministisch. Rood is rood, en elke nieuwe test moet rood worden als zijn code wordt gemuteerd.
AUTOStatische analyse & securityDependencies en OWASP-baseline, bij elke commit.
AGENTSceptische reviewEen tweede agent toetst aan de definition of done.
HUMANIemand tekentEen engineer met naam tekent, de product owner accepteert de scope.
Uitgeschreven

Dit is een echte gate.

Zo ziet een gate eruit op een echte opdracht: één pagina, vóór de eerste commit met de klant afgesproken, met dezelfde vijf checks als elke SaaS Factory-release. Dat zijn build en tests, statische analyse en security, een sceptische review, mutatie op nieuwe tests, en de scope. Daarna is de gate de scheidsrechter. Die van jou verschilt alleen in de drempels, want die schrijven we op basis van jouw standaarden.

Acceptance gate — SaaS Factory release

De gate zoals hij in de repository staat, in het Engels.

  • AUTObuild & tests: the build succeeds, warnings treated as errors
  • AUTObuild & tests: every test green, on a clean checkout
  • AUTOstatic analysis & security: analysis clean, no new findings above the agreed threshold
  • AUTOstatic analysis & security: dependency and secret scan clean, OWASP baseline passed
  • AUTOmutation on new tests: every new test goes red when the code it tests is mutated
  • AGENTsceptical review: a second agent, against the written definition of done
  • HUMANscope: named engineer signs; product owner accepts the scope
En een echte hook
  • ONevery file write by an agent
  • IFpath matches migrations/ or infra/
  • THENblock, print the rule, require a human
  • IFcommand contains a destructive delete
  • THENblock. no override flag exists
  • ELSEsilence

Gaat het goed, dan blijft het stil. Gaat het mis, dan krijg je de volledige uitleg. De agent leest de regel die hij overtrad en herstelt zichzelf voordat er een mens hoeft te kijken.

Waarom dit nu telt

Technische schuld van agents is onzichtbaar.

Door AI geschreven code ziet er netjes uit. Hij komt door elke check die je toevallig hebt, terwijl het team langzaam het zicht verliest op wat er werkelijk is opgeleverd.

72 %van de respondenten zegt dat hun organisatie al minstens één productie-incident had door AI-gegenereerde codeHarness · Coleman Parkes-onderzoek onder 900 engineers en technisch leidinggevenden · aug 2025
+31,3 %meer pull requests samengevoegd zonder enige review (door mens of agent)Faros AI · 22.000 developers, laagste tegenover hoogste AI-adoptie per organisatie · 2026
0,45 % → 6,66 %van de commits bevatte een gedupliceerd blok van vijf regels of meer, 2022 tegenover 2024GitClear · 211 miljoen regels in ~10.000 repositories · 2025
Drie gepubliceerde onderzoeken, met hun populatie en hun vergelijking erbij. Het zijn Harness, Faros AI en GitClear. Alle drie zijn onderzoek van leveranciers: nuttige context voor waarom gates ertoe doen, maar geen bewijs dat de onze werken.
c.

Elke fout wordt een regel.

Kwaliteit zet je stap voor stap vast in een codebasis. Elke regel in ons harness is terug te voeren op een echte fout. Maakt een beter model een regel overbodig, dan halen we hem weg. Een harness wordt ontworpen, en klein gehouden.

01Begin klein
02Let op de fouten
03Leg de fix vast
04Geef het een eigenaar
Waar de agents op bouwen

Entry

Het harness is de helft van het verhaal. De andere helft is dat onze agents twintig jaar architectuur erven in plaats van die opnieuw te bedenken: bouwstenen, een blauwdruk en codegeneratie voor .NET en Angular, openbaar onder Apache-2.0, zodat je het eerst kunt lezen.

Wat de agents weten

Twintig jaar, doorzoekbaar

Architectuurbeslissingen, duur betaalde lessen en de redenering achter twintig jaar keuzes, vastgelegd en gestructureerd. Diezelfde kennis voedt de context van onze agents, zodat ze bouwen als mensen die hier al jaren rondlopen.

Een andere manier van samenwerken

Een team naast het jouwe, onder jouw leiding, achter jouw gate.

Wanneer het past

Je hebt een product owner en een backlog, en wat je nodig hebt is capaciteit die achter een gate oplevert, geen project met een begin en een eind. Onze engineers werken vanuit Rotterdam, Belgrado en Novi Sad: één bedrijf, dezelfde arbeidscontracten, geen tijdsverschil, en dezelfde ISO 27001-beheersmaatregelen op alle drie de kantoren.

Wat je krijgt

Een team met een eigen lead, dat in jouw backlog werkt onder jouw product owner, met het harness en de gates op jouw pipeline vanaf de eerste week. Je betaalt per maand en kunt op elk moment stoppen. De gate en de code blijven in jouw repository.

Zie het op je eigen code.

In vijf dagen heb je een vaste offerte voor een veilige MVP. Zes weken later draait hij in Europese productie. Een app die je al met AI bouwde, krijgt eerst een Hardening Audit.

De methode

De methode is openbaar. Het inzicht kostte twintig jaar.

De gate staat op deze pagina, het fundament is Apache-2.0, en de reviewloop past in vier alinea’s. Wat twintig jaar kostte, is weten welke fouten er in jouw domein echt toe doen. Dat deel doen we liever naast je team dan dat we het opschrijven.

Agents schrijven · checks blokkeren · een engineer beslist