Vi gav samma kodgranskningsuppgift till 22 AI-agenter. Samma pull request, samma fastnålad commit, samma prompt, samma modell — den enda variabeln var hur varje agent laddade projektets regler. Den billigaste konfigurationen visade sig vara den mest grundliga, och anledningen säger något allmänt om kontextengineering.
TL;DR: En kontextmotorsammanfattning plus en direkt läsning av policyfilen för maskinläsning slog varje annan strategi: $1,56 per granskning och 9,6/13 verifierade fynd — billigare än att läsa dokumentationen ($2,30, 8,6/13) och bättre än endast sammanfattningen ($1,77, 7,8/13). Att läsa allt presterade sämst av alla (7,4/13). Alla 22 agenter körde på Claude Opus 4.8, och 21 av 22 nådde samma slutsats.
Vad: ett testsystem, en kontextmotor och en pull request
Vad är ett “testsystem”?
Varje seriös försök att låta AI-agenter arbeta i ett produktionsarkiv växer två lager av styrning.
Prosaklassificeringsmässiga lagret — konventioner, arkitekturregler, teststandarder. I vårt arkiv det är CLAUDE.md och docs/**: “backend är snake_case,” “domänen importerar aldrig infrastruktur,” “alla väghanterare är asynkrona.” Människor läser det; agenter sägs läsa det också.
Det maskinläsbara lagret — testsystemkonfigurationen. Vår är en enda JSON-fil som klassificerar varje sökväg i arkivet i risknivåer och kopplar tvingande grindar till varje nivå. CI läser det. Sammanslagningstpolicy läser det. Det är inte råd — det är policy:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Terminologisk anmärkning: “testsystem” namnger också själva agentkörmiljön — underlaget av verktyg, färdigheter och MCP-servrar som en agent agerar genom, som i harnext , “kodningsagentens testsystem.” I det här inlägget är testsystemkonfigurationen arkivets policyfil som sådan en körning och CI både tillämpar.)
En kodgransknare — människa eller agent — kan inte bedöma “är denna PR tillåten att slå samman?” utan denna fil. En Tier-3 PR med review-agent-kontrollen överhoppad är en policyöverträdelse även om varje test är grönt. Kom ihåg det här exemplet; det avgör experimentet.
Eftersom båda lagren finns, kräver arkivet en grind: ingen agent startar arbete innan den laddar denna kontext — och bevisar att den gjorde det, via ett bekräftelseblock som granskare kontrollerar. Frågan som det här inlägget besvarar är helt enkelt: vad är det billigaste korrekta sättet att uppfylla denna grind?
Möt harnext och meaninggrid
meaninggrid är den värderade kontextmotorn från harnext
, QualityUnits MIT-licensierade, leverantörsagnostiska kodningsagentesystem (sex verktyg — läs, skriv, redigera, bash, färdighet, mcp — npm i -g harnext). Leverantörens tonfall för kontextmotorn är enkelt: “din agents hjärna.” Källor strömmar in i ett kontinuerligt uppdaterat index — “rutnätet” — och per fråga “rangordnar och beskär motorn det till tokeneffektiv kontext, kopplad direkt till testsystemet”: kontinuerligt index, relevansrangordning, dedup och cache. harnexts huvudnummer är −89% tokens per fråga i genomsnitt. Det är leverantörens påstående; ett syfte med detta experiment var att mäta, med våra egna siffror på en verklig uppgift, vad den här typen av komprimering faktiskt sparar — och vad det kostar.
I vår distribution intar rutnätet arkivets prosadokumentation; varje intagning producerar en oföränderlig, versionerad ögonblicksbild. Agenter frågar den över MCP (meaninggrid.harnext.dev/mcp) med ett enda context_research-anrop och får en syntetiserad, citerad sammanfattning stämplad med snapshot_id, som agenten måste citera i sitt bekräftelseblock — granskningsbar kontext gjord konkret.
Vad grinden producerar — bekräftelseblocket (exempel; projektspecifikationer utelämnade):
Laddad via: optimerad hybrid (kontextmotorsammanfattning + policyfil endast).
- context_research anrop #1 (konventioner / skiktning / testning / säkerhet /
risknivåer) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research anrop #2 (LLM-leverantörsintegrationschecklista +
flödesmotor-extra-varningsregler) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Läs testsystemkonfiguration (full) från disk för exakta nivåmönster,
requiredChecks, mergePolicy, evidenceConfig.
Läste INTE CLAUDE.md eller docs/* (täckt av sammanfattningen).
snapshot_id är verklig — en granskare kan verifiera exakt vilken version av reglerna agenten arbetade från.
Tre hypoteser
Experimentet designades för att lösa tre testbara förutsägelser, skrivna förhand:
H1 — En sammanfattning är billigare än att läsa igen. Inta prosadokumentationen en gång, servera varje agent en kompakt syntetiserad sammanfattning, istället för att varje agent läser varje dokument på varje uppgift. Om sant: meningsfullt lägre kostnad per granskning, vid lika slutsatser.
H2 — Omformulering förstör policy. En sammanfattning kan bära “Tier 3 kräver mänsklig granskning” utan förlust. Den kan inte bära "requireReviewAgent": true utan förlust — de exakta, citerbara detaljerna en granskare behöver för att hävda en överträdelse dör i sammanfattning. Om sant: agenter med endast sammanfattning bör systematiskt missa grindöverträdelser som agenter som håller policyfilen bokstavligt fångar.
H3 — Leanare kontext läser djupare. Kontext betalas för två gånger — en gång i dollar, en gång i uppmärksamhet: varje redundant dokument i fönstret konkurrerar med koden under granskning. Om sant: att läsa allt (sammanfattning + all dokumentation) bör inte vinna; den leanaste tillräckliga kontexten bör.
Hur vi testade det
Tjugotvå agenter granskade samma Tier-3 pull request i vårt produktionsmonarkiv (en LLM-leverantörsintegration: 44 filer, +2 111 rader, verkliga insatser — faktureringsstabeller, flödesmotor-routing). Fem armar, som skiljer sig endast i kontextinladdningssteget:
| Arm | Kontextinladdning | n |
|---|---|---|
| meaninggrid | kontextmotorsammanfattning endast (2× context_research) | 5 |
| disk | läser 7+ dokument från disk — ingen kontextmotor | 5 |
| hybrid | sammanfattning + läser ALL dokumentationen | 5 |
| opt-hybrid | sammanfattning + läser EN fil: testsystemkonfigurationen | 5 |
| cold | ingen konventionskontext alls (baslinje) | 2 |
Grundregler: en fastnålad commit, en prompttext, en modell — Claude Opus 4.8 — alla armar interfolierade i en enda samtidig batch. Agenter förbjöds från PR:ns kommentartråd, så tidigare experimentrundor kunde inte läcka in. Varje siffra kommer från de råa agenttranskriberingar, med tokenanvändning deduplicerad per API-förfrågan och prissatt till listpriser. Kvalitet bedöms mot 13 oberoende verifierade, verkliga defekter i PR:n, mönstermatchade i varje granskningstekst och manuellt granskade för falska positiver. Slutsatsöverenskommelse över alla armar: 21/22 sa REQUEST CHANGES.
Så vad: den billigaste konfigurationen vann också på kvalitet
| Arm | Kostnad / granskning | Fynd (av 13) | Grindsfynd (av 3) | Väggklocka |
|---|---|---|---|---|
| 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 |
★ = konfigurationen vi nu levererar som arkivets standardfärdighet. Väggklocka inkluderar delad innehålltning från att köra 22 agenter samtidigt.
H1 — bekräftad
Sammanfattningen-endast-armen granskade för $1,77 mot $2,30 för att läsa dokumentationen (−23%), och den vinnande sammanfattning-plus-en-fil-armen för $1,56 (−32%) — vid lika slutsatser. Besparingen sammansätts: sammanfattningen ersätter en stack av dokument som annars skulle åka genom varje efterföljande API-anropets kontext.
H2 — bekräftad, avgörande
Den överhoppade review-agent-kontrollen — en verklig sammanslagningstpolicyöverträdelse i denna PR — fångades av 5 av 5 agenter som höll policyfilen bokstavligt, och av 1 av 5 agenter med endast sammanfattning. Mekanismen är exakt vad H2 förutsåg: för att skriva det fyndet måste en agent matcha exakta CI-kontrollnamn mot exakta konfigurationsfält — en omformulering är inte citerbar bevis, så agenter med endast sammanfattning vacklar och sänker det. En direkt läsning återställer det.
H3 — bekräftad
Läs-allt-hybriden bar mest kontext av någon arm och presterade sämst (7,4/13), medan den leanaste tillräckliga armen presterade bäst (9,6/13) — och var bäst av alla armar vid det enda djupaste fyndet, en död-kod-bugg som kräver att spåra en anropsväg över tre filer. Redundant prosa lade inte till information; den konkurrerade med koden om uppmärksamhet.
En ärlig fotnot: baslinjen cold (8,0/13 på $1,64) visar att de flesta av de 13 defekterna är vanliga kodfel som en stark modell hittar utan någon konventionskontext alls. Vad cold inte kan göra är policydelen av jobbet — grindar, nivåer, sammanslagninsregler — vilket är exakt där armarna skiljer sig.
Kurera prosan in i en sammanfattning. Läs policyfilen råt. Läs inte något två gånger.
Fullständig information
- Modell: varje API-anrop för varje agent körde på claude-opus-4-8 (Claude Opus 4.8) — verifierad från
model-fältet i varje transkriberad linje, inte antagen. Resultat kan skilja sig på andra modeller; mindre modeller beror sannolikt mer på kurerad kontext, inte mindre. - Priser: kostnader använder Anthropics listpriser vid tidpunkten för skrivandet; faktisk fakturering kan skilja sig. Relativa jämförelser påverkas inte.
- Urvalsstorlek: n=5 per arm (n=2 för cold), en PR, ett arkiv, en uppgiftstyp. Grindeffekten (5/5 kontra 1/5) är skarp; per-fynd-frekvenser någon annanstans är ±1 agent. Behandla detta som en stark pilot, inte ett riktmärke.
- Kvalitetsmått: mönsterupptäckning över granskningstext (citat uteslutna), manuellt granskad för falska positiver. Det räknar omnämnanden av verifierade defekter, inte övergripande granskningselokveens.
- Tidsinställning: alla 22 agenter delade en maskin och en API-kvot; väggklocksnummer inkluderar denna innehålltning.
- Vi korrigerade oss själva två gånger: initiala tokenantal var uppblåsta 2–3× (per-linjeanvändningsduplicering i transkribieringar; åtgärdat genom förfrågan-ID-dedup), och en tidigare tidslinjegrafik underkalkylerade väggtid (åtgärdat genom fullständig intervallattribution). Båda korrigeringarna är inbakade i varje siffra här.
Nu vad: stjäl loopen
Vad vi levererade
Den vinnande armen är nu arkivets standardfärdighet check-context-first: dra kontextmotorsammanfattningen (två anrop), läs sedan exakt en fil från disk — testsystemkonfigurationen — och avge ett bekräftelseblock som citerar ögonblicksbilden och de exakta grindarna. En uppmätt svaghet, en enrads-policyfix, åtvaliderades samma dag. Den loopen — mäta, fixa kontextpolicyn, åtvalidera — är den delen vi skulle uppmuntra dig att stjäla, oavsett vilken kontextmotor du använder.
Vad du kan göra på måndag
- Dela din agentkontext i två: prosa (konventioner, arkitektur, testning) kontra maskinläsbar policy (CI-grindar, risknivåer, sammanslagninsregler).
- Sammanfatta prosan; sammanfatta aldrig policyn. Servera prosan genom en kontextmotor — meaninggrid är vår — och gör policyfilen en obligatorisk ordagrann läsning i din kontextgrind.
- Gör kontext granskningsbar. Versionera den intagna kontexten; kräv att agenter citerar ögonblicksbildens id i ett bekräftelseblock som granskare faktiskt kan kontrollera.
- Mäta innan du tror — inklusive oss. En handfull agenter per arm på ditt eget arkiv räcker för att se mönstret. Poäng granskningen mot verifierade fynd, inte vibbar.
En öppen inbjudan
Om du kör detta experiment på ditt eget arkiv — samma armar, din modell, ditt testsystem — skulle vi verkligen vilja se dina siffror, särskilt om de motsäger våra. Och om ditt team vill ha hjälp med att ställa in en kontextgrind som denna, eller vill prata om meaninggrid och harnext-stacken, kontakta FlowHunt-teamet eller hitta det öppen källkodsbaserade testsystemet på harnext.dev . Replikationer, frågor och rättelser är alla välkomna.

