Como medimos

O Pathrule faz uma única afirmação principal baseada em medição, e ela trata de se o trabalho sai do jeito que o projeto já sabia que deveria sair, não de velocidade ou custo.

Esta página mostra o quadro completo: a grade por trás dessa afirmação, o único número de payload que citamos, o resultado negativo associado a ele, um benchmark de eficiência anterior e seu escopo, e os limites de todos eles.

O resultado principal: conformidade

Doze tarefas, vinte e quatro execuções, um agente, um modelo fixado. Cada tarefa rodou duas vezes a partir de uma cópia nova, idêntica byte a byte, do mesmo repositório, com o mesmo prompt. O prompt não continha nenhuma dica, e o script de pontuação foi escrito e congelado antes de qualquer execução.

• Sem Pathrule: a cópia de trabalho pura. Nenhum arquivo de conhecimento, nenhum hook.
• Com Pathrule: o caminho real de entrega de produção, sem alterações.

Cada tarefa tinha uma convenção oculta do projeto que um agente capaz não conseguiria deduzir dos arquivos: o acesso ao ambiente precisa passar por um gateway, uma configuração precisa ser validada antes de ser retornada, um corpo de requisição vazio precisa ser tratado antes do parsing, este banco de dados é uma réplica somente leitura, este parser substitui aquele outro. O avaliador verificou duas coisas separadas: a mudança funcionou, e ela seguiu a convenção.

Como interpretar

O agente não é o problema. Todas as execuções sem Pathrule produziram uma implementação funcionalmente correta. O Claude conseguia fazer o trabalho nos dois casos. O que mudou foi se ele fez o trabalho do jeito que o espaço de trabalho já sabia que deveria ser feito.

Isso se repete em diferentes tipos de conhecimento. Nove das doze tarefas diferenciaram as condições, distribuídas entre restrições, uma verificação obrigatória, correções lembradas, um fato de contexto, uma justificativa, um caso misto e uma relação de precedência. As duas tarefas de correção lembrada são as mais nítidas: sem o Pathrule, o agente reproduziu exatamente os incidentes que as correções armazenadas existem para evitar.

Três tarefas não diferenciaram as condições, e isso é relatado em vez de descartado. Nessas três, o conhecimento podia ser recuperado do próprio repositório: comentários revelavam uma preferência, três funções de ciclo de vida exportadas deixavam a ordem evidente, e o nome da função vencedora combinava mais com a tarefa do que o da perdedora. A convenção foi respeitada nas duas condições. São resultados neutros, não regressões, e marcam o limite do efeito. O Pathrule muda o resultado quando o conhecimento realmente não está no código, e não traz ganho de conformidade quando o código já o deixa implícito.

O número de payload de conhecimento

Um teste A/B ao vivo separado mediu o que a entrega compilada e vinculada à tarefa faz com o tamanho do conhecimento que o agente recebe.

Em memórias narrativas, uma forma compilada e vinculada à tarefa carregou o mesmo conhecimento em cerca de 104 a 234 tokens, enquanto a forma em prosa ocupava cerca de 3.000. Isso representa um payload de conhecimento de 13 a 30 vezes menor, medido.

Há dois limites, e os dois são essenciais.

É um resultado para memórias narrativas. Uma memória que já é uma convenção de uma frase é praticamente atômica desde o início; compilá-la quase não economiza nada, e uma execução separada mediu exatamente isso (prosa com 25 a 70 tokens contra IR com 15 a 59). Citar o número de 13 a 30 vezes para convenções compactas seria errado.

Não reduziu o total de tokens. O mesmo teste A/B mediu o uso de tokens novos do agente nas duas condições e constatou que uma injeção 13 vezes menor não o reduziu. A economia está no payload de conhecimento, e ela importa para a pressão sobre o contexto, não para a conta.

Por isso, a forma de dizer isso em todo o site é deliberada e fixa: payload de conhecimento, nunca total de tokens. O Pathrule não afirma reduzir o uso de tokens do seu agente em nenhuma porcentagem, porque, quando medimos, isso não aconteceu.

O benchmark anterior de eficiência de entrega

Antes da grade de conformidade, o que se media era a eficiência de entrega: o que acontece com a carga de contexto quando o mesmo conhecimento é entregue vinculado a caminhos, em vez de despejado inteiro em um único arquivo de instruções. Essa suíte é aberta e pode ser executada em github.com/pathrule/benchmarks. Ela faz checkout de um repositório de código aberto fixado (Fastify), o popula com conhecimento no estilo de uma equipe e envia os mesmos dez prompts duas vezes, uma por condição, com pontuação mecânica e três execuções por célula.

A métrica principal era o consumo total, ou seja, os tokens que o modelo processa por turno, no nível difícil:

O que essa comparação é, e o que não é. Ela compara duas formas de entregar a mesma base de conhecimento: tudo em um único arquivo contra apenas a parte relevante. Não é uma medição do Pathrule contra um agente trabalhando sozinho, e não se generaliza para uma afirmação sobre o seu gasto total com agentes. A linha do Codex é mista e é publicada como tal. O relatório também publica as células em que o Pathrule custa mais. Os tokens faturáveis não armazenados em cache aparecem ao lado do consumo total, já que o cache de prompt dá desconto a um despejo estático.

Lidos junto com o resultado de payload acima, os dois dizem algo coerente: o conhecimento que o Pathrule envia é muito menor, e o quanto isso afeta o seu uso geral depende inteiramente do que domina as suas sessões.

Por que uma varredura de código não resolve a lacuna

As execuções sem Pathrule não são uma falha de ferramenta. O agente fez o razoável: leu o código e raciocinou sobre ele. A falha é estrutural. O fato de que ele precisava era uma decisão da equipe, não uma propriedade do código-fonte, e nenhuma varredura adicional faz aparecer uma decisão que os arquivos não registram.

É isso que a grade de conformidade realmente mede: o custo de redescobrir, a cada sessão, um conhecimento que já existe. Veja como o conhecimento se acumula.

O que os números não significam

• Não são garantias. São o que medimos nas configurações descritas acima. Seus resultados dependem das suas tarefas, da sua base de código, de quanto do conhecimento da sua equipe foi capturado e do agente que você usa.
• Dependem da tarefa. Uma mudança cuja resposta já está no arquivo que você tem aberto não mostra ganho de conformidade, porque não havia nada oculto para deixar passar.
• Dependem da base de código. O efeito cresce conforme a quantidade de conhecimento da sua equipe que foi capturada.
• Dependem do modelo e da ferramenta. Agentes diferentes leem arquivos e chamam ferramentas em ritmos diferentes.
• Descrevem o que chega ao trabalho, não o tamanho nem a qualidade do código produzido.

O que publicamos e o que não publicamos

Publicamos o que medimos, as condições, os limites, as células neutras e as células em que o Pathrule custa mais.

Não publicamos como o sistema decide qual conhecimento trazer à tona. Se você quer entender o comportamento, e não os detalhes internos, como a recuperação encontra o conhecimento certo descreve o que você pode observar, e segurança e fallback descreve o que acontece quando ele não tem confiança suficiente.