Hvad en kontekstmotor faktisk køber dig: Vi kørte 22 AI-kodeanmeldere på fem forskellige måder

AI Agents Context Engineering MCP Agentic Workflows

Vi gav den samme kodeanmeldelsesopgave til 22 AI-agenter. Samme pull request, samme fastgjort commit, samme prompt, samme model — den eneste variabel var, hvordan hver agent indlæste projektets regler. Den billigste konfiguration viste sig at være den mest grundig, og grunden til det siger noget generelt om kontekstudvikling.

TL;DR: En kontekstmotor-digest plus én direkte læsning af den maskinerbare politikfil slog hver anden strategi: $1,56 pr. anmeldelse og 9,6/13 verificerede fund — billigere end at læse dokumentationen ($2,30, 8,6/13) og bedre end kun digest ($1,77, 7,8/13). Læsning af alt scorede værst af alle (7,4/13). Alle 22 agenter kørte på Claude Opus 4.8, og 21 af 22 nåede til samme konklusion.

Hvad: en harness, en kontekstmotor og en pull request

Hvad er en “harness”?

Enhver seriøs forsøg på at lade AI-agenter arbejde i et produktionsrepository vokser to lag af styring.

Prosa-laget — konventioner, arkitekturregler, teststandarder. I vores repo er det CLAUDE.md og docs/**: “backend er snake_case,” “domain importerer aldrig infrastruktur,” “alle rute-handlere er async.” Mennesker læser det; agenter bliver fortalt at læse det også.

Det maskinerbare lagharness-konfigurationen. Vores er en enkelt JSON-fil, der klassificerer hver sti i repoet i risikotrin og vedhæfter håndhævelsesgates til hvert trin. CI læser det. Fusionspolitik læser det. Det er ikke råd — det er politik:

"tier3": {
  "requiredChecks": [
    "lint", "test", "build", "review-agent",
    "harness-smoke", "manual-approval", "expanded-coverage"
  ],
  "mergePolicy": {
    "minApprovals": 2,
    "requireReviewAgent": true,
    "allowSelfMerge": false
  }
}

(Terminologisk note: “harness” navngiver også agenten runtime selv — stilladserne af værktøjer, færdigheder og MCP-servere, som en agent handler gennem, som i harnext , “kodningsagentens harness.” I dette indlæg er harness-konfigurationen repoets politikfil, som sådan en runtime og CI’en begge håndhæver.)

En kodeanmeldelse — menneske eller agent — kan ikke bedømme “må denne PR fusioneres?” uden denne fil. En Tier-3 PR med review-agent-kontrollen sprunget over er en politikovertrædelse selvom hver test er grøn. Husk dette eksempel; det afgør eksperimentet.

Fordi begge lag eksisterer, mandaterer repoet en gate: ingen agent starter arbejde før indlæsning af denne kontekst — og beviser det gjorde det, via en bekræftelsesblok, som anmeldere kontrollerer. Spørgsmålet, som dette indlæg besvarer, er simpelt: hvad er den billigste korrekte måde at opfylde denne gate?

Møde harnext og meaninggrid

meaninggrid er den hostede kontekstmotor fra harnext , QualityUnits MIT-licenserede, udbyder-agnostiske kodningsagent-harness (seks værktøjer — læs, skriv, rediger, bash, færdighed, mcp — npm i -g harnext). Sælgers pitch for kontextmotoren er direkte: “hjerner for din agent.” Kilder strømmer ind i et kontinuerligt opdateret indeks — “nettet” — og pr. forespørgsel “rangerer og beskærer motoren det til token-effektiv kontekst, ledningsført direkte ind i harness’en”: kontinuerligt indeks, relevansrangering, deduplering og cache. harnext’s toptaltal er −89% tokens pr. forespørgsel i gennemsnit. Det er leverandørens påstand; ét formål med dette eksperiment var at måle, med vores egne tal på en rigtig opgave, hvad den slags komprimering faktisk sparer — og hvad det koster.

I vores implementering indlæser nettet repositorys prosa-dokumentation; hver indlæsning producerer et uforanderligt, versioneret øjebliksbillede. Agenter forespørger det over MCP (meaninggrid.harnext.dev/mcp) med et enkelt context_research-kald og modtager en syntetiseret, citeret sammenfatning stemplet med snapshot_id, som agenten skal citere i sin bekræftelsesblok — revidérbar kontekst gjort konkret.

Context engine pipeline: prose docs flow through ingest, versioned snapshot and context_research into the agent, while the machine-readable policy file is read directly

Hvad gaten producerer — bekræftelsesblokken (eksempel; projektspecifikke detaljer udeladt):

Loaded via: optimized hybrid (context-engine digest + policy file only).

- context_research call #1 (conventions / layering / testing / security /
  risk tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integration checklist +
  flow-engine extra-care rules) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Read harness config (full) from disk for exact tier patterns,
  requiredChecks, mergePolicy, evidenceConfig.
  Did NOT read CLAUDE.md or docs/* (covered by the digest).

snapshot_id er reelt — en anmeldelse kan verificere nøjagtigt, hvilken version af reglerne agenten arbejdede ud fra.

Tre hypoteser

Eksperimentet var designet til at afgjøre tre testbare forudsigelser, skrevet ned på forhånd:

H1 — En digest er billigere end genlæsning. Indlæs prosa-dokumenterne én gang, servér hver agent en kompakt syntetiseret sammenfatning, i stedet for at hver agent genlæser hvert dokument på hver opgave. Hvis sandt: meningsfuldt lavere omkostning pr. anmeldelse, med lige domme.

H2 — Omformulering ødelægger politik. En sammenfatning kan bære “Tier 3 kræver menneskelig gennemgang” uden tab. Den kan ikke bære "requireReviewAgent": true uden tab — de nøjagtige, citérbare detaljer, som en anmeldelse har brug for at hævde en overtrædelse, dør i sammenfatning. Hvis sandt: kun-digest-agenter bør systematisk misse gate-overtrædelser, som agenter, der holder den bogstavelige politikfil, fanger.

H3 — Leanere kontekst læser dybere. Kontekst betales for to gange — én gang i dollars, én gang i opmærksomhed: hvert redundant dokument i vinduet konkurrerer med koden under anmeldelse. Hvis sandt: læsning af alt (digest + all dokumenter) bør ikke vinde; den leaneste tilstrækkelige kontekst bør.

Hvordan vi testede det

To og tyve agenter anmeldede samme Tier-3 pull request i vores produktions-monorepo (en LLM-leverandør-integration: 44 filer, +2.111 linjer, rigtige indsatser — faktureringsborde, flow-motor-routing). Fem arme, der kun adskiller sig i kontekstindlæsningstrinet:

ArmContext loadingn
meaninggridcontext-engine digest only (2× context_research)5
diskreads 7+ docs from disk — no context engine5
hybriddigest + reads ALL the docs5
opt-hybriddigest + reads ONE file: the harness config5
coldno convention context at all (baseline)2

Grundregler: ét fastgjort commit, én prompt-krop, én model — Claude Opus 4.8 — alle arme sammenflettede i en enkelt samtidig batch. Agenter blev udelukket fra PR’ens kommentartråd, så tidligere eksperimentrunder kunne ikke lække ind. Hvert tal kommer fra de rå agenttransskriptioner, med tokenudgift dedupleret pr. API-anmodning og prissat til listepriser. Kvalitet scoredes mod 13 uafhængigt verificerede, rigtige defekter i PR’en, mønstersøgt i hver anmeldelses krop og manuelt revideret for falsk positiver. Dommeenighed på tværs af alle arme: 21/22 sagde REQUEST CHANGES.

Så hvad: den billigste konfiguration vandt også på kvalitet

Scatter chart of cost per review versus verified findings: opt-hybrid is cheapest and most thorough, read-everything hybrid scores worst
ArmCost / reviewFindings (of 13)Gate findings (of 3)Wall clock
meaninggrid$1.777.80.25:34
disk$2.308.60.84:35
hybrid$1.837.40.85:40
opt-hybrid ★$1.569.61.44:55
cold$1.648.00.54:13

★ = the configuration we now ship as the repo’s default skill. Wall clock includes shared contention from running 22 agents concurrently.

H1 — bekræftet

Digest-kun-armen anmeldede for $1,77 mod $2,30 for dokumentationslæsning (−23%), og den vindende digest-plus-en-fil-arm for $1,56 (−32%) — med lige domme. Besparelsen sammensætter sig: digestet erstatter en stak dokumenter, der ellers ville køre gennem hver efterfølgende API-kaldets kontekst.

H2 — bekræftet, afgørende

Den sprunget review-agent-kontrol — en ægte fusionspolitik-overtrædelse i denne PR — blev fanget af 5 af 5 agenter, der holdt den bogstavelige politikfil, og af 1 af 5 kun-digest-agenter. Mekanismen er præcis, hvad H2 forudsagde: for at skrive det fund, skal en agent matche nøjagtige CI-kontrolnavne mod nøjagtige konfigurationsfelter — en omformulering er ikke citérbar evidens, så kun-digest-agenter sikrer sig og dropper det. En direkte læsning gendanner det.

Side by side: the harness policy requiring the review-agent check, and the CI run where that check was skipped while everything else passed

H3 — bekræftet

Hybrid’en, der læste alt, bar mest kontekst af alle arme og scorede værst (7,4/13), mens den leaneste tilstrækkelige arm scorede bedst (9,6/13) — og var bedst af alle arme på det enkelte dybeste fund, en dead-code-fejl, der kræver at spore en kaldesti på tværs af tre filer. Redundant prosa tilføjede ikke information; det konkurrerede med koden om opmærksomhed.

Time anatomy of a digest agent versus a docs-reading agent: the context engine wait is visible, doc reads are fast slivers, model time dominates both

En ærlig fodnote: cold baseline (8,0/13 til $1,64) viser, at det meste af de 13 defekter er almindelige kodebugs, som en stærk model finder uden nogen konventionskontekst overhovedet. Hvad cold ikke kan gøre, er politikhalvdelen af jobbet — gates, trin, fusionsregler — hvilket er præcis hvor armene adskiller sig.

Kuratér prosaen til en digest. Læs politikfilen rå. Læs ikke noget to gange.

Fuld offentliggørelse

  • Model: hvert API-kald af hver agent kørte på claude-opus-4-8 (Claude Opus 4.8) — bekræftet fra model-feltet i hver transskriptionslinje, ikke antaget. Resultaterne kan variere på andre modeller; mindre modeller afhænger sandsynligvis mere af kurateret kontekst, ikke mindre.
  • Priser: omkostninger bruger Anthropic-listepriser på tidspunktet for skrivningen; faktisk fakturering kan variere. Relative sammenligninger påvirkes ikke.
  • Stikprøvestørrelse: n=5 pr. arm (n=2 for cold), en PR, ét repository, én opgavetype. Gate-effekten (5/5 vs 1/5) er skarp; per-fund-rater andre steder er ±1 agent. Behandl dette som en stærk pilot, ikke et benchmark.
  • Kvalitetsmåling: mønstergenkendelse over anmeldelses-tekst (citater udeladt), manuelt revideret for falsk positiver. Det tæller omtale af verificerede defekter, ikke overordnet anmeldels-veltalenhed.
  • Timing: alle 22 agenter delte én maskine og én API-kvote; wall-clock-tal inkluderer den kontention.
  • Vi korrigerede os selv to gange: indledende tokentellinger var oppustede 2–3× (per-linje-udnyttelse duplikering i transskriptioner; rettet ved anmodnings-ID-deduplering), og en tidligere tidslinje-visual undertallede wall-tid (rettet ved fuld interval-tildeling). Begge korrektioner er bagt ind i hvert tal her.
FlowHunt Logo

Klar til at vokse din virksomhed?

Start din gratis prøveperiode i dag og se resultater inden for få dage.

Nu hvad: stjæl løkken

Hvad vi sendte

Den vindende arm er nu repoets standard check-context-first-færdighed: træk kontekstmotor-digestet (to kald), læs derefter nøjagtigt en fil fra disk — harness-konfigurationen — og udsend en bekræftelsesblok, der citerer øjebliksbilledet og de nøjagtige gates. En målt svaghed, en-linjers politikfix, re-valideret samme dag. Den løkke — mål, ret kontekstpolitikken, re-validér — er den del, vi ville opfordre dig til at stjæle, uanset hvilken kontekstmotor du bruger.

Hvad du kan gøre på mandag

  1. Opdel din agentkontekst i to: prosa (konventioner, arkitektur, test) vs maskinerbar politik (CI-gates, risikotrin, fusionsregler).
  2. Digest prosaen; digest aldrig politikken. Servér prosaen gennem en kontekstmotor — meaninggrid er vores — og gør politikfilen til en obligatorisk bogstavelig læsning i din kontekstgate.
  3. Gør kontekst revidérbar. Versionér den indlæste kontekst; kræv, at agenter citerer snapshot-id’et i en bekræftelsesblok, som anmeldere faktisk kan kontrollere.
  4. Mål før du tror — også os. En håndfuld agenter pr. arm på dit eget repository er nok til at se mønsteret. Score anmeldelserne mod verificerede fund, ikke vibber.

En åben invitation

Hvis du kører dette eksperiment på dit eget repository — samme arme, din model, din harness — ville vi gerne se dine tal, især hvis de modsiger vores. Og hvis dit team ønsker hjælp til at opsætte en kontekstgate som denne, eller ønsker at tale om meaninggrid og harnext-stakken, kontakt FlowHunt-teamet eller find open-source-harness’en på harnext.dev . Replikationer, spørgsmål og rettelser er alle velkomne.

Ofte stillede spørgsmål

Štefan er en AI- og softwareingeniør, der bygger FlowHunt. Ud over selve produktet designer han agentic software-engineering workflows for udviklere, der reducerer udviklingskostnaderne, mens kodekvaliteten forbedres.

Štefan Moravík
Štefan Moravík
AI- og softwareingeniør

Build Agent Workflows That Pay for Themselves

FlowHunt helps engineering teams design agentic workflows, context gates, and MCP integrations that cut development costs while raising code quality.