Annoimme saman koodintarkastus-tehtävän 22 AI-agentille. Sama pull request, sama kiinnitetty commit, sama kehote, sama malli — ainoa muuttuja oli kuinka jokainen agentti latasi projektin säännöt. Halvin konfiguraatio osoittautui myös perusteellisimmaksi, ja syy siihen kertoo jotain yleistä kontekstien suunnittelusta.
TL;DR: Kontekstimoottorin yhteenveto plus yksi koneluettavan politiikkatiedoston suora lukeminen voitti jokaisen muun strategian: 1,56 $ per tarkastus ja 9,6/13 vahvistettua löydöstä — halvempi kuin dokumentaation lukeminen (2,30 $, 8,6/13) ja parempi kuin pelkkä yhteenveto (1,77 $, 7,8/13). Kaiken lukeminen sai huonoimmat pisteet (7,4/13). Kaikki 22 agenttia käyttivät Claude Opus 4.8:aa, ja 21 22:sta päätyivät samaan johtopäätökseen.
Mitä: harness, kontekstimoottorin ja yksi pull request
Mikä on “harness”?
Jokainen vakava yritys antaa AI-agentteille mahdollisuus työskennellä tuotanto-repositoriossa kasvattaa kahta hallintatasoa.
Proosakerros — käytännöt, arkkitehtuuri säännöt, testausstandardit. Repositoriomme CLAUDE.md ja docs/**: “backend on snake_case”, “domain ei koskaan tuo infrastruktuuria”, “kaikki reitintarkastajat ovat async”. Ihmiset lukevat sitä; agenteilta pyydetään lukemaan se myös.
Koneluettava kerros — harness-konfiguraatio. Omamme on yksittäinen JSON-tiedosto, joka luokittelee jokaisen polun repositoriossa riskitasoihin ja liittää täytäntöönpanokelpoiset portit jokaiselle tasolle. CI lukee sen. Merge-politiikka lukee sen. Se ei ole neuvoja — se on politiikka:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Terminologian huomautus: “harness” nimeää myös agentin runtime-ympäristön — työkaluja, taitoja ja MCP-palvelimia sisältävän rungon, jonka kautta agentti toimii, kuten harnext , “koodausagentin harness”. Tässä viestissä harness-konfiguraatio on repositorion politiikkatiedosto, jonka sekä tällainen runtime että CI täytäntöönpanee.)
Koodintarkastaja — ihminen tai agentti — ei voi arvioida “sallitaanko tämän PR:n yhdistäminen?” ilman tätä tiedostoa. Tier-3 PR, jonka review-agent tarkistus on ohitettu, on politiikan rikkominen vaikka jokainen testi olisi vihreä. Pidä tämä esimerkki mielessä; se ratkaisee kokeen.
Koska molemmat kerrokset ovat olemassa, repository määrää portin: mikään agentti ei aloita työtä ennen kuin lataa tämän kontekstin — ja todistaa sen tekemisen vahvistusblokilla, jonka tarkastajat tarkistavat. Kysymys, johon tämä viesti vastaa, on yksinkertaisesti: mikä on halvin oikea tapa täyttää tämä portti?
Tapaa harnext ja meaninggrid
meaninggrid on harnestin
isännöity kontekstimoottorin, QualityUnitin MIT-lisensoitu, palveluntarjoaja-agnostinen koodausagentin harness (kuusi työkalua — read, write, edit, bash, skill, mcp — npm i -g harnext). Myyjän pitch kontekstimoottorin puolesta on suora: “agentin aivot.” Lähteet virtaavat jatkuvasti päivittyneeseen indeksiin — “verkkoon” — ja per kysely moottori “järjestää ja karsii sen token-tehokkaaksi kontekstiksi, kytketty suoraan harnessin”: jatkuva indeksi, relevanssiarviointi, poistaminen ja välimuisti. harnessin otsikkonumero on −89% tokenia per kysely keskimäärin. Se on myyjän väite; yksi tämän kokeen tarkoitus oli mitata omilla numeroillaan todellisella tehtävällä, mitä tällainen pakkaaminen todella säästää — ja mitä se maksaa.
Omassa käyttöönottossamme verkko ottaa repositorion proosadokumentaation vastaan; jokainen ottaminen tuottaa muuttumattoman, versioitavan tilannekuvan. Agentit kyselevät sitä MCP:n kautta (meaninggrid.harnext.dev/mcp) yhdellä context_research kutsulla ja saavat syntetisoidun, lähdeviitteillä varustetun yhteenvedon, joka on leimattu snapshot_id:llä, jonka agentti on sitouduttava mainitsemaan vahvistusblokissaan — tarkastettava konteksti konkreettiseksi.
Mitä portti tuottaa — vahvistusblokki (esimerkki; projektin yksityiskohdat poistettu):
Ladattu: optimoitu hybridi (kontekstimoottorin yhteenveto + politiikkatiedosto vain).
- context_research kutsu #1 (käytännöt / kerrostaminen / testaus / turvallisuus /
riskitasot) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research kutsu #2 (LLM-palveluntarjoajan integraation tarkistuslista +
flow-engine extra-care säännöt) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Lue harness-konfiguraatio (täysi) levyltä tarkoille taso-malleille,
requiredChecks, mergePolicy, evidenceConfig.
EI luettu CLAUDE.md tai docs/* (katettu yhteenveto).
snapshot_id on oikea — tarkastaja voi varmistaa tarkalleen, mitä version sääntöjä agentti käytti.
Kolme hypoteesia
Koe suunniteltiin kolmen testattavan ennusteen ratkaisemiseksi, jotka kirjoitettiin etukäteen:
H1 — Yhteenveto on halvempi kuin uudelleenlukeminen. Ota proosadokumentaatio vastaan kerran, tarjoa jokaiselle agentille kompakti syntetisoidun yhteenveto, sen sijaan että jokainen agentti lukisi jokaisen dokumentin uudelleen jokaisella tehtävällä. Jos totta: merkittävästi alhaisemmat kustannukset tarkastusta kohden, yhtä suurilla tuomioilla.
H2 — Parafraasi tuhoaa politiikan. Yhteenveto voi välittää “Tier 3 vaatii ihmisen tarkistuksen” ilman menetystä. Se ei voi välittää "requireReviewAgent": true ilman menetystä — tarkat, lainattavat yksityiskohdat, joita tarkastaja tarvitsee politiikan rikkomuksen väittämiseen, kuolevat yhteenveto-muodossa. Jos totta: pelkkä yhteenveto-agentit pitäisi systemaattisesti missata portin rikkomukset, jotka agentit, joilla on kirjaimellinen politiikkatiedosto, havaitsevat.
H3 — Leanempi konteksti lukee syvemmälle. Konteksti maksetaan kahdesti — kerran dollareissa, kerran huomiossa: jokainen redundantti dokumentti ikkunassa kilpailee tarkastettavan koodin kanssa. Jos totta: kaiken lukeminen (yhteenveto + kaikki dokumentit) ei tulisi voittaa; leanein riittävä konteksti tulisi.
Kuinka testasimme sitä
Kaksikymmentäkaksi agenttia tarkasti saman Tier-3 pull requestin omassa tuotanto-monorepossa (LLM-palveluntarjoajan integraatio: 44 tiedostoa, +2 111 riviä, todelliset panokset — laskutustaulukot, flow-engine-reititys). Viisi varsinta, jotka eroavat vain kontekstin lataamisen vaiheessa:
| Varsi | Kontekstin lataaminen | n |
|---|---|---|
| meaninggrid | kontekstimoottorin yhteenveto vain (2× context_research) | 5 |
| disk | lukee 7+ dokumenttia levyltä — ei kontekstimoottoria | 5 |
| hybrid | yhteenveto + lukee KAIKKI dokumentit | 5 |
| opt-hybrid | yhteenveto + lukee YHDEN tiedoston: harness-konfiguraation | 5 |
| cold | ei konventio-kontekstia lainkaan (perusviiva) | 2 |
Perussäännöt: yksi kiinnitetty commit, yksi kehote, yksi malli — Claude Opus 4.8 — kaikki varret lomitettuna yhdessä samanaikaisessa erässä. Agentit estettiin PR:n kommenttiketjusta, jotta aikaisemmat koekierrokset eivät vuotaisi. Jokainen luku tulee raakasta agentin äänityksestä, token-käyttö deduplikoitu API-pyynnöstä kohden ja hinnoiteltu listahintaan. Laatu pisteytettiin 13 itsenäisesti varmistetun, todellisen vian perusteella, kuvio-vastaavaksi jokaisessa tarkastuksen rungossa ja manuaalisesti tarkastettu väärille positiivisille. Tuomio-sopimus kaikissa varissa: 21/22 sanoi PYYDÄ MUUTOKSIA.
Joten mitä: halvin konfiguraatio voitti myös laadusta
| Varsi | Kustannus / tarkastus | Löydökset (13:sta) | Portin löydökset (3:sta) | Seinäkello |
|---|---|---|---|---|
| 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 |
★ = konfiguraatio, jota nyt toimitetaan repositorion oletustaidoksi. Seinäkello sisältää jaetun kilpailun 22 agentin rinnakkaisesta ajosta.
H1 — vahvistettu
Pelkkä yhteenveto-varsi tarkasti hinnalla 1,77 $ vs 2,30 $ dokumentaation lukemisesta (−23%), ja voittava yhteenveto-plus-yksi-tiedosto varsi hinnalla 1,56 $ (−32%) — samansuuruisilla tuomioilla. Säästö yhdistää: yhteenveto korvaa dokumenttipinojan, joka muuten kulkisi jokaisen seuraavan API-kutsun kontekstin kautta.
H2 — vahvistettu, ratkaisevasti
Ohitettu review-agent tarkistus — todellinen merge-politiikan rikkominen tässä PR:ssä — havaittiin 5 5:stä agentista, joilla oli kirjaimellinen politiikkatiedosto, ja 1 5:stä pelkkä yhteenveto-agentista. Mekanismi on täsmälleen sitä, mitä H2 ennusti: kirjoittaakseen tämän löydöksen, agentti on vastaavaksi tarkat CI-tarkistusnimet tarkoille konfiguraation kentille — parafraasi ei ole lainattava todiste, joten pelkkä yhteenveto-agentit varovaisesti pudottavat sen. Yksi suora lukeminen palauttaa sen.
H3 — vahvistettu
Lue-kaikki hybrid kantoi eniten kontekstia kaikista varista ja sai huonoimmat pisteet (7,4/13), kun taas leanein riittävä varsi sai parhaat (9,6/13) — ja oli paras kaikista varista yksittäisessä syvimmässä löydöksessä, kuolleet-koodi-viassa, joka vaatii puhelun polun jäljittämisen kolmen tiedoston yli. Redundantti proosa ei lisännyt tietoa; se kilpaili koodin kanssa huomiosta.
Yksi rehellinen alaviite: kylmä perusviiva (8,0/13 hinnalla 1,64 $) osoittaa, että suurin osa 13 viasta on tavallisia koodavioja, jotka vahva malli löytää ilman konventio-kontekstia. Mitä kylmä ei voi tehdä, on politiikan puoli työstä — portit, tasot, merge-säännöt — joka on täsmälleen se paikka, jossa varret erottuvat.
Kuratoitunut proosa yhteenveto-muotoon. Lue politiikkatiedosto raakamuodossa. Älä lue mitään kahdesti.
Täysi paljastaminen
- Malli: jokainen API-kutsu jokaisesta agentista käytti claude-opus-4-8:aa (Claude Opus 4.8) — varmistettu kunkin äänityslähteen mallikentästä, ei oletettu. Tulokset saattavat poiketa muissa malleissa; pienemmät mallit luultavasti riippuvat enemmän kuratoidusta kontekstista, ei vähemmän.
- Hinnat: kustannukset käyttävät Anthropicin listahintoja kirjoitushetkellä; todellinen laskutus saattaa poiketa. Suhteelliset vertailut eivät vaikutu.
- Näytteen koko: n=5 per varsi (n=2 kylmälle), yksi PR, yksi repository, yksi tehtävätyyppi. Portin vaikutus (5/5 vs 1/5) on terävä; per-löydös-hinnat muualla ovat ±1 agentti. Pidä tätä vahvana pilottina, ei vertailuarvona.
- Laadun mittari: kuvion havaitseminen tarkastustekstissä (lainaukset poissuljettuina), manuaalisesti tarkastettu väärille positiivisille. Se laskee mainitut vahvistetut viat, ei kokonaisuudessaan tarkastuksen kauneus.
- Ajoitus: kaikki 22 agenttia jakoivat yhden koneen ja yhden API-kiintiön; seinäkello-numerot sisältävät sen kilpailun.
- Korjasimme itsemme kahdesti: alkuperäiset token-määrät olivat paisutettu 2–3× (per-rivi-käyttö-duplikointi äänityksessä; korjattu pyynnön ID-deduplikoinnilla), ja aikaisempi aikajanan visuaalinen alilaskutettava seinä-aika (korjattu täydellä väli-attribuoinnilla). Molemmat korjaukset on sisällytetty jokaiseen numeroon tässä.
Nyt mitä: varastoi silmukka
Mitä toimituimme
Voittava varsi on nyt repositorion oletusksi check-context-first taito: vedä kontekstimoottorin yhteenveto (kaksi kutsua), sitten lue täsmälleen yksi tiedosto levyltä — harness-konfiguraatio — ja lähetä vahvistusblokki, joka lainaa tilannekuvan ja tarkat portit. Yksi mitattu heikkous, yksi yhden rivin politiikan korjaus, uudelleenvalidoitu samana päivänä. Tämä silmukka — mittaa, korjaa konteksti-politiikka, uudelleenvalidoi — on osa, jonka haluamme sinun varastavan, riippumatta siitä, mitä kontekstimoottoria käytät.
Mitä voit tehdä maanantaina
- Jaa agentin konteksti kahteen: proosa (käytännöt, arkkitehtuuri, testaus) vs koneluettava politiikka (CI-portit, riskitasot, merge-säännöt).
- Tee yhteenveto proosasta; älä koskaan tee yhteenveto politiikasta. Tarjoa proosa kontekstimoottorin kautta — meaninggrid on omamme — ja tee politiikkatiedosto pakolliseksi kirjaimelliseksi luennaksi konteksti-portissasi.
- Tee konteksti tarkastettavaksi. Versio otettu konteksti; vaadi agenteilta lainata snapshot-tunnusta vahvistusblokissa, jonka tarkastajat voivat todella tarkistaa.
- Mittaa ennen kuin uskot — myös meihin. Kourallinen agentteja per varsi omassa repositoryssasi riittää näkemään kuvio. Piste tarkastukset vahvistettuja löydöksiä vastaan, ei tuntemuksia.
Avoin kutsu
Jos ajat tämän kokeen omassa repositoryssasi — samat varret, sinun malli, sinun harness — haluaisimme todella nähdä numerosi, erityisesti jos ne kumoavat omamme. Ja jos tiimisi haluaa apua tällaisen konteksti-portin asettamiseen, tai haluaa puhua meaninggridistä ja harnext-pinosta, ota yhteyttä FlowHunt-tiimiin tai etsi avoin lähde harness osoitteesta harnext.dev . Replikaatiot, kysymykset ja korjaukset tervetulleita.

