¿Para Quién Es Agent Trace?

Cursor lanzó Agent Trace, una especificación abierta para rastrear qué código en un repositorio fue escrito por un LLM. Registra el modelo, la herramienta, la conversación y los rangos de línea exactos, todo añadido a un archivo JSONL en tu proyecto.

La propuesta: “A medida que los agentes escriben más código, es importante entender qué provino de la IA versus los humanos.”

Pasé tiempo leyendo la especificación y la implementación de referencia. La ingeniería es sólida: esquema limpio, extensibilidad bien pensada, buena lista de socios (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel). Pero seguía volviendo a una pregunta: ¿qué haces con estos datos?

Qué Captura

Cada vez que un LLM edita un archivo, se activa un hook y registra un trace: qué modelo, qué herramienta, qué líneas, qué conversación. La implementación de referencia maneja eventos tanto de Cursor como de Claude Code:

// Del hook de referencia — los eventos fluyen vía 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 especificación define cuatro tipos de contribuyentes: human, ai, mixed, unknown, y soporta atribución a nivel de línea con hashes de contenido para rastrear código que se mueve. Es neutral al proveedor, agnóstico al VCS y extensible mediante metadatos con espacios de nombres.

Como formato de datos, está bien diseñado. La pregunta es qué habilita.

El Desafío de la Atribución

La especificación modela la autoría como una clasificación. Pero la codificación asistida por LLM es una conversación. Describes lo que quieres. El LLM genera algo. Editas la mitad, rechazas una función, pides una revisión, aceptas el segundo intento y luego corriges manualmente un caso extremo. Más tarde, otro LLM refactoriza todo el bloque.

¿Quién escribió ese código? El límite entre la autoría humana y del LLM es borroso, y se está volviendo más borroso. La mayoría del código real terminará como mixed, y si casi todo es mixed, la clasificación no te dice mucho.

La atribución a nivel de línea también tiene un problema de caducidad. Un trace dice “Claude escribió las líneas 10-50 en el commit abc123.” Dos commits después, alguien reformatea ese bloque o extrae una función de él. La respuesta de la especificación es encadenar mediante git blame, y los hashes de contenido pueden ayudar a rastrear código que se mueve. Pero en flujos de trabajo con rebases y squash-merges, la cadena se rompe. Estos son problemas difíciles, el tipo que un RFC temprano debería estar planteando.

La Acción Ausente

La especificación rechaza explícitamente los usos obvios: no para propiedad del código, no para evaluación de calidad, no para proveniencia de datos de entrenamiento. Dice “transparencia”. Pero la transparencia es un medio, no un fin.

Si el código pasa la revisión y las pruebas, ¿qué cambia porque un LLM lo escribió? Si tiene errores, lo arreglas de todas formas. La especificación nunca conecta la atribución con una acción concreta. Los datos entran, pero no hay una forma definida de obtener respuestas. Esa es la brecha: no el formato, sino el caso de uso.

Donde Se Pone Interesante

Esto es lo que creo que Agent Trace realmente está señalando, incluso si la especificación aún no lo dice.

Detrás de cada función generada por LLM hay tokens de razonamiento, caminos erróneos, reintentos, cambios de contexto e invocaciones de herramientas. Un agente no solo produce código: pasa por un proceso para llegar allí. Lee archivos, malinterpreta una interfaz, retrocede, prueba un enfoque diferente, ejecuta una prueba, corrige el fallo y llega a una solución. Ese proceso es invisible en el diff final.

El hook ya captura más que solo atribución. Mira la superficie de entrada:

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

Modelo, sesión, conversación, herramienta, comando, duración, si es un agente en segundo plano, el modo compositor, cada invocación de herramienta con su entrada. Esto no son solo datos de atribución. Estos son datos de proceso. Y los datos de proceso son donde vive el verdadero valor:

• Evaluaciones. ¿Qué modelos luchan con qué patrones? Una función que tomó un intento es diferente de una que tomó doce reintentos, incluso si el resultado es idéntico. No “quién lo escribió” sino “qué tan difícil fue producirlo”.
• Bases de código nativas para agentes. Si los agentes luchan consistentemente con un módulo (muchos caminos erróneos, altas tasas de reintento, confusión de contexto repetida), esa es una señal de que el código no está estructurado para cómo funcionan los agentes. Puedes refactorizar para claridad, mejores interfaces, contratos más explícitos. Los datos del trace se convierten en un mapa de dónde tu base de código es hostil a la colaboración con LLM.
• Optimización de procesos. ¿Qué configuraciones de herramientas producen mejor código en el primer intento? ¿Qué patrones de prompts reducen el retroceso? No puedes responder esto desde la atribución de líneas. Necesitas el viaje, no el destino.

La Pregunta Correcta

Agent Trace es temprano. Es un RFC con desafíos reales en torno al modelado de atribución, durabilidad de rangos y semántica de consultas. Pero el instinto es correcto: a medida que los LLM escriben más código, necesitamos datos estructurados sobre cómo sucede eso.

La versión más útil de esta especificación podría no ser “¿qué escribió el LLM?” sino “¿cómo llegó allí el LLM?”. El libro mayor a nivel de línea es un punto de partida. El trace de proceso (el razonamiento, las iteraciones, el costo de llegar a una solución) es donde esto se convierte en algo que los equipos realmente usan para escribir mejor código con LLM.

Esa es la especificación sobre la que querría construir.