Voor Wie Is Agent Trace?

Cursor bracht Agent Trace uit, een open specificatie voor het bijhouden welke code in een repo door een LLM is geschreven. Het registreert het model, de tool, het gesprek en de exacte lijnbereiken — allemaal toegevoegd aan een JSONL-bestand in je project.

De pitch: “Naarmate agents meer code schrijven, is het belangrijk om te begrijpen wat van AI kwam versus mensen.”

Ik heb tijd besteed aan het lezen van de spec en de referentie-implementatie. De engineering is solide — schoon schema, doordachte uitbreidbaarheid, goede partnerlijst (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel). Maar ik bleef terugkomen bij één vraag: wat doe je met deze data?

Wat Het Vastlegt

Elke keer dat een LLM een bestand bewerkt, wordt een hook geactiveerd en wordt een trace geregistreerd: welk model, welke tool, welke lijnen, welk gesprek. De referentie-implementatie verwerkt events van zowel Cursor als Claude Code:

// Uit de referentie-hook — events stromen binnen via 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 },
}));

De spec definieert vier contributortypes — human, ai, mixed, unknown — en ondersteunt toewijzing op lijnniveau met content hashes voor het volgen van code die wordt verplaatst. Het is vendor-neutraal, VCS-agnostisch en uitbreidbaar via metadata met namespaces.

Als dataformaat is het goed ontworpen. De vraag is wat het mogelijk maakt.

De Toewijzingsuitdaging

De spec modelleert auteurschap als een classificatie. Maar LLM-geassisteerd coderen is een gesprek. Je beschrijft wat je wilt. De LLM genereert iets. Je bewerkt de helft ervan, wijst een functie af, vraagt om een herziening, accepteert de tweede poging en repareert dan handmatig een randgeval. Later refactort een andere LLM het hele blok.

Wie schreef die code? De grens tussen menselijk en LLM-auteurschap is vaag, en het wordt vager. De meeste echte code zal eindigen als mixed, en als bijna alles mixed is, vertelt de classificatie je niet veel.

Toewijzing op lijnniveau heeft ook een houdbaarheidsprobleem. Een trace zegt “Claude schreef lijnen 10-50 bij commit abc123.” Twee commits later herformatteert iemand dat blok of extraheert er een functie uit. Het antwoord van de spec is om door te ketenen via git blame, en content hashes kunnen helpen code te volgen die wordt verplaatst. Maar in workflows met rebases en squash-merges breekt de keten. Dit zijn moeilijke problemen — het type dat een vroege RFC zou moeten aanstippen.

De Ontbrekende Actie

De spec wijst expliciet de voor de hand liggende toepassingen af: niet voor code-eigendom, niet voor kwaliteitsbeoordeling, niet voor herkomst van trainingsdata. Het zegt “transparantie”. Maar transparantie is een middel, geen doel.

Als de code review en tests doorstaat, wat verandert er dan omdat een LLM het schreef? Als het buggy is, repareer je het hoe dan ook. De spec verbindt toewijzing nooit met een concrete actie. Data gaat erin, maar er is geen gedefinieerde manier om antwoorden eruit te krijgen. Dat is de kloof — niet het formaat, maar de use case.

Waar Het Interessant Wordt

Dit is wat ik denk dat Agent Trace eigenlijk aangeeft, zelfs als de spec het nog niet zegt.

Achter elke LLM-gegenereerde functie zijn redeneertoken, verkeerde bochten, nieuwe pogingen, contextwisselingen en tool-aanroepen. Een agent produceert niet alleen code — het doorloopt een proces om daar te komen. Het leest bestanden, begrijpt een interface verkeerd, gaat terug, probeert een andere aanpak, voert een test uit, repareert het falen en komt tot een oplossing. Dat proces is onzichtbaar in de uiteindelijke diff.

De hook legt al meer vast dan alleen toewijzing. Kijk naar het input-oppervlak:

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;
}

Model, sessie, gesprek, tool, commando, duur, of het een achtergrondagent is, de composer-modus, elke tool-aanroep met zijn input. Dit zijn niet alleen toewijzingsdata. Dit zijn procesdata. En procesdata is waar de echte waarde ligt:

• Evaluaties. Welke modellen worstelen met welke patronen? Een functie die één poging kostte is anders dan een die twaalf nieuwe pogingen kostte — zelfs als de output identiek is. Niet “wie schreef het” maar “hoe moeilijk was het om te produceren.”
• Agent-native codebases. Als agents consistent worstelen met een module — veel verkeerde bochten, hoge retry-percentages, herhaalde contextverwarring — dan is dat een signaal dat de code niet is gestructureerd voor hoe agents werken. Je kunt refactoren voor duidelijkheid, betere interfaces, meer expliciete contracten. De trace-data wordt een kaart van waar je codebase vijandig is voor LLM-samenwerking.
• Procesoptimalisatie. Welke toolconfiguraties produceren betere eerste-poging-code? Welke prompting-patronen verminderen het terugkeren? Je kunt deze vragen niet beantwoorden vanuit lijntoewijzing. Je hebt de reis nodig, niet de bestemming.

De Juiste Vraag

Agent Trace is vroeg. Het is een RFC met echte uitdagingen rond toewijzingsmodellering, bereikduurzaamheid en querysemantics. Maar het instinct is juist — naarmate LLM’s meer code schrijven, hebben we gestructureerde data nodig over hoe dat gebeurt.

De meest nuttige versie van deze spec is misschien niet “wat schreef de LLM?” maar “hoe kwam de LLM daar?” Het grootboek op lijnniveau is een startpunt. De proces-trace — het redeneren, de iteraties, de kosten van het komen tot een oplossing — is waar dit iets wordt dat teams daadwerkelijk gebruiken om betere code te schrijven met LLM’s.

Dat is de spec waarop ik zou willen bouwen.