Co vám Context Engine skutečně přináší: Spustili jsme 22 AI Code Reviewery pěti různými způsoby

Dali jsme stejný úkol code review 22 AI agentům. Stejný pull request, stejný připnutý commit, stejný prompt, stejný model — jedinou proměnnou bylo jak každý agent načítal pravidla projektu. Nejlevnější konfigurace se ukázala být nejdůkladnější a důvod proč to říká něco obecného o context engineeringu.

TL;DR: Digest z context engine plus jedno přímé čtení souboru s machine-readable politikou porazilo každou jinou strategii: 1,56 USD za review a 9,6/13 ověřených zjištění — levnější než čtení dokumentace (2,30 USD, 8,6/13) a lepší než samotný digest (1,77 USD, 7,8/13). Čtení všeho dosáhlo nejhoršího výsledku ze všech (7,4/13). Všichni 22 agenti běželi na Claude Opus 4.8 a 21 z 22 dosáhlo stejného verdiktu.

Co: harness, context engine a jeden pull request

Co je “harness”?

Každý vážný pokus nechat AI agenty pracovat v produkčním úložišti vytváří dvě vrstvy správy.

Prose vrstva — konvence, architektonická pravidla, standardy testování. V našem úložišti je to CLAUDE.md a docs/**: “backend je snake_case,” “domain nikdy neimportuje infrastructure,” “všechny route handlery jsou async.” Lidé to čtou; agentům se říká, aby to také četli.

Machine-readable vrstva — harness config. Náš je jediný JSON soubor, který klasifikuje každou cestu v úložišti do tříd rizika a připojuje vynucovatelné brány ke každé třídě. CI jej čte. Merge politika jej čte. Nejde o radu — jde o politiku:

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

(Poznámka k terminologii: “harness” také pojmenovává samotný agent runtime — lešení nástrojů, dovedností a MCP serverů, kterými agent jedná, jako v harnext , “coding agent harness.” V tomto příspěvku je harness config soubor politiky úložiště, který takový runtime a CI oba vynucují.)

Recenzent kódu — člověk nebo agent — nemůže posoudit “je povoleno tomuto PR sloučit se?” bez tohoto souboru. PR třídy Tier-3 s přeskočenou kontrolou review-agent je porušení politiky i když je každý test zelený. Pamatujte si tento příklad; rozhoduje experiment.

Protože obě vrstvy existují, úložiště stanovuje bránu: žádný agent nezačne pracovat, dokud nenačte tento kontext — a neprokáže to prostřednictvím potvrzovacího bloku, který recenzenti kontrolují. Otázka, na kterou tento příspěvek odpovídá, je jednoduše: jaký je nejlevnější správný způsob, jak splnit tuto bránu?

Poznámka s harnext a meaninggrid

meaninggrid je hostovaný Context Engine od harnext , MIT-licencovaného, vendor-agnostického coding-agent harness od QualityUnit (šest nástrojů — read, write, edit, bash, skill, mcp — npm i -g harnext). Pitch vendora pro Context Engine je přímý: “mozek vašeho agenta.” Zdroje se streamují do průběžně aktualizovaného indexu — “grid” — a na dotaz engine “jej řadí a ořezává do token-efektivního kontextu, připojeného přímo do harness”: průběžný index, relevance ranking, deduplikace a cache. Hlavní číslo harnext je −89% tokenů na dotaz v průměru. To je tvrzení vendora; jedním účelem tohoto experimentu bylo měřit s našimi vlastními čísly na skutečném úkolu, co taková komprese skutečně ušetří — a co ji stojí.

V našem nasazení grid inguje prose dokumentaci úložiště; každý ingest vytváří neměnný, verzovaný snímek. Agenti jej dotazují přes MCP (meaninggrid.harnext.dev/mcp) s jediným voláním context_research a obdrží syntetizovaný, citovaný digest označený snapshot_id, který agent musí citovat v jeho potvrzovacím bloku — ověřitelný kontext učiněný konkrétním.

Co brána vytváří — potvrzovací blok (příklad; projektové specifika vynechána):

Načteno prostřednictvím: 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 je skutečný — recenzent může ověřit přesně, jakou verzi pravidel agent používal.

Tři hypotézy

Experiment byl navržen tak, aby vyřešil tři testovatelné předpovědi, napsané dopředu:

H1 — Digest je levnější než opětovné čtení. Ingujte prose docs jednou, podávejte každému agentovi kompaktní syntetizovaný digest, místo aby každý agent znovu četl každý dokument při každém úkolu. Pokud je pravda: smysluplně nižší náklady na review, při stejných verdiktech.

H2 — Parafrází se ničí politika. Digest může přenést “Tier 3 vyžaduje lidskou kontrolu” bez ztráty. Nemůže přenést "requireReviewAgent": true bez ztráty — přesné, citovatelné detaily, které recenzent potřebuje k tvrzení porušení, umírají v souhrnu. Pokud je pravda: agenti pouze s digestem by měli systematicky propouštět porušení brány, která agenti držící doslova soubor s politikou zachytí.

H3 — Štíhlejší kontext čte hlouběji. Kontext se platí dvakrát — jednou v dolarech, jednou v pozornosti: každý redundantní dokument v okně soutěží s kódem pod kontrolou. Pokud je pravda: čtení všeho (digest + všechny docs) by nemělo zvítězit; nejštíhlejší dostatečný kontext by měl.

Jak jsme to testovali

Dvacet dva agenti kontrolovali stejný pull request třídy Tier-3 v našem produkčním monorepu (LLM-provider integrace: 44 souborů, +2 111 řádků, skutečné sázky — tabulky fakturace, flow-engine routing). Pět arms, lišících se pouze v kroku načítání kontextu:

Základní pravidla: jeden připnutý commit, jedno tělo promptu, jeden model — Claude Opus 4.8 — všechny arms prokládané v jediné souběžné dávce. Agenti byli vyloučeni z vlákna komentářů PR, takže dřívější kola experimentů nemohla unést. Každé číslo pochází z surových přepisů agentů, s deduplicírovaným použitím tokenů na API žádost a oceňováno seznamovými cenami. Kvalita je skórována proti 13 nezávisle ověřeným, skutečným chybám v PR, pattern-matchovaným v těle každé kontroly a ručně auditovaným na falešné pozitivy. Shoda verdiktu ve všech arms: 21/22 řeklo REQUEST CHANGES.

Takže co: nejlevnější konfigurace také zvítězila v kvalitě

★ = konfigurace, kterou nyní dodáváme jako výchozí skill úložiště. Wall clock zahrnuje sdílené konflikty z běhu 22 agentů souběžně.

H1 — potvrzena

Arm pouze s digestem kontroloval za 1,77 USD vs 2,30 USD za čtení dokumentů (−23%), a vítězný arm digest-plus-jeden-soubor za 1,56 USD (−32%) — při stejných verdiktech. Úspora se skládá: digest nahrazuje zásobník dokumentů, které by jinak projely každým následujícím voláním API v kontextu.

H2 — potvrzena, rozhodujícím způsobem

Přeskočená kontrola review-agent — skutečné porušení merge-policy v tomto PR — byla zachycena 5 z 5 agenty držícími doslova soubor s politikou a 1 z 5 agenty pouze s digestem. Mechanismus je přesně to, co H2 předpokládala: aby agent napsal toto zjištění, musí porovnat přesné názvy CI kontrol proti přesným polím config — parafrází není citovatelný důkaz, takže agenti pouze s digestem váhají a vynechávají jej. Jedno přímé čtení jej obnoví.

H3 — potvrzena

Hybrid s čtením všeho nesl nejvíce kontextu ze všech arms a dosáhl nejhoršího výsledku (7.4/13), zatímco nejštíhlejší dostatečný arm dosáhl nejlepšího (9.6/13) — a byl nejlepší ze všech arms v jediném nejhlubším zjištění, bug mrtvého kódu, který vyžaduje trasování call path přes tři soubory. Redundantní próza nepřidala informace; soutěžila s kódem o pozornost.

Jedna poctivá poznámka pod čarou: baseline cold (8.0/13 za 1,64 USD) ukazuje, že většina z 13 chyb jsou prosté code bugs, které silný model najde bez jakéhokoli konvence kontextu. Co cold nemůže dělat, je politická polovina úkolu — brány, třídy, merge pravidla — což je přesně místo, kde se arms oddělují.

Kurujte prose do digestu. Čtěte soubor s politikou surový. Nečtěte nic dvakrát.

Úplné zveřejnění

• Model: každé API volání každého agenta běželo na claude-opus-4-8 (Claude Opus 4.8) — ověřeno z pole model každého řádku přepisu, ne předpokládáno. Výsledky se mohou lišit na jiných modelech; menší modely pravděpodobně více závisí *na kurátorském kontextu, ne méně.
• Ceny: náklady používají Anthropic list prices v době psaní; skutečná fakturace se může lišit. Relativní srovnání nejsou ovlivněna.
• Velikost vzorku: n=5 na arm (n=2 pro cold), jeden PR, jedno úložiště, jeden typ úkolu. Efekt brány (5/5 vs 1/5) je ostrý; sazby na zjištění jinde jsou ±1 agent. Považujte to za silný pilotní projekt, ne benchmark.
• Metrika kvality: pattern detection přes review text (citace vyloučeny), ručně auditováno na falešné pozitivy. Počítá zmínky ověřených chyb, ne celkovou eloquenci review.
• Časování: všichni 22 agenti sdíleli jeden stroj a jednu API kvótu; wall-clock čísla zahrnují tuto soutěž.
• Opravili jsme se dvakrát: počáteční počty tokenů byly nafouklé 2–3× (per-line usage duplikace v přepisech; opraveno deduplicí request-ID) a starší timeline visual undercounted wall time (opraveno úplnou intervalovou atribucí). Obě opravy jsou zapečeny do každého čísla zde.

Připraveni rozšířit své podnikání?

Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.

Požádat o demo Přihlásit se

Teď co: ukradněte smyčku

Co jsme dodali

Vítězný arm je nyní výchozí check-context-first skill úložiště: vytáhněte digest z context engine (dvě volání), pak přečtěte přesně jeden soubor z disku — harness config — a vyzařujte potvrzovací blok citující snapshot a přesné brány. Jedna měřená slabost, jedna jednolineková politika fix, re-validována stejný den. Ta smyčka — měřit, opravit context politiku, re-validovat — je část, kterou bychom vás povzbuzovali okrást, bez ohledu na to, jaký context engine používáte.

Co můžete dělat v pondělí

1. Rozdělte kontext vašeho agenta na dva: próza (konvence, architektura, testování) vs machine-readable politika (CI brány, třídy rizika, merge pravidla).
2. Kurujte prózu; nikdy nedigitujte politiku. Podávejte prózu prostřednictvím context engine — meaninggrid je náš — a udělejte soubor s politikou povinným doslova čtením v bráně vašeho kontextu.
3. Udělejte kontext auditovatelným. Verzujte ingestovaný kontext; vyžadujte, aby agenti citovali snapshot id v potvrzovacím bloku, který mohou recenzenti skutečně zkontrolovat.
4. Měřte, než věříte — včetně nás. Hrstka agentů na arm ve vašem vlastním úložišti je dost na to, aby viděla vzor. Skórujte reviews proti ověřeným zjištěním, ne vibům.

Otevřená pozvánka

Pokud spustíte tento experiment ve vašem vlastním úložišti — stejné arms, váš model, váš harness — opravdu bychom rádi viděli vaše čísla, zvláště pokud naše vyvrací. A pokud váš tým chce pomoc s nastavením context gate jako tohoto, nebo chce mluvit o meaninggrid a harnext stacku, kontaktujte tým FlowHunt nebo najděte open-source harness na harnext.dev . Replikace, otázky a opravy jsou vítány.