Cómo medimos

Pathrule hace una sola afirmación medida principal, y trata sobre si el trabajo sale como el proyecto ya sabía que debía salir, no sobre velocidad ni costo.

Esta página muestra el panorama completo: la matriz detrás de esa afirmación, la única cifra de carga que citamos, el resultado negativo que la acompaña, un benchmark de eficiencia anterior y su alcance, y los límites de todo ello.

El resultado principal: cumplimiento

Doce tareas, veinticuatro ejecuciones, un agente, un modelo fijo. Cada tarea se ejecutó dos veces a partir de una copia nueva, idéntica byte a byte, del mismo repositorio, con el mismo prompt. El prompt no contenía pistas, y el script de puntuación se escribió y se congeló antes de cualquier ejecución.

• Sin Pathrule: la copia de trabajo sin nada más. Sin archivos de conocimiento, sin hook.
• Con Pathrule: la ruta de entrega real de producción, sin cambios.

Cada tarea tenía una convención oculta del proyecto que un agente capaz no podía deducir de los archivos: el acceso al entorno debe pasar por un gateway, una configuración debe pasar una validación antes de devolverse, un cuerpo de solicitud vacío debe controlarse antes del parseo, esta base de datos es una réplica de solo lectura, este parser reemplaza a aquel. El evaluador comprobaba dos cosas por separado: si el cambio funcionaba y si seguía la convención.

Cómo interpretarlo

El agente no es el problema. Todas las ejecuciones sin Pathrule produjeron una implementación funcionalmente correcta. Claude podía hacer el trabajo en ambos casos. Lo que cambió fue si lo hacía como el espacio de trabajo ya sabía que debía hacerse.

Se repite en distintos tipos de conocimiento. Nueve de las doce tareas discriminaron, repartidas entre restricciones, una comprobación obligatoria, correcciones recordadas, un hecho de contexto, una justificación, un caso mixto y una relación de precedencia. Las dos tareas de correcciones recordadas son las más claras: sin Pathrule, el agente reprodujo exactamente los incidentes que las correcciones guardadas existen para evitar.

Tres tareas no discriminaron, y eso se informa en lugar de descartarse. En esas tres, el conocimiento se podía recuperar del propio repositorio: unos comentarios revelaban una preferencia, tres funciones de ciclo de vida exportadas hacían evidente el orden, y el nombre de una función ganadora encajaba mejor con la tarea que el de la perdedora. En ambas condiciones se respetó la convención. Son resultados neutros, no regresiones, y marcan el límite del efecto. Pathrule cambia el resultado cuando el conocimiento realmente no está en el código, y no aporta ninguna mejora de cumplimiento cuando el código ya lo implica.

La cifra de carga de conocimiento

Un A/B en vivo independiente midió qué efecto tiene la entrega compilada y acotada a la tarea sobre el tamaño del conocimiento que recibe un agente.

En memorias narrativas, una forma compilada y acotada a la tarea transmitió el mismo conocimiento en aproximadamente 104 a 234 tokens, mientras que la forma en prosa ocupaba unos 3.000. Eso es una carga de conocimiento entre 13 y 30 veces más pequeña, medida.

Dos límites, y ambos son fundamentales.

Es un resultado sobre memorias narrativas. Una memoria que ya es una convención de una sola oración es casi atómica de entrada; compilarla no ahorra casi nada, y una ejecución aparte midió justamente eso (prosa de 25 a 70 tokens frente a IR de 15 a 59). Citar la cifra de 13 a 30 veces para convenciones compactas sería incorrecto.

No redujo el total de tokens. El mismo A/B midió el uso de tokens nuevos del agente en ambas condiciones y encontró que una inyección 13 veces más pequeña no lo redujo. El ahorro está en la carga de conocimiento, y importa para la presión sobre el contexto, no para la factura.

Por eso la redacción en todo este sitio es deliberada y fija: carga de conocimiento, nunca tokens totales. Pathrule no afirma reducir en un porcentaje el uso de tokens de tu agente, porque cuando lo medimos, no lo hizo.

El benchmark anterior de eficiencia de entrega

Antes de la matriz de cumplimiento, lo que se medía era la eficiencia de entrega: qué le pasa a la carga de contexto cuando el mismo conocimiento se entrega vinculado a una ruta en lugar de volcarse completo en un único archivo de instrucciones. Esa suite es abierta y puedes ejecutarla en github.com/pathrule/benchmarks. Clona un repositorio de código abierto en una versión fija (Fastify), lo carga con conocimiento al estilo de un equipo y hace las mismas diez preguntas dos veces, una por condición, con puntuación mecánica y tres ejecuciones por celda.

Su métrica principal era la huella total, es decir, los tokens que el modelo procesa por turno, en el nivel difícil:

Qué es esa comparación y qué no es. Compara dos formas de entregar la misma base de conocimiento: todo en un archivo frente a solo la parte relevante. No es una medición de Pathrule frente a un agente que trabaja solo, y no se generaliza a una afirmación sobre tu gasto total en agentes. La fila de Codex es mixta y se publica como tal. El informe también publica las celdas donde Pathrule cuesta más. Los tokens facturables no cacheados se muestran junto a la huella total, ya que el caché de prompts abarata un volcado estático.

Leídos junto con el resultado de carga anterior, ambos dicen algo coherente: el conocimiento que envía Pathrule es mucho más pequeño, y cuánto mueve eso tu uso general depende por completo de qué domina tus sesiones.

Por qué escanear el código no cierra la brecha

Las ejecuciones sin Pathrule no son una falla de las herramientas. El agente hizo lo razonable: leyó el código y razonó sobre él. La falla es estructural. El dato que necesitaba era una decisión del equipo, no una propiedad del código fuente, y ningún escaneo adicional saca a la luz una decisión que los archivos no registran.

Eso es lo que realmente mide la matriz de cumplimiento: el costo de redescubrir, en cada sesión, un conocimiento que ya existe. Consulta cómo se acumula el conocimiento.

Lo que los números no significan

• No son garantías. Son lo que medimos en las configuraciones descritas arriba. Tus resultados dependen de tus tareas, tu código, cuánto del conocimiento de tu equipo esté capturado y el agente que uses.
• Dependen de la tarea. Un cambio cuya respuesta ya está en el archivo que tienes abierto no muestra mejora de cumplimiento, porque no había nada oculto que pasar por alto.
• Dependen del código. El efecto crece según cuánto del conocimiento de tu equipo se haya capturado.
• Dependen del modelo y de la herramienta. Cada agente lee archivos y llama a herramientas con frecuencias distintas.
• Describen lo que llega al trabajo, no el tamaño ni la calidad del código producido.

Qué publicamos y qué no

Publicamos lo que medimos, las condiciones, los límites, las celdas neutras y las celdas donde Pathrule cuesta más.

No publicamos cómo decide el sistema qué conocimiento mostrar. Si quieres entender el comportamiento y no los detalles internos, cómo la recuperación encuentra el conocimiento correcto describe lo que puedes observar, y seguridad y respaldo describe qué ocurre cuando no tiene suficiente confianza.