Notre méthode de mesure

Pathrule avance une seule affirmation principale mesurée, et elle porte sur la question de savoir si le travail aboutit comme le projet savait déjà qu'il devait aboutir, pas sur la vitesse ni sur le coût.

Cette page présente l'ensemble : la grille qui fonde cette affirmation, le seul chiffre de charge utile que nous citons, le résultat négatif qui l'accompagne, un benchmark d'efficacité antérieur avec son périmètre, et les limites de chacun.

Le résultat principal : la conformité

Douze tâches, vingt-quatre exécutions, un agent, un modèle figé. Chaque tâche a été exécutée deux fois à partir d'une copie neuve et identique octet pour octet du même dépôt, avec le même prompt. Le prompt ne contenait aucun indice, et le script de notation a été écrit puis figé avant toute exécution.

• Sans Pathrule : la copie de travail brute. Aucun fichier de connaissances, aucun hook.
• Avec Pathrule : le vrai chemin de diffusion de production, sans modification.

Chaque tâche comportait une convention de projet cachée qu'un agent compétent ne pouvait pas déduire des fichiers : l'accès à l'environnement doit passer par une passerelle, une configuration doit être validée avant d'être renvoyée, un corps de requête vide doit être vérifié avant l'analyse, cette base de données est une réplique en lecture seule, ce parseur remplace celui-là. Le script de notation vérifiait deux choses distinctes : la modification fonctionnait-elle, et respectait-elle la convention.

Comment lire ces résultats

Le problème ne vient pas de l'agent. Chaque exécution sans Pathrule a produit une implémentation fonctionnellement correcte. Claude savait faire le travail dans les deux cas. Ce qui changeait, c'était s'il le faisait comme l'espace de travail savait déjà qu'il fallait le faire.

L'effet se répète d'un type de connaissances à l'autre. Neuf des douze tâches ont été discriminantes, réparties entre contraintes, vérification obligatoire, correctifs mémorisés, fait de contexte, justification, cas mixte et relation de priorité. Les deux tâches de correctifs mémorisés sont les plus parlantes : sans Pathrule, l'agent a reproduit exactement les incidents que les correctifs enregistrés visent à empêcher.

Trois tâches n'ont pas été discriminantes, et nous le publions au lieu de les écarter. Dans ces trois cas, les connaissances pouvaient être retrouvées dans le dépôt lui-même : des commentaires révélaient une préférence, trois fonctions de cycle de vie exportées rendaient l'ordre évident, et le nom d'une fonction gagnante correspondait mieux à la tâche que celui de la perdante. La convention était respectée dans les deux conditions. Ce sont des résultats neutres, pas des régressions, et ils marquent la limite de l'effet. Pathrule change le résultat quand les connaissances ne figurent réellement pas dans le code, et n'apporte aucun gain de conformité quand le code les implique déjà.

Le chiffre sur la charge utile de connaissances

Un test A/B distinct, en conditions réelles, a mesuré l'effet d'une diffusion compilée et liée à la tâche sur la taille des connaissances que reçoit un agent.

Sur des mémoires narratives, une forme compilée et liée à la tâche transmettait les mêmes connaissances en 104 à 234 tokens environ, là où la forme en prose en demandait environ 3 000. Cela représente une charge utile de connaissances 13 à 30 fois plus petite, mesurée.

Deux limites s'appliquent, et toutes deux sont essentielles.

C'est un résultat propre aux mémoires narratives. Une mémoire qui se résume déjà à une convention d'une phrase est quasiment atomique au départ : la compiler ne fait presque rien gagner, et une exécution distincte a mesuré précisément cela (prose de 25 à 70 tokens contre IR de 15 à 59). Citer le facteur de 13 à 30 pour des conventions compactes serait faux.

Il n'a pas réduit le total des tokens. Le même test A/B a mesuré la consommation de tokens neufs de l'agent dans les deux conditions et a constaté qu'une injection 13 fois plus petite ne l'avait pas réduite. Le gain porte sur la charge utile de connaissances, et il compte pour la pression sur le contexte plutôt que pour la facture.

