Come misuriamo

Pathrule fa un'unica affermazione principale basata su misurazioni, e riguarda se il lavoro viene fuori nel modo in cui il progetto sapeva già che dovesse essere fatto, non la velocità o il costo.

Questa pagina offre il quadro completo: la griglia alla base di quell'affermazione, l'unico dato sul payload che citiamo, il risultato negativo che lo accompagna, un precedente benchmark sull'efficienza con il suo ambito, e i limiti di tutti questi dati.

Il risultato principale: la conformità

Dodici attività, ventiquattro esecuzioni, un agente, un modello fissato. Ogni attività è stata eseguita due volte partendo da una copia nuova e identica byte per byte dello stesso repository, con lo stesso prompt. Il prompt non conteneva suggerimenti, e lo script di valutazione è stato scritto e congelato prima di qualsiasi esecuzione.

• Senza Pathrule: la semplice copia di lavoro. Nessun file di conoscenza, nessun hook.
• Con Pathrule: il vero percorso di consegna di produzione, senza modifiche.

Ogni attività aveva una convenzione di progetto nascosta che un agente capace non poteva ricavare dai file: l'accesso all'ambiente deve passare da un gateway, una configurazione deve superare la validazione prima di essere restituita, un corpo di richiesta vuoto va gestito prima del parsing, questo database è una replica in sola lettura, questo parser sostituisce quell'altro. Lo script di valutazione verificava due cose distinte: se la modifica funzionava e se rispettava la convenzione.

Come leggerlo

Il problema non è l'agente. Ogni esecuzione senza Pathrule ha prodotto un'implementazione funzionalmente corretta. Claude era in grado di svolgere il lavoro in entrambi i casi. Quello che cambiava era se lo svolgesse nel modo in cui il workspace sapeva già che andava fatto.

Si ripete su diversi tipi di conoscenza. Nove delle dodici attività hanno discriminato, distribuite tra vincoli, un controllo obbligatorio, correzioni memorizzate, un fatto di contesto, una motivazione, un caso misto e una relazione di precedenza. Le due attività sulle correzioni memorizzate sono le più nette: senza Pathrule l'agente ha riprodotto esattamente gli incidenti che le correzioni salvate esistono per prevenire.

Tre attività non hanno discriminato, e il dato viene riportato anziché scartato. In quei tre casi la conoscenza era ricavabile dal repository stesso: alcuni commenti rivelavano una preferenza, tre funzioni di ciclo di vita esportate rendevano ovvio l'ordine, e il nome della funzione corretta corrispondeva all'attività meglio di quello dell'alternativa. In entrambe le condizioni la convenzione è stata rispettata. Sono risultati neutri, non regressioni, e segnano il confine dell'effetto. Pathrule cambia il risultato quando la conoscenza davvero non si trova nel codice, e non aggiunge alcun guadagno di conformità quando il codice la lascia già intendere.

Il dato sul payload di conoscenza

Un A/B dal vivo separato ha misurato l'effetto della consegna compilata e legata all'attività sulla dimensione della conoscenza che un agente riceve.

Sulle memorie narrative, una forma compilata e legata all'attività trasportava la stessa conoscenza in circa 104-234 token, contro i circa 3.000 della forma in prosa. Si tratta di un payload di conoscenza da 13 a 30 volte più piccolo, misurato.

Due limiti, ed entrambi sono essenziali.

È un risultato sulle memorie narrative. Una memoria che è già una convenzione di una sola frase è quasi atomica in partenza; compilarla non fa risparmiare quasi nulla, ed è esattamente ciò che ha misurato un'esecuzione separata (prosa da 25 a 70 token contro IR da 15 a 59). Citare il dato da 13 a 30 volte per convenzioni compatte sarebbe sbagliato.

Non ha ridotto i token totali. Lo stesso A/B ha misurato l'uso di token nuovi dell'agente in entrambe le condizioni e ha rilevato che un'iniezione 13 volte più piccola non lo ha ridotto. Il risparmio riguarda il payload di conoscenza, e conta per la pressione sul contesto, non per la bolletta.

Per questo la formulazione usata in tutto il sito è deliberata e fissa: payload di conoscenza, mai token totali. Pathrule non afferma di ridurre di una certa percentuale l'uso di token del tuo agente, perché quando lo abbiamo misurato non è successo.

Il precedente benchmark sull'efficienza di consegna

Prima della griglia di conformità, ciò che veniva misurato era l'efficienza di consegna: cosa succede al carico di contesto quando la stessa conoscenza viene consegnata legata al percorso invece di essere riversata per intero in un unico file di istruzioni. Quella suite è aperta ed eseguibile su github.com/pathrule/benchmarks. Fa il checkout di un repository open source fissato (Fastify), lo popola con conoscenza in stile team e pone gli stessi dieci prompt due volte, una per condizione, con valutazione meccanica e tre esecuzioni per cella.

La metrica principale era il footprint totale, cioè i token che il modello elabora a ogni turno, sul livello di difficoltà più alto:

Cosa è quel confronto, e cosa non è. Confronta due modi di consegnare la stessa base di conoscenza: tutto in un unico file contro la sola porzione pertinente. Non è una misurazione di Pathrule rispetto a un agente che lavora da solo, e non si generalizza in un'affermazione sulla tua spesa complessiva per l'agente. La riga di Codex è mista ed è pubblicata come tale. Il report pubblica anche le celle in cui Pathrule costa di più. I token fatturabili non in cache sono riportati accanto al footprint totale, dato che il prompt caching sconta un dump statico.

Letti insieme al risultato sul payload qui sopra, i due dicono una cosa coerente: la conoscenza che Pathrule invia è molto più piccola, e quanto questo incida sul tuo utilizzo complessivo dipende interamente da ciò che domina le tue sessioni.

Perché una scansione del codice non colma il divario

Le esecuzioni senza Pathrule non sono un fallimento degli strumenti. L'agente ha fatto la cosa ragionevole: ha letto il codice e ci ha ragionato sopra. La mancanza è strutturale. Il fatto di cui aveva bisogno era una decisione del team, non una proprietà del sorgente, e nessuna scansione aggiuntiva può far emergere una decisione che i file non registrano.

È questo che la griglia di conformità misura davvero: il costo di riscoprire, a ogni sessione, una conoscenza che esiste già. Vedi come cresce la conoscenza nel tempo.

Cosa non significano i numeri

• Non sono garanzie. Sono ciò che abbiamo misurato sulle configurazioni descritte sopra. I tuoi risultati dipendono dalle tue attività, dalla tua codebase, da quanta conoscenza del tuo team è stata acquisita e dall'agente che usi.
• Dipendono dall'attività. Una modifica la cui risposta si trova già nel file che hai aperto non mostra alcun guadagno di conformità, perché non c'era nulla di nascosto da mancare.
• Dipendono dalla codebase. L'effetto cresce con la quantità di conoscenza del tuo team che è stata acquisita.
• Dipendono dal modello e dallo strumento. Agenti diversi leggono file e chiamano strumenti con frequenze diverse.
• Descrivono ciò che arriva al lavoro, non la dimensione o la qualità del codice prodotto.

Cosa pubblichiamo e cosa no

Pubblichiamo ciò che abbiamo misurato, le condizioni, i limiti, le celle neutre e le celle in cui Pathrule costa di più.

Non pubblichiamo il modo in cui il sistema decide quale conoscenza far emergere. Se vuoi capire il comportamento anziché i meccanismi interni, come il recupero trova la conoscenza giusta descrive ciò che puoi osservare, e sicurezza e fallback descrive cosa succede quando il sistema non è sicuro.