Nous avons donné la même tâche de révision de code à 22 agents IA. Même pull request, même commit épinglé, même invite, même modèle — la seule variable était comment chaque agent chargeait les règles du projet. La configuration la moins chère s’est avérée être la plus approfondie, et la raison pour laquelle cela dit quelque chose de général sur l’ingénierie du contexte.
TL;DR : Un digest du moteur de contexte plus une seule lecture directe du fichier de politique lisible par machine a surpassé chaque autre stratégie : 1,56 $ par révision et 9,6/13 découvertes vérifiées — moins cher que de lire la documentation (2,30 $, 8,6/13) et mieux que le digest seul (1,77 $, 7,8/13). Lire tout a obtenu le pire score de tous (7,4/13). Les 22 agents ont fonctionné sur Claude Opus 4.8, et 21 sur 22 ont atteint le même verdict.
Quoi : un harness, un moteur de contexte et une pull request
Qu’est-ce qu’un « harness » ?
Chaque tentative sérieuse de laisser les agents IA travailler dans un référentiel de production développe deux couches de gouvernance.
La couche prose — conventions, règles d’architecture, normes de test. Dans notre référentiel, c’est CLAUDE.md et docs/** : « le backend est snake_case », « le domaine n’importe jamais l’infrastructure », « tous les gestionnaires de routes sont async ». Les humains la lisent ; les agents sont invités à la lire aussi.
La couche lisible par machine — la configuration du harness. La nôtre est un seul fichier JSON qui classe chaque chemin du référentiel en niveaux de risque et attache des portails applicables à chaque niveau. CI la lit. La politique de fusion la lit. Ce n’est pas un conseil — c’est une politique :
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Note terminologique : « harness » nomme également le runtime de l’agent lui-même — l’échafaudage des outils, des compétences et des serveurs MCP qu’un agent agit par, comme dans harnext , « le harness de l’agent de codage ». Dans cet article, la configuration du harness est le fichier de politique du référentiel que tel un runtime et le CI appliquent.)
Un examinateur de code — humain ou agent — ne peut pas juger « cette PR est-elle autorisée à fusionner ? » sans ce fichier. Une PR de niveau 3 avec la vérification review-agent ignorée est une violation de politique même si chaque test est vert. Gardez cet exemple en tête ; il décide l’expérience.
Parce que les deux couches existent, le référentiel mandate un portail : aucun agent ne commence le travail avant de charger ce contexte — et le prouver, via un bloc de confirmation que les examinateurs vérifient. La question que cet article répond est simplement : quel est le moyen le moins cher correct de satisfaire ce portail ?
Rencontrez harnext et meaninggrid
meaninggrid est le moteur de contexte hébergé de harnext
, le harness de l’agent de codage agnostique du fournisseur sous licence MIT de QualityUnit (six outils — read, write, edit, bash, skill, mcp — npm i -g harnext). Le discours du vendeur pour le moteur de contexte est brutal : « le cerveau de votre agent ». Les sources s’écoulent dans un index continuellement mis à jour — « la grille » — et par requête le moteur « la classe et l’élagage en contexte efficace en tokens, câblé directement dans le harness » : index continu, classement par pertinence, dédup et cache. Le numéro principal de harnext est −89 % tokens par requête en moyenne. C’est la revendication du vendeur ; un objectif de cette expérience était de mesurer, avec nos propres chiffres sur une tâche réelle, ce que ce type de compression économise réellement — et ce qu’il coûte.
Dans notre déploiement, la grille ingère la documentation en prose du référentiel ; chaque ingestion produit un snapshot immuable et versionné. Les agents le demandent via MCP (meaninggrid.harnext.dev/mcp) avec un seul appel context_research et reçoivent un digest synthétisé, cité estampillé avec le snapshot_id, que l’agent doit citer dans son bloc de confirmation — contexte auditable rendu concret.
Ce que le portail produit — le bloc de confirmation (exemple ; spécificités du projet élucidées) :
Chargé via : hybride optimisé (digest du moteur de contexte + fichier de politique uniquement).
- appel context_research #1 (conventions / layering / tests / sécurité /
niveaux de risque) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- appel context_research #2 (checklist d'intégration du fournisseur LLM +
règles d'extra-care du flow-engine) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Lire la configuration du harness (complète) depuis le disque pour les motifs exacts des niveaux,
requiredChecks, mergePolicy, evidenceConfig.
N'a PAS lu CLAUDE.md ou docs/* (couvert par le digest).
Le snapshot_id est réel — un examinateur peut vérifier exactement quelle version des règles l’agent a utilisée.
Trois hypothèses
L’expérience a été conçue pour régler trois prédictions testables, écrites d’avance :
H1 — Un digest est moins cher que de relire. Ingérez les docs en prose une seule fois, servez chaque agent un digest synthétisé compact, au lieu que chaque agent relise chaque document à chaque tâche. Si vrai : coût par révision significativement plus bas, avec des verdicts égaux.
H2 — La paraphrase détruit la politique. Un digest peut transporter « Tier 3 nécessite un examen humain » sans perte. Il ne peut pas transporter "requireReviewAgent": true sans perte — les spécificités exactes et citables qu’un examinateur doit affirmer une violation meurent dans le résumé. Si vrai : les agents utilisant uniquement le digest devraient systématiquement manquer les violations de portail que les agents détenant le fichier de politique littéral attrapent.
H3 — Un contexte plus maigre lit plus profondément. Le contexte est payé deux fois — une fois en dollars, une fois en attention : chaque document redondant dans la fenêtre entre en concurrence avec le code examiné. Si vrai : lire tout (digest + tous les docs) ne devrait pas gagner ; la configuration la plus maigre mais suffisante devrait.
Comment nous l’avons testé
Vingt-deux agents ont examiné la même pull request de niveau 3 dans notre monorepo de production (une intégration de fournisseur LLM : 44 fichiers, +2 111 lignes, enjeux réels — tableaux de facturation, routage du flow-engine). Cinq bras, différant uniquement dans l’étape de chargement du contexte :
| Bras | Chargement du contexte | n |
|---|---|---|
| meaninggrid | digest du moteur de contexte uniquement (2× context_research) | 5 |
| disk | lit 7+ docs depuis le disque — pas de moteur de contexte | 5 |
| hybrid | digest + lit TOUS les docs | 5 |
| opt-hybrid | digest + lit UN seul fichier : la configuration du harness | 5 |
| cold | pas de contexte de convention du tout (baseline) | 2 |
Règles de base : un commit épinglé, un corps d’invite, un modèle — Claude Opus 4.8 — tous les bras entrelacés dans un seul lot concurrent. Les agents ont été empêchés du fil de commentaires de la PR, afin que les tours d’expérience antérieurs ne puissent pas s’échapper. Chaque nombre provient des transcriptions brutes de l’agent, avec l’utilisation de tokens dédupliquée par requête API et tarifée aux prix de liste. La qualité est notée par rapport à 13 défauts réels indépendamment vérifiés dans la PR, correspondant aux motifs dans le corps de chaque révision et auditée manuellement pour les faux positifs. Accord de verdict dans tous les bras : 21/22 a dit REQUEST CHANGES.
Donc quoi : la configuration la moins chère a également gagné en qualité
| Bras | Coût / révision | Découvertes (sur 13) | Découvertes de portail (sur 3) | Temps d’horloge murale |
|---|---|---|---|---|
| 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 |
★ = la configuration que nous livrons maintenant comme compétence par défaut du référentiel. Le temps d’horloge murale inclut la contention partagée de l’exécution de 22 agents simultanément.
H1 — confirmée
Le bras utilisant uniquement le digest a examiné pour 1,77 $ contre 2,30 $ pour lire les docs (−23 %), et le bras gagnant digest-plus-un-fichier pour 1,56 $ (−32 %) — avec des verdicts égaux. L’économie se compose : le digest remplace une pile de documents qui autrement chevaucherait chaque appel API ultérieur du contexte.
H2 — confirmée, décisivement
La vérification review-agent ignorée — une violation réelle de politique de fusion dans cette PR — a été attrapée par 5 sur 5 agents détenant le fichier de politique littéral, et par 1 sur 5 agents utilisant uniquement le digest. Le mécanisme est exactement ce que H2 a prédit : pour écrire cette découverte, un agent doit faire correspondre les noms exacts des vérifications CI avec les champs de configuration exacts — une paraphrase n’est pas une preuve citables, donc les agents utilisant uniquement le digest hésitent et la laissent tomber. Une seule lecture directe la restaure.
H3 — confirmée
Le hybrid read-everything portait le plus de contexte de tous les bras et a obtenu le pire score (7,4/13), tandis que le bras le plus maigre mais suffisant a obtenu le meilleur (9,6/13) — et était le meilleur de tous les bras sur la découverte la plus profonde unique, un bug de code mort qui nécessite de tracer un chemin d’appel sur trois fichiers. La prose redondante n’a pas ajouté d’information ; elle a concurrencé le code pour l’attention.
Une note de pied honnête : la baseline froide (8,0/13 à 1,64 $) montre que la plupart des 13 défauts sont des bugs de code simples qu’un modèle fort trouve sans aucun contexte de convention. Ce que cold ne peut pas faire est la moitié politique du travail — portails, niveaux, règles de fusion — qui est précisément où les bras se séparent.
Curez la prose en un digest. Lisez le fichier de politique brut. Ne lisez rien deux fois.
Divulgation complète
- Modèle : chaque appel API de chaque agent a fonctionné sur claude-opus-4-8 (Claude Opus 4.8) — vérifié à partir du champ
modelde chaque ligne de transcription, pas supposé. Les résultats peuvent différer sur d’autres modèles ; les modèles plus petits dépendent probablement plus du contexte curé, pas moins. - Prix : les coûts utilisent les prix de liste d’Anthropic au moment de la rédaction ; la facturation réelle peut différer. Les comparaisons relatives ne sont pas affectées.
- Taille d’échantillon : n=5 par bras (n=2 pour cold), une PR, un référentiel, un type de tâche. L’effet de portail (5/5 contre 1/5) est net ; les taux par découverte ailleurs sont ±1 agent. Traitez ceci comme un pilote solide, pas un benchmark.
- Métrique de qualité : détection de motifs sur le texte de révision (citations exclues), auditée manuellement pour les faux positifs. Il compte les mentions de défauts vérifiés, pas l’éloquence globale de la révision.
- Timing : les 22 agents partageaient une machine et un quota API ; les numéros de temps d’horloge murale incluent cette contention.
- Nous nous sommes corrigés deux fois : les comptages de tokens initiaux étaient gonflés 2–3× (duplication d’utilisation par ligne dans les transcriptions ; corrigée par dédup request-ID), et une chronologie visuelle antérieure sous-comptait le temps mural (corrigée par attribution d’intervalle complet). Les deux corrections sont intégrées dans chaque chiffre ici.
Prêt à développer votre entreprise?
Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.
Maintenant quoi : volez la boucle
Ce que nous avons livré
Le bras gagnant est maintenant la compétence check-context-first par défaut du référentiel : tirez le digest du moteur de contexte (deux appels), puis lisez exactement un fichier depuis le disque — la configuration du harness — et émettez un bloc de confirmation citant le snapshot et les portails exacts. Une faiblesse mesurée, une correction de politique d’une ligne, re-validée le même jour. Cette boucle — mesurer, corriger la politique de contexte, re-valider — est la partie que nous vous encourageons à voler, quel que soit le moteur de contexte que vous utilisez.
Ce que vous pouvez faire lundi
- Divisez votre contexte d’agent en deux : prose (conventions, architecture, tests) vs politique lisible par machine (portails CI, niveaux de risque, règles de fusion).
- Curez la prose ; ne curez jamais la politique. Servez la prose via un moteur de contexte — meaninggrid est le nôtre — et rendez le fichier de politique une lecture verbatim obligatoire dans votre portail de contexte.
- Rendez le contexte auditable. Versionnez le contexte ingéré ; exigez que les agents citent l’id du snapshot dans un bloc de confirmation que les examinateurs peuvent réellement vérifier.
- Mesurez avant de croire — y compris nous. Une poignée d’agents par bras sur votre propre référentiel suffit pour voir le motif. Notez les révisions par rapport aux découvertes vérifiées, pas par vibes.
Une invitation ouverte
Si vous exécutez cette expérience sur votre propre référentiel — mêmes bras, votre modèle, votre harness — nous aimerions vraiment voir vos chiffres, surtout s’ils réfutent les nôtres. Et si votre équipe veut de l’aide pour configurer un portail de contexte comme celui-ci, ou veut parler de meaninggrid et de la pile harnext, contactez l’équipe FlowHunt ou trouvez le harness open-source sur harnext.dev . Les réplications, questions et corrections sont tous bienvenues.
