We gaven dezelfde code-review-taak aan 22 AI-agents. Dezelfde pull request, dezelfde vastgepinde commit, dezelfde prompt, dezelfde model — de enige variabele was hoe elke agent de regels van het project laadde. De goedkoopste configuratie bleek de grondigste te zijn, en de reden waarom zegt iets algemeens over context engineering.
TL;DR: Een context-engine digest plus één directe read van het machine-leesbare beleidsbestand versloeg elke andere strategie: $1,56 per review en 9,6/13 geverifieerde bevindingen — goedkoper dan het lezen van documentatie ($2,30, 8,6/13) en beter dan alleen digest ($1,77, 7,8/13). Alles lezen scoorde het slechtst van allemaal (7,4/13). Alle 22 agents liepen op Claude Opus 4.8, en 21 van 22 bereikten hetzelfde verdict.
Wat: een harness, een context engine en één pull request
Wat is een “harness”?
Elke serieuze poging om AI-agents in een productie repository te laten werken groeit twee lagen governance.
De proza-laag — conventies, architectuurregels, teststandardards. In onze repo dat zijn CLAUDE.md en docs/**: “backend is snake_case,” “domein importeert nooit infrastructuur,” “alle route handlers zijn async.” Mensen lezen het; agents wordt gezegd het ook te lezen.
De machine-leesbare laag — de harness config. De onze is een enkel JSON-bestand dat elk pad in de repo in risicolagen classificeert en afdwingbare gates aan elke laag koppelt. CI leest het. Merge-beleid leest het. Het is geen advies — het is beleid:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Terminologie opmerking: “harness” noemt ook de agent runtime zelf — de steiger van tools, vaardigheden en MCP-servers waar een agent door handelt, zoals in harnext , “de coding agent harness.” In dit bericht is de harness config het beleidsbestand van de repo dat zo’n runtime en de CI beide afdwingen.)
Een code reviewer — mens of agent — kan niet oordelen “mag deze PR mergen?” zonder dit bestand. Een Tier-3 PR met de review-agent check overgeslagen is een beleidsinbreuk zelfs als elke test groen is. Onthoud dat voorbeeld; het besluit het experiment.
Omdat beide lagen bestaan, mandateert de repo een gate: geen agent start werk voordat deze context is geladen — en bewijst dit via een bevestigingsblok dat reviewers controleren. De vraag die dit bericht beantwoordt is eenvoudig: wat is de goedkoopste correcte manier om aan deze gate te voldoen?
Ontmoet harnext en meaninggrid
meaninggrid is de gehoste Context Engine van harnext
, de MIT-gelicentieerde, provider-agnostische coding-agent harness van QualityUnit (zes tools — read, write, edit, bash, skill, mcp — npm i -g harnext). De pitch van de leverancier voor de Context Engine is direct: “het brein van je agent.” Bronnen stromen in een voortdurend bijgewerkte index — “het grid” — en per query “rangschikt en snoeit de engine het tot token-efficiënte context, rechtstreeks in de harness bedraden”: voortdurende index, relevantierangschikking, dedup en cache. Het kopnummer van harnext is −89% tokens per query gemiddeld. Dat is de claim van de leverancier; één doel van dit experiment was om met onze eigen getallen op een echte taak te meten wat dit soort compressie werkelijk bespaart — en wat het kost.
In onze implementatie neemt het grid de proza-documentatie van de repository in; elke opname produceert een onveranderbare, versioned snapshot. Agents bevragen het via MCP (meaninggrid.harnext.dev/mcp) met een enkele context_research call en ontvangen een gesynthetiseerde, geciteerde digest met stempel van de snapshot_id, die de agent in zijn bevestigingsblok moet citeren — verifieerbare context concreet gemaakt.
Wat de gate produceert — het bevestigingsblok (voorbeeld; projectspecificiteiten verborgen):
Geladen via: geoptimaliseerde hybrid (context-engine digest + beleidsbestand alleen).
- context_research call #1 (conventies / layering / testen / beveiliging /
risicolagen) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integratie checklist +
flow-engine extra-care regels) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Lees harness config (volledig) van schijf voor exacte tier-patronen,
requiredChecks, mergePolicy, evidenceConfig.
Lees NIET CLAUDE.md of docs/* (gedekt door de digest).
De snapshot_id is echt — een reviewer kan precies verifiëren welke versie van de regels de agent gebruikte.
Drie hypothesen
Het experiment was ontworpen om drie testbare voorspellingen te beslechten, van tevoren opgeschreven:
H1 — Een digest is goedkoper dan opnieuw lezen. Neem de proza docs eenmaal in, serveer elke agent een compacte gesynthetiseerde digest, in plaats van dat elke agent elk document op elke taak opnieuw leest. Indien waar: betekenisvol lagere kosten per review, bij gelijke verdicts.
H2 — Parafrase vernietigt beleid. Een digest kan “Tier 3 vereist menselijke review” zonder verlies dragen. Het kan "requireReviewAgent": true niet zonder verlies dragen — de exacte, citeerbare specificiteiten die een reviewer nodig heeft om een inbreuk te stellen sterven in samenvatting. Indien waar: agents met alleen digest zouden systematisch gate-inbreuken missen die agents met het letterlijke beleidsbestand vangen.
H3 — Leanere context leest dieper. Context wordt twee keer betaald — eenmaal in dollars, eenmaal in aandacht: elk redundant document in het venster concurreert met de code onder review. Indien waar: alles lezen (digest + alle docs) mag niet winnen; de meest minimale voldoende context mag.
Hoe we het testten
Tweeëntwintig agents beoordeelden dezelfde Tier-3 pull request in onze productie monorepo (een LLM-provider integratie: 44 bestanden, +2.111 regels, echte inzet — facturingstabellen, flow-engine routing). Vijf armen, verschillend alleen in de context-laadstap:
| Arm | Context laden | n |
|---|---|---|
| meaninggrid | context-engine digest alleen (2× context_research) | 5 |
| disk | leest 7+ docs van schijf — geen context engine | 5 |
| hybrid | digest + leest ALLE docs | 5 |
| opt-hybrid | digest + leest ÉÉN bestand: de harness config | 5 |
| cold | helemaal geen convention context (baseline) | 2 |
Grondregels: één vastgepinde commit, één prompt body, één model — Claude Opus 4.8 — alle armen verweven in een enkele gelijktijdige batch. Agents werd de commentaarthread van de PR ontzegd, zodat eerdere experimentronden niet konden uitlekken. Elk getal komt uit de ruwe agent transcripts, met tokengebruik per API-verzoek gededupliceerd en geprijsd tegen lijstprijzen. Kwaliteit wordt gescoord tegen 13 onafhankelijk geverifieerde, echte defecten in de PR, patroon-gematcht in elk review body en handmatig gecontroleerd op false positives. Verdict-overeenstemming over alle armen: 21/22 zei REQUEST CHANGES.
Dus wat: de goedkoopste configuratie won ook op kwaliteit
| Arm | Kosten / review | Bevindingen (van 13) | Gate bevindingen (van 3) | Wall clock |
|---|---|---|---|---|
| meaninggrid | $1,77 | 7,8 | 0,2 | 5:34 |
| disk | $2,30 | 8,6 | 0,8 | 4:35 |
| hybrid | $1,83 | 7,4 | 0,8 | 5:40 |
| opt-hybrid ★ | $1,56 | 9,6 | 1,4 | 4:55 |
| cold | $1,64 | 8,0 | 0,5 | 4:13 |
★ = de configuratie die we nu als standaard skill van de repo verzenden. Wall clock omvat gedeelde contention van het gelijktijdig uitvoeren van 22 agents.
H1 — bevestigd
De digest-only arm beoordeeld voor $1,77 vs $2,30 voor het lezen van docs (−23%), en de winnende digest-plus-één-bestand arm voor $1,56 (−32%) — bij gelijke verdicts. De besparing samengesteld: de digest vervangt een stapel documenten die anders door elk vervolgend API-call’s context zou rijden.
H2 — bevestigd, beslissend
De overgeslagen review-agent check — een echte merge-policy inbreuk in deze PR — werd gevangen door 5 van 5 agents met het letterlijke beleidsbestand, en door 1 van 5 digest-only agents. Het mechanisme is precies wat H2 voorspelde: om die bevinding te schrijven, moet een agent exacte CI-checknamen tegen exacte config-velden matchen — een parafrase is geen citeerbaar bewijs, dus digest-only agents aarzelen en laten het vallen. Één directe read herstelt het.
H3 — bevestigd
De alles-lezen hybrid bevatte de meeste context van elke arm en scoorde slechtst (7,4/13), terwijl de meest minimale voldoende arm het beste scoorde (9,6/13) — en was het beste van alle armen op de enkele diepste bevinding, een dead-code bug die het traceren van een call path over drie bestanden vereist. Redundante proza voegde geen informatie toe; het concurreerde met de code om aandacht.
Één eerlijke voetnoot: de cold baseline (8,0/13 tegen $1,64) toont aan dat de meeste van de 13 defecten gewone code bugs zijn die een sterk model zonder convention context vindt. Wat cold niet kan doen is de beleidshelft van de taak — gates, tiers, merge-regels — wat precies is waar de armen uit elkaar groeien.
Cureer de proza in een digest. Lees het beleidsbestand rauw. Lees niets twee keer.
Volledige onthulling
- Model: elke API-call van elke agent liep op claude-opus-4-8 (Claude Opus 4.8) — geverifieerd uit het
modelveld van elke transcript regel, niet aangenomen. Resultaten kunnen op andere modellen verschillen; kleinere modellen zijn waarschijnlijk meer afhankelijk van gecureerde context, niet minder. - Prijzen: kosten gebruiken Anthropic lijstprijzen op het moment van schrijven; werkelijke facturering kan verschillen. Relatieve vergelijkingen worden niet beïnvloed.
- Steekproefgrootte: n=5 per arm (n=2 voor cold), één PR, één repository, één taaktype. Het gate effect (5/5 vs 1/5) is scherp; per-bevinding percentages elders zijn ±1 agent. Behandel dit als een sterke pilot, niet een benchmark.
- Kwaliteitsmaatstaf: patroondetectie over beoordelingstekst (citaten uitgesloten), handmatig gecontroleerd op false positives. Het telt vermeldingen van geverifieerde defecten, niet algehele beoordelingseloquentie.
- Timing: alle 22 agents deelden één machine en één API-quota; wall-clock nummers omvatten die contention.
- We hebben onszelf twee keer gecorrigeerd: initiële token-tellingen waren 2–3× opgeblazen (per-regel gebruiksduplicate in transcripts; opgelost door request-ID dedup), en een eerdere timeline visual onderschatte wall time (opgelost door volledige interval toewijzing). Beide correcties zijn in elk getal hier ingebakken.
Nu wat: steel de lus
Wat we hebben verzonden
De winnende arm is nu de standaard check-context-first skill van de repo: trek de context-engine digest (twee calls), lees dan precies één bestand van schijf — de harness config — en zend een bevestigingsblok uit dat de snapshot en de exacte gates citeert. Één gemeten zwakte, één one-line beleidsfix, opnieuw gevalideerd dezelfde dag. Die lus — meten, de context policy fixen, opnieuw valideren — is het gedeelte dat we je zouden aanraden te stelen, welke context engine je ook gebruikt.
Wat je maandag kunt doen
- Splits je agent context in twee: proza (conventies, architectuur, testen) vs machine-leesbare beleid (CI gates, risicolagen, merge-regels).
- Cureer de proza; cureer nooit het beleid. Serveer de proza via een context engine — meaninggrid is de onze — en maak het beleidsbestand een verplichte woordelijke read in je context gate.
- Maak context verifieerbaar. Versie de opgenomen context; vereisen dat agents de snapshot id in een bevestigingsblok citeren die reviewers werkelijk kunnen controleren.
- Meet voordat je gelooft — inclusief ons. Een handvol agents per arm op je eigen repository is genoeg om het patroon te zien. Score de beoordelingen tegen geverifieerde bevindingen, niet vibes.
Een open uitnodiging
Als je dit experiment op je eigen repository uitvoert — dezelfde armen, je model, je harness — zouden we graag je getallen zien, vooral als ze de onze tegenspreken. En als je team hulp wil bij het opzetten van een context gate als deze, of wil praten over meaninggrid en de harnext stack, neem contact op met het FlowHunt team of vind de open-source harness op harnext.dev . Replicaties, vragen en correcties allemaal welkom.

