Le dimos la misma tarea de revisión de código a 22 agentes AI. Mismo pull request, mismo commit fijado, mismo prompt, mismo modelo — la única variable fue cómo cada agente cargó las reglas del proyecto. La configuración más barata resultó ser la más completa, y la razón por la que dice algo general sobre ingeniería de contexto.
TL;DR: Un resumen de motor de contexto más una lectura directa del archivo de política legible por máquina ganó cada otra estrategia: $1.56 por revisión y 9.6/13 hallazgos verificados — más barato que leer la documentación ($2.30, 8.6/13) y mejor que el resumen solo ($1.77, 7.8/13). Leer todo obtuvo la peor puntuación de todas (7.4/13). Los 22 agentes se ejecutaron en Claude Opus 4.8, y 21 de 22 llegaron al mismo veredicto.
Qué: un arnés, un motor de contexto y un pull request
¿Qué es un “arnés”?
Cada intento serio de dejar que los agentes AI funcionen en un repositorio de producción crece dos capas de gobernanza.
La capa de prosa — convenciones, reglas de arquitectura, estándares de prueba. En nuestro repositorio eso es CLAUDE.md y docs/**: “backend es snake_case”, “domain nunca importa infrastructure”, “todos los manejadores de ruta son async”. Los humanos lo leen; a los agentes se les dice que también lo lean.
La capa legible por máquina — la configuración del arnés. La nuestra es un único archivo JSON que clasifica cada ruta en el repositorio en niveles de riesgo y adjunta puertas ejecutables a cada nivel. CI lo lee. La política de fusión lo lee. No es consejo — es política:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Nota de terminología: “arnés” también nombra el tiempo de ejecución del agente — el andamiaje de herramientas, habilidades y servidores MCP que un agente actúa, como en harnext , “el arnés del agente de codificación”. En este post, la configuración del arnés es el archivo de política del repositorio que tanto tal tiempo de ejecución como el CI aplican.)
Un revisor de código — humano o agente — no puede juzgar “¿se permite que este PR se fusione?” sin este archivo. Un PR de Nivel 3 con la verificación review-agent omitida es una violación de política incluso si todas las pruebas están en verde. Ten ese ejemplo en mente; decide el experimento.
Porque ambas capas existen, el repositorio ordena una puerta: ningún agente comienza el trabajo antes de cargar este contexto — y probándolo, a través de un bloque de confirmación que los revisores verifican. La pregunta que este post responde es simplemente: ¿cuál es la forma más barata correcta de satisfacer esa puerta?
Conoce harnext y meaninggrid
meaninggrid es el Motor de Contexto alojado de harnext
, el arnés de agente de codificación agnóstico de proveedor con licencia MIT de QualityUnit (seis herramientas — read, write, edit, bash, skill, mcp — npm i -g harnext). El argumento del vendedor para el Motor de Contexto es directo: “el cerebro de tu agente”. Las fuentes fluyen hacia un índice continuamente actualizado — “la red” — y por consulta el motor “lo clasifica y poda en contexto eficiente en tokens, conectado directamente al arnés”: índice continuo, clasificación de relevancia, deduplicación y caché. El número principal de harnext es −89% tokens por consulta en promedio. Esa es la afirmación del vendedor; un propósito de este experimento fue medir, con nuestros propios números en una tarea real, qué ahorra realmente ese tipo de compresión — y qué cuesta.
En nuestro despliegue la red ingiere la documentación en prosa del repositorio; cada ingestión produce una instantánea inmutable y versionada. Los agentes la consultan sobre MCP (meaninggrid.harnext.dev/mcp) con una única llamada context_research y reciben un resumen sintetizado, citado estampado con el snapshot_id, que el agente debe citar en su bloque de confirmación — contexto auditable hecho concreto.
Lo que la puerta produce — el bloque de confirmación (ejemplo; especificidades del proyecto omitidas):
Cargado a través de: híbrido optimizado (resumen del motor de contexto + archivo de política solo).
- llamada context_research #1 (convenciones / capas / pruebas / seguridad /
niveles de riesgo) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- llamada context_research #2 (lista de verificación de integración de proveedor de LLM +
reglas de cuidado extra del motor de flujo) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Leer configuración del arnés (completa) desde el disco para patrones exactos de nivel,
requiredChecks, mergePolicy, evidenceConfig.
NO leyó CLAUDE.md o docs/* (cubierto por el resumen).
El snapshot_id es real — un revisor puede verificar exactamente qué versión de las reglas usó el agente.
Tres hipótesis
El experimento fue diseñado para resolver tres predicciones comprobables, escritas de antemano:
H1 — Un resumen es más barato que releer. Ingiere los documentos en prosa una vez, sirve a cada agente un resumen sintetizado compacto, en lugar de que cada agente relea cada documento en cada tarea. Si es verdadero: costo significativamente más bajo por revisión, con veredictos iguales.
H2 — La paráfrasis destruye la política. Un resumen puede llevar “Nivel 3 requiere revisión humana” sin pérdida. No puede llevar "requireReviewAgent": true sin pérdida — los detalles exactos y citables que un revisor necesita para afirmar una violación mueren en el resumen. Si es verdadero: los agentes solo con resumen deberían perder sistemáticamente violaciones de puerta que los agentes que tienen el archivo de política literal capturan.
H3 — El contexto más delgado lee más profundo. El contexto se paga dos veces — una vez en dólares, otra en atención: cada documento redundante en la ventana compite con el código bajo revisión. Si es verdadero: leer todo (resumen + todos los documentos) no debería ganar; el contexto más delgado y suficiente debería.
Cómo lo probamos
Veintidós agentes revisaron el mismo pull request de Nivel 3 en nuestro monorepo de producción (una integración de proveedor de LLM: 44 archivos, +2,111 líneas, apuestas reales — tablas de facturación, enrutamiento del motor de flujo). Cinco brazos, diferenciándose solo en el paso de carga de contexto:
| Brazo | Carga de contexto | n |
|---|---|---|
| meaninggrid | resumen del motor de contexto solo (2× context_research) | 5 |
| disk | lee 7+ documentos desde el disco — sin motor de contexto | 5 |
| hybrid | resumen + lee TODOS los documentos | 5 |
| opt-hybrid | resumen + lee UN archivo: la configuración del arnés | 5 |
| cold | sin contexto de convención en absoluto (línea de base) | 2 |
Reglas fundamentales: un commit fijado, un cuerpo de prompt, un modelo — Claude Opus 4.8 — todos los brazos intercalados en un único lote concurrente. Se les prohibió a los agentes acceder al hilo de comentarios del PR, para que las rondas de experimento anteriores no se filtraran. Cada número proviene de las transcripciones brutas del agente, con uso de tokens deduplicado por solicitud de API y precio a precios de lista. La calidad se puntúa contra 13 defectos reales verificados de forma independiente en el PR, coincididos por patrón en el cuerpo de cada revisión y auditados manualmente para falsos positivos. Acuerdo de veredicto en todos los brazos: 21/22 dijo REQUEST CHANGES.
Entonces qué: la configuración más barata también ganó en calidad
| Brazo | Costo / revisión | Hallazgos (de 13) | Hallazgos de puerta (de 3) | Reloj de pared |
|---|---|---|---|---|
| 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 configuración que ahora enviamos como la habilidad predeterminada del repositorio. El reloj de pared incluye contención compartida de ejecutar 22 agentes concurrentemente.
H1 — confirmada
El brazo solo con resumen revisó por $1.77 vs $2.30 para leer la documentación (−23%), y el brazo ganador de resumen-más-un-archivo por $1.56 (−32%) — con veredictos iguales. El ahorro se compone: el resumen reemplaza una pila de documentos que de otro modo viajarían a través de cada llamada de API posterior en el contexto.
H2 — confirmada, decisivamente
La verificación review-agent omitida — una violación de política de fusión genuina en este PR — fue capturada por 5 de 5 agentes que tenían el archivo de política literal, y por 1 de 5 agentes solo con resumen. El mecanismo es exactamente lo que H2 predijo: para escribir ese hallazgo, un agente debe coincidir nombres exactos de verificaciones de CI contra campos de configuración exactos — una paráfrasis no es evidencia citable, así que los agentes solo con resumen se cubren y lo descartan. Una lectura directa lo restaura.
H3 — confirmada
El híbrido de leer-todo llevaba el mayor contexto de cualquier brazo y obtuvo la peor puntuación (7.4/13), mientras que el brazo más delgado y suficiente obtuvo la mejor (9.6/13) — y fue el mejor de todos los brazos en el hallazgo único más profundo, un error de código muerto que requiere rastrear una ruta de llamada a través de tres archivos. La prosa redundante no agregó información; compitió con el código por atención.
Una nota honesta: la línea de base fría (8.0/13 a $1.64) muestra que la mayoría de los 13 defectos son errores de código simple que un modelo fuerte encuentra sin contexto de convención en absoluto. Lo que cold no puede hacer es la mitad de política del trabajo — puertas, niveles, reglas de fusión — que es precisamente donde los brazos se separan.
Cura la prosa en un resumen. Lee el archivo de política crudo. No leas nada dos veces.
Divulgación completa
- Modelo: cada llamada de API de cada agente se ejecutó en claude-opus-4-8 (Claude Opus 4.8) — verificado desde el campo
modelde cada línea de transcripción, no asumido. Los resultados pueden diferir en otros modelos; los modelos más pequeños probablemente dependen más del contexto curado, no menos. - Precios: los costos utilizan precios de lista de Anthropic en el momento de la escritura; la facturación real puede diferir. Las comparaciones relativas no se ven afectadas.
- Tamaño de muestra: n=5 por brazo (n=2 para cold), un PR, un repositorio, un tipo de tarea. El efecto de puerta (5/5 vs 1/5) es agudo; las tasas por hallazgo en otros lugares son ±1 agente. Trata esto como un piloto fuerte, no un punto de referencia.
- Métrica de calidad: detección de patrones sobre texto de revisión (citas excluidas), auditado manualmente para falsos positivos. Cuenta menciones de defectos verificados, no elocuencia general de revisión.
- Temporización: los 22 agentes compartieron una máquina y una cuota de API; los números de reloj de pared incluyen esa contención.
- Nos corregimos dos veces: los conteos de tokens iniciales estaban inflados 2–3× (duplicación de uso por línea en transcripciones; fijo por deduplicación de ID de solicitud), y una línea de tiempo anterior subestimaba el tiempo de pared (fijo por atribución de intervalo completo). Ambas correcciones están integradas en cada número aquí.
¿Listo para hacer crecer tu negocio?
Comienza tu prueba gratuita hoy y ve resultados en días.
Ahora qué: roba el bucle
Lo que enviamos
El brazo ganador es ahora la habilidad predeterminada check-context-first del repositorio: extrae el resumen del motor de contexto (dos llamadas), luego lee exactamente un archivo desde el disco — la configuración del arnés — y emite un bloque de confirmación citando la instantánea y las puertas exactas. Una debilidad medida, una corrección de política de una línea, revalidada el mismo día. Ese bucle — medir, corregir la política de contexto, revalidar — es la parte que te alentamos a robar, sea cual sea el motor de contexto que uses.
Lo que puedes hacer el lunes
- Divide tu contexto de agente en dos: prosa (convenciones, arquitectura, pruebas) vs política legible por máquina (puertas de CI, niveles de riesgo, reglas de fusión).
- Digiere la prosa; nunca digeras la política. Sirve la prosa a través de un motor de contexto — meaninggrid es el nuestro — y haz que el archivo de política sea una lectura verbatim obligatoria en tu puerta de contexto.
- Haz que el contexto sea auditable. Versioniza el contexto ingerido; requiere que los agentes citen el id de instantánea en un bloque de confirmación que los revisores realmente puedan verificar.
- Mide antes de creer — incluyéndonos a nosotros. Un puñado de agentes por brazo en tu propio repositorio es suficiente para ver el patrón. Puntúa las revisiones contra hallazgos verificados, no vibraciones.
Una invitación abierta
Si ejecutas este experimento en tu propio repositorio — mismos brazos, tu modelo, tu arnés — realmente nos gustaría ver tus números, especialmente si refutan los nuestros. Y si tu equipo quiere ayuda configurando una puerta de contexto como esta, o quiere hablar sobre meaninggrid y la pila harnext, comunícate con el equipo de FlowHunt o encuentra el arnés de código abierto en harnext.dev . Las replicaciones, preguntas y correcciones son bienvenidas.
