Per Chi È Agent Trace?

Cursor ha rilasciato Agent Trace, una specifica aperta per tracciare quale codice in un repository è stato scritto da un LLM. Registra il modello, lo strumento, la conversazione e gli esatti intervalli di righe — tutto aggiunto a un file JSONL nel tuo progetto.

La proposta: “Man mano che gli agenti scrivono più codice, è importante capire cosa proviene dall’IA rispetto agli umani.”

Ho passato del tempo a leggere la specifica e l’implementazione di riferimento. L’ingegnerizzazione è solida — schema pulito, estensibilità ben ponderata, buona lista di partner (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel). Ma continuavo a tornare su una domanda: cosa fai con questi dati?

Cosa Cattura

Ogni volta che un LLM modifica un file, un hook si attiva e registra una traccia: quale modello, quale strumento, quali righe, quale conversazione. L’implementazione di riferimento gestisce eventi sia da Cursor che da Claude Code:

// Dal hook di riferimento — gli eventi fluiscono tramite stdin
appendTrace(createTrace("ai", input.file_path!, {
  model: input.model,
  rangePositions,
  transcript: input.transcript_path,
  metadata: { conversation_id: input.conversation_id, generation_id: input.generation_id },
}));

La specifica definisce quattro tipi di contributori — human, ai, mixed, unknown — e supporta l’attribuzione a livello di riga con hash dei contenuti per tracciare il codice che si sposta. È vendor-neutral, agnostica rispetto ai VCS ed estensibile tramite metadati con namespace.

Come formato dati, è ben progettato. La domanda è cosa abilita.

La Sfida dell’Attribuzione

La specifica modella l’autorialità come una classificazione. Ma la programmazione assistita da LLM è una conversazione. Descrivi cosa vuoi. L’LLM genera qualcosa. Modifichi metà, rifiuti una funzione, chiedi una revisione, accetti il secondo tentativo e poi correggi manualmente un caso limite. Più tardi, un altro LLM refactorizza l’intero blocco.

Chi ha scritto quel codice? Il confine tra autorialità umana e LLM è sfocato, e sta diventando sempre più sfocato. La maggior parte del codice reale finirà come mixed, e se quasi tutto è mixed, la classificazione non ti dice molto.

L’attribuzione a livello di riga ha anche un problema di durata. Una traccia dice “Claude ha scritto le righe 10-50 nel commit abc123.” Due commit dopo, qualcuno riformatta quel blocco o ne estrae una funzione. La risposta della specifica è concatenare tramite git blame, e gli hash dei contenuti possono aiutare a tracciare il codice che si sposta. Ma nei workflow con rebase e squash-merge, la catena si spezza. Questi sono problemi difficili — il tipo che un RFC iniziale dovrebbe far emergere.

L’Azione Mancante

La specifica nega esplicitamente gli usi ovvi: non per la proprietà del codice, non per la valutazione della qualità, non per la provenienza dei dati di addestramento. Dice “trasparenza”. Ma la trasparenza è un mezzo, non un fine.

Se il codice passa la revisione e i test, cosa cambia perché un LLM lo ha scritto? Se è buggy, lo correggi comunque. La specifica non connette mai l’attribuzione a un’azione concreta. I dati entrano, ma non c’è un modo definito per ottenere risposte. Questo è il divario — non il formato, ma il caso d’uso.

Dove Diventa Interessante

Ecco cosa penso che Agent Trace stia realmente indicando, anche se la specifica non lo dice ancora.

Dietro ogni funzione generata da LLM ci sono token di ragionamento, svolte sbagliate, tentativi, cambi di contesto e invocazioni di strumenti. Un agente non produce solo codice — attraversa un processo per arrivarci. Legge file, fraintende un’interfaccia, torna indietro, prova un approccio diverso, esegue un test, corregge il fallimento e arriva a una soluzione. Quel processo è invisibile nel diff finale.

L’hook cattura già più della semplice attribuzione. Guarda la superficie di input:

interface HookInput {
  hook_event_name: string;
  model?: string;
  transcript_path?: string | null;
  conversation_id?: string;
  generation_id?: string;
  session_id?: string;
  file_path?: string;
  edits?: FileEdit[];
  command?: string;
  duration?: number;
  is_background_agent?: boolean;
  composer_mode?: string;
  tool_name?: string;
  tool_input?: { file_path?: string; new_string?: string; old_string?: string; command?: string };
  tool_use_id?: string;
}

Modello, sessione, conversazione, strumento, comando, durata, se è un agente in background, la modalità compositore, ogni invocazione di strumento con il suo input. Questi non sono solo dati di attribuzione. Questi sono dati di processo. E i dati di processo sono dove risiede il vero valore:

• Valutazioni. Quali modelli faticano con quali pattern? Una funzione che ha richiesto un tentativo è diversa da una che ha richiesto dodici tentativi — anche se l’output è identico. Non “chi l’ha scritto” ma “quanto è stato difficile produrlo.”
• Codebase native per agenti. Se gli agenti faticano costantemente con un modulo — molte svolte sbagliate, alti tassi di tentativi, confusione di contesto ripetuta — questo è un segnale che il codice non è strutturato per come funzionano gli agenti. Puoi refactorizzare per chiarezza, interfacce migliori, contratti più espliciti. I dati di traccia diventano una mappa di dove la tua codebase è ostile alla collaborazione LLM.
• Ottimizzazione del processo. Quali configurazioni di strumenti producono codice migliore al primo tentativo? Quali pattern di prompting riducono il backtracking? Non puoi rispondere a queste domande dall’attribuzione di riga. Hai bisogno del viaggio, non della destinazione.

La Domanda Giusta

Agent Trace è agli inizi. È un RFC con sfide reali riguardo alla modellazione dell’attribuzione, alla durabilità degli intervalli e alla semantica delle query. Ma l’istinto è giusto — man mano che gli LLM scrivono più codice, abbiamo bisogno di dati strutturati su come ciò accade.

La versione più utile di questa specifica potrebbe non essere “cosa ha scritto l’LLM?” ma “come ci è arrivato l’LLM?”. Il registro a livello di riga è un punto di partenza. La traccia del processo — il ragionamento, le iterazioni, il costo di arrivare a una soluzione — è dove questo diventa qualcosa che i team usano effettivamente per scrivere codice migliore con gli LLM.

Questa è la specifica su cui vorrei costruire.