Wir gaben 22 AI Agents die gleiche Code-Review-Aufgabe. Gleicher Pull Request, gleicher gepinnter Commit, gleiche Anfrage, gleiches Modell — die einzige Variable war, wie jeder Agent die Projektregeln lud. Die günstigste Konfiguration erwies sich als die gründlichste, und der Grund dafür sagt etwas Allgemeines über Context Engineering aus.
TL;DR: Ein Context-Engine-Digest plus eine direkte Lektüre der maschinenlesbaren Richtliniendatei schlug jede andere Strategie: 1,56 $ pro Review und 9,6/13 verifizierte Befunde — günstiger als das Lesen der Dokumentation (2,30 $, 8,6/13) und besser als nur der Digest (1,77 $, 7,8/13). Alles zu lesen erzielte das schlechteste Ergebnis (7,4/13). Alle 22 Agents liefen auf Claude Opus 4.8, und 21 von 22 kamen zum gleichen Urteil.
Was: ein Harness, eine Context Engine und ein Pull Request
Was ist ein “Harness”?
Jeder ernsthafte Versuch, AI Agents in einem Production-Repository arbeiten zu lassen, entwickelt zwei Governance-Ebenen.
Die Prosa-Ebene — Konventionen, Architektur-Regeln, Testing-Standards. In unserem Repository sind das CLAUDE.md und docs/**: “Backend ist snake_case”, “Domain importiert nie Infrastructure”, “alle Route Handler sind async”. Menschen lesen es; Agents wird gesagt, es auch zu lesen.
Die maschinenlesbare Ebene — die Harness-Konfiguration. Unsere ist eine einzige JSON-Datei, die jeden Pfad im Repository in Risiko-Tiers klassifiziert und durchsetzbare Gates an jeden Tier anhängt. CI liest es. Merge-Richtlinie liest es. Es ist keine Empfehlung — es ist Richtlinie:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Anmerkung zur Terminologie: “Harness” benennt auch die Agent Runtime selbst — das Gerüst von Tools, Fähigkeiten und MCP-Servern, durch die ein Agent handelt, wie in harnext , “der Coding-Agent-Harness”. In diesem Beitrag ist die Harness-Konfiguration die Richtliniendatei des Repositories, die solch eine Runtime und die CI durchsetzen.)
Ein Code Reviewer — Mensch oder Agent — kann nicht beurteilen, “darf dieser PR zusammengeführt werden?” ohne diese Datei. Ein Tier-3 PR mit dem übersprungenen review-agent Check ist eine Richtlinienverletzung auch wenn jeder Test grün ist. Behalten Sie dieses Beispiel im Hinterkopf; es entscheidet das Experiment.
Weil beide Ebenen existieren, mandatiert das Repository ein Gate: kein Agent startet die Arbeit, bevor dieser Kontext geladen ist — und beweist dies über einen Bestätigungsblock, den Reviewer überprüfen. Die Frage, die dieser Beitrag beantwortet, ist einfach: Was ist der günstigste korrekte Weg, um dieses Gate zu erfüllen?
Treffen Sie harnext und meaninggrid
meaninggrid ist die gehostete Context Engine von harnext
, QualityUnits MIT-lizenziertem, Provider-agnostischem Coding-Agent-Harness (sechs Tools — read, write, edit, bash, skill, mcp — npm i -g harnext). Das Angebot des Vendors für die Context Engine ist deutlich: “das Gehirn Ihres Agents.” Quellen fließen in einen kontinuierlich aktualisierten Index — “das Grid” — und pro Abfrage “ordnet und beschneidet die Engine es in token-effiziente Kontext, direkt in den Harness verdrahtet”: kontinuierlicher Index, Relevanzranking, Deduplizierung und Cache. harnext’s Headline-Nummer ist −89% Token pro Abfrage im Durchschnitt. Das ist die Aussage des Vendors; ein Zweck dieses Experiments war zu messen, mit unseren eigenen Zahlen bei einer echten Aufgabe, was diese Art von Kompression tatsächlich spart — und was sie kostet.
In unserer Bereitstellung nimmt das Grid die Prosa-Dokumentation des Repositories auf; jede Aufnahme erzeugt einen unveränderlichen, versionierten Snapshot. Agents fragen es über MCP (meaninggrid.harnext.dev/mcp) mit einem einzelnen context_research Aufruf ab und erhalten einen synthetisierten, zitierten Digest, der mit der snapshot_id gestempelt ist, die der Agent in seinem Bestätigungsblock zitieren muss — auditable Kontext gemacht konkret.
Was das Gate produziert — der Bestätigungsblock (Beispiel; Projektspezifikationen ausgelassen):
Geladen über: optimiertes Hybrid (Context-Engine-Digest + nur Richtliniendatei).
- context_research Aufruf #1 (Konventionen / Schichtung / Testing / Sicherheit /
Risiko-Tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research Aufruf #2 (LLM-Provider-Integration Checkliste +
Flow-Engine Extra-Care-Regeln) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Harness-Konfiguration (vollständig) von Disk für exakte Tier-Muster lesen,
requiredChecks, mergePolicy, evidenceConfig.
NICHT GELESEN: CLAUDE.md oder docs/* (abgedeckt durch den Digest).
Die snapshot_id ist real — ein Reviewer kann genau überprüfen, welche Version der Regeln der Agent verwendete.
Drei Hypothesen
Das Experiment wurde entworfen, um drei testbare Vorhersagen zu klären, die vorher aufgeschrieben wurden:
H1 — Ein Digest ist günstiger als erneutes Lesen. Nimm die Prosa-Dokumentation einmalig auf, stelle jedem Agent einen kompakten synthetisierten Digest bereit, statt dass jeder Agent jedes Dokument bei jeder Aufgabe erneut liest. Falls wahr: bedeutsam niedrigere Kosten pro Review bei gleichen Urteilen.
H2 — Paraphrase zerstört Richtlinie. Ein Digest kann “Tier 3 erfordert Überprüfung durch Menschen” ohne Verlust tragen. Es kann "requireReviewAgent": true nicht ohne Verlust tragen — die genauen, zitierbaren Spezifikationen, die ein Reviewer braucht, um eine Verletzung zu behaupten, sterben in der Zusammenfassung. Falls wahr: Digest-only Agents sollten systematisch Gate-Verletzungen übersehen, die Agents mit der wörtlichen Richtliniendatei erkennen.
H3 — Leaner Kontext liest tiefer. Kontext wird zweimal bezahlt — einmal in Dollar, einmal in Aufmerksamkeit: jedes redundante Dokument im Fenster konkurriert mit dem Code unter Review. Falls wahr: alles zu lesen (Digest + alle Dokumentation) sollte nicht gewinnen; der leanste ausreichende Kontext sollte.
Wie wir es testeten
Zweiundzwanzig Agents überprüften den gleichen Tier-3 Pull Request in unserem Production-Monorepo (eine LLM-Provider-Integration: 44 Dateien, +2.111 Zeilen, echte Einsätze — Abrechnung Tabellen, Flow-Engine Routing). Fünf Arme, unterschiedlich nur im Context-Loading-Schritt:
| Arm | Context-Laden | n |
|---|---|---|
| meaninggrid | Context-Engine-Digest nur (2× context_research) | 5 |
| disk | liest 7+ Dokumentationen von Disk — keine Context Engine | 5 |
| hybrid | Digest + liest ALLE Dokumentationen | 5 |
| opt-hybrid | Digest + liest EINE Datei: die Harness-Konfiguration | 5 |
| cold | überhaupt kein Konventionskontext (Baseline) | 2 |
Grundregeln: ein gepinnter Commit, ein Anfrage-Body, ein Modell — Claude Opus 4.8 — alle Arme verschachtelt in einem einzelnen gleichzeitigen Batch. Agents wurde der Zugriff auf den PR-Kommentar-Thread verweigert, damit frühere Experiment-Runden nicht durchsickern konnten. Jede Zahl kommt aus den rohen Agent-Transkripten, mit Token-Nutzung dedupliziert pro API-Anfrage und zu Listenpreisen berechnet. Qualität wird gegen 13 unabhängig verifizierte, echte Defekte im PR bewertet, Muster-abgestimmt in jeder Review’s Body und manuell geprüft auf falsch-positive. Urteilsübereinstimmung über alle Arme: 21/22 sagten ÄNDERUNGEN ANFORDERN.
Was also: die günstigste Konfiguration gewann auch bei Qualität
| Arm | Kosten / Review | Befunde (von 13) | Gate-Befunde (von 3) | Wanduhr |
|---|---|---|---|---|
| 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 |
★ = die Konfiguration, die wir jetzt als Standard-Fähigkeit des Repositories ausliefern. Wanduhr umfasst gemeinsame Contention vom gleichzeitigen Ausführen von 22 Agents.
H1 — bestätigt
Der Digest-only Arm überprüfte für $1,77 gegen $2,30 für das Lesen der Dokumentation (−23%), und der gewinnende Digest-plus-eine-Datei Arm für $1,56 (−32%) — bei gleichen Urteilen. Die Einsparung summiert sich: der Digest ersetzt einen Stack von Dokumentationen, die sonst durch jeden nachfolgenden API-Aufruf’s Kontext fahren würden.
H2 — bestätigt, entscheidend
Der übersprungene review-agent Check — eine echte Merge-Policy-Verletzung in diesem PR — wurde von 5 von 5 Agents mit der wörtlichen Richtliniendatei erkannt, und von 1 von 5 Digest-only Agents. Der Mechanismus ist genau das, was H2 vorhersagte: um diesen Befund zu schreiben, muss ein Agent exakte CI-Check-Namen gegen exakte Config-Felder abgleichen — eine Paraphrase ist nicht zitierbar als Beweis, also hedgen Digest-only Agents und lassen es fallen. Eine direkte Lektüre stellt es wieder her.
H3 — bestätigt
Der Alles-lesen Hybrid trug den meisten Kontext aller Arme und schnitt am schlechtesten ab (7,4/13), während der leanste ausreichende Arm am besten abschnitt (9,6/13) — und war besten aller Arme bei dem einzelnen tiefsten Befund, ein Dead-Code Bug, der das Verfolgen eines Aufrufs über drei Dateien erfordert. Redundante Prosa fügte keine Informationen hinzu; sie konkurrierte mit dem Code um Aufmerksamkeit.
Ein ehrlicher Fußnote: die Cold-Baseline (8,0/13 bei $1,64) zeigt, dass die meisten der 13 Defekte einfache Code-Bugs sind, die ein starkes Modell ohne Konventionskontext findet. Was Cold nicht kann, ist die Richtlinien-Hälfte des Jobs — Gates, Tiers, Merge-Regeln — was genau dort ist, wo sich die Arme trennen.
Kuratieren Sie die Prosa in einen Digest. Lesen Sie die Richtliniendatei roh. Lesen Sie nichts zweimal.
Vollständige Offenlegung
- Modell: jeder API-Aufruf jedes Agents lief auf claude-opus-4-8 (Claude Opus 4.8) — verifiziert aus dem
modelFeld jeder Transkript-Zeile, nicht angenommen. Ergebnisse können auf anderen Modellen unterschiedlich sein; kleinere Modelle hängen wahrscheinlich mehr von kuratiertem Kontext ab, nicht weniger. - Preise: Kosten verwenden Anthropic Listenpreise zum Zeitpunkt des Schreibens; tatsächliche Abrechnung kann unterschiedlich sein. Relative Vergleiche sind unberührt.
- Stichprobengröße: n=5 pro Arm (n=2 für cold), ein PR, ein Repository, ein Aufgabentyp. Der Gate-Effekt (5/5 gegen 1/5) ist scharf; Pro-Befund-Raten anderswo sind ±1 Agent. Behandeln Sie dies als starken Piloten, nicht als Benchmark.
- Qualitätsmetrik: Mustererkennung über Review-Text (Zitate ausgeschlossen), manuell geprüft auf falsch-positive. Es zählt Erwähnungen von verifizierten Defekten, nicht insgesamt Review-Eloquenz.
- Timing: alle 22 Agents teilten sich eine Maschine und ein API-Kontingent; Wanduhr-Nummern umfassen diese Contention.
- Wir korrigierten uns selbst zweimal: anfängliche Token-Zählungen waren aufgeblasen 2–3× (Pro-Zeile-Nutzungs-Duplikation in Transkripten; behoben durch Request-ID-Deduplizierung), und eine frühere Timeline-Visualisierung unterschätzte Wandzeit (behoben durch volle Interval-Attribution). Beide Korrektionen sind in jede Zahl hier eingebacken.
Bereit, Ihr Geschäft zu erweitern?
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Jetzt was: stehlen Sie die Schleife
Was wir auslieferten
Der gewinnende Arm ist jetzt die Standard-check-context-first Fähigkeit des Repositories: Ziehen Sie den Context-Engine-Digest (zwei Aufrufe), dann lesen Sie genau eine Datei von Disk — die Harness-Konfiguration — und geben Sie einen Bestätigungsblock aus, der den Snapshot und die genauen Gates zitiert. Eine gemessene Schwäche, eine Ein-Zeilen-Richtlinien-Fix, revalidiert am selben Tag. Diese Schleife — messen, die Context-Richtlinie reparieren, revalidieren — ist der Teil, den wir Sie ermutigen würden zu stehlen, egal welche Context Engine Sie verwenden.
Was Sie am Montag tun können
- Teilen Sie Ihren Agent-Kontext in zwei: Prosa (Konventionen, Architektur, Testing) gegen maschinenlesbare Richtlinie (CI Gates, Risiko-Tiers, Merge-Regeln).
- Verdauen Sie die Prosa; verdauen Sie niemals die Richtlinie. Stellen Sie die Prosa über eine Context Engine bereit — meaninggrid ist unsere — und machen Sie die Richtliniendatei zu einer obligatorischen wörtlichen Lektüre in Ihrem Context Gate.
- Machen Sie Kontext auditable. Versionieren Sie den aufgenommenen Kontext; verlangen Sie von Agents, die snapshot_id in einem Bestätigungsblock zu zitieren, den Reviewer tatsächlich überprüfen können.
- Messen Sie, bevor Sie uns glauben — auch uns. Eine Handvoll Agents pro Arm auf Ihrem eigenen Repository reicht aus, um das Muster zu sehen. Bewerten Sie die Reviews gegen verifizierte Befunde, nicht Vibes.
Eine offene Einladung
Wenn Sie dieses Experiment auf Ihrem eigenen Repository ausführen — gleiche Arme, Ihr Modell, Ihr Harness — würden wir wirklich gerne Ihre Zahlen sehen, besonders wenn sie unsere widerlegen. Und wenn Ihr Team Hilfe beim Einrichten eines Context Gates wie diesem braucht, oder über meaninggrid und den harnext-Stack sprechen möchte, kontaktieren Sie das FlowHunt-Team oder finden Sie den Open-Source-Harness unter harnext.dev . Replikationen, Fragen und Korrektionen sind alle willkommen.