La formulation employée sur ce site est donc délibérée et figée : charge utile de connaissances, jamais total des tokens. Pathrule ne prétend pas réduire d'un certain pourcentage la consommation de tokens de votre agent, parce que, lorsque nous l'avons mesurée, elle n'a pas baissé.

Le benchmark antérieur sur l'efficacité de diffusion

Avant la grille de conformité, nous mesurions l'efficacité de diffusion : ce qu'il advient de la charge de contexte quand les mêmes connaissances sont diffusées liées au chemin au lieu d'être déversées en bloc dans un seul fichier d'instructions. Cette suite est ouverte et exécutable sur github.com/pathrule/benchmarks. Elle récupère un dépôt open source figé à une version précise (Fastify), l'alimente avec des connaissances de type équipe et pose deux fois les dix mêmes prompts, une fois par condition, avec une notation mécanique et trois exécutions par cellule.

Son indicateur principal était l'empreinte totale, c'est-à-dire les tokens traités par le modèle à chaque tour, sur le niveau difficile :

Ce que cette comparaison est, et ce qu'elle n'est pas. Elle compare deux façons de diffuser la même base de connaissances : tout dans un seul fichier, ou uniquement la partie pertinente. Ce n'est pas une mesure de Pathrule face à un agent travaillant seul, et elle ne permet pas d'en tirer une affirmation sur vos dépenses totales en agents. La ligne Codex est mitigée et publiée comme telle. Le rapport publie aussi les cellules où Pathrule coûte davantage. Les tokens facturables non mis en cache figurent à côté de l'empreinte totale, puisque la mise en cache des prompts réduit le coût d'un déversement statique.

Lus avec le résultat sur la charge utile présenté plus haut, ces deux résultats disent la même chose : les connaissances qu'envoie Pathrule sont beaucoup plus petites, et la part de votre consommation globale que cela fait bouger dépend entièrement de ce qui domine vos sessions.

Pourquoi une analyse du code ne comble pas l'écart

Les exécutions sans Pathrule ne relèvent pas d'une défaillance de l'outillage. L'agent a fait ce qui était raisonnable : il a lu le code et raisonné dessus. L'échec est structurel. Le fait dont il avait besoin était une décision d'équipe, pas une propriété du code source, et aucune analyse supplémentaire ne fait apparaître une décision que les fichiers n'enregistrent pas.

C'est ce que mesure réellement la grille de conformité : le coût de redécouvrir, à chaque session, des connaissances qui existent déjà. Voir comment les connaissances fructifient.

Ce que les chiffres ne signifient pas

• Ce ne sont pas des garanties. Ce sont nos mesures sur les configurations décrites ci-dessus. Vos résultats dépendent de vos tâches, de votre base de code, de la part des connaissances de votre équipe qui a été capturée et de l'agent que vous utilisez.
• Ils dépendent de la tâche. Une modification dont la réponse se trouve déjà dans le fichier ouvert ne montre aucun gain de conformité, puisqu'il n'y avait rien de caché à manquer.
• Ils dépendent de la base de code. L'effet croît avec la part des connaissances de votre équipe qui a été capturée.
• Ils dépendent du modèle et de l'outil. Les agents ne lisent pas les fichiers et n'appellent pas les outils au même rythme.
• Ils décrivent ce qui parvient au travail, pas la taille ni la qualité du code produit.

Ce que nous publions, et ce que nous ne publions pas

Nous publions ce que nous avons mesuré, les conditions, les limites, les cellules neutres et les cellules où Pathrule coûte davantage.

Nous ne publions pas la façon dont le système décide quelles connaissances faire remonter. Si vous voulez comprendre le comportement plutôt que le fonctionnement interne, comment la récupération trouve les bonnes connaissances décrit ce que vous pouvez observer, et sécurité et repli décrit ce qui se passe quand le système n'est pas sûr de lui.