Agent Trace किसके लिए है?

Cursor ने Agent Trace जारी किया, एक ओपन स्पेसिफिकेशन जो ट्रैक करता है कि किसी रेपो में कौन सा कोड LLM द्वारा लिखा गया था। यह मॉडल, टूल, बातचीत और सटीक लाइन रेंज रिकॉर्ड करता है — सभी को आपके प्रोजेक्ट में एक JSONL फ़ाइल में जोड़ा जाता है।

पिच: “जैसे-जैसे एजेंट अधिक कोड लिखते हैं, यह समझना महत्वपूर्ण है कि क्या AI से आया बनाम मनुष्यों से।”

मैंने स्पेसिफिकेशन और रेफरेंस इम्प्लीमेंटेशन को पढ़ने में समय बिताया। इंजीनियरिंग ठोस है — साफ स्कीमा, विचारशील एक्सटेंसिबिलिटी, अच्छी पार्टनर लिस्ट (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel)। लेकिन मैं एक सवाल पर वापस आता रहा: आप इस डेटा का क्या करते हैं?

यह क्या कैप्चर करता है

हर बार जब LLM किसी फ़ाइल को एडिट करता है, एक हुक फायर होता है और एक ट्रेस रिकॉर्ड करता है: कौन सा मॉडल, कौन सा टूल, कौन सी लाइनें, कौन सी बातचीत। रेफरेंस इम्प्लीमेंटेशन Cursor और Claude Code दोनों से इवेंट्स को हैंडल करता है:

// रेफरेंस हुक से — इवेंट 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 },
}));

स्पेसिफिकेशन चार योगदानकर्ता प्रकार परिभाषित करता है — human, ai, mixed, unknown — और लाइन-लेवल attribution का समर्थन करता है जिसमें कोड को ट्रैक करने के लिए कंटेंट हैश होते हैं जो घूमता है। यह vendor-neutral है, VCS-agnostic है, और namespaced metadata के माध्यम से एक्सटेंसिबल है।

एक डेटा फॉर्मेट के रूप में, यह अच्छी तरह से डिज़ाइन किया गया है। सवाल यह है कि यह क्या सक्षम बनाता है।

Attribution चुनौती

स्पेसिफिकेशन authorship को एक वर्गीकरण के रूप में मॉडल करता है। लेकिन LLM-असिस्टेड कोडिंग एक बातचीत है। आप वर्णन करते हैं कि आप क्या चाहते हैं। LLM कुछ जेनरेट करता है। आप इसका आधा हिस्सा एडिट करते हैं, एक फंक्शन को अस्वीकार करते हैं, एक संशोधन के लिए कहते हैं, दूसरे प्रयास को स्वीकार करते हैं, फिर मैन्युअल रूप से एक edge case को ठीक करते हैं। बाद में, एक और LLM पूरे ब्लॉक को रिफैक्टर करता है।

उस कोड को किसने लिखा? मानव और LLM authorship के बीच की सीमा धुंधली है, और यह अधिक धुंधली होती जा रही है। अधिकांश वास्तविक कोड mixed के रूप में समाप्त होगा, और यदि लगभग सब कुछ mixed है, तो वर्गीकरण आपको बहुत कुछ नहीं बता रहा है।

लाइन-लेवल attribution में एक shelf life समस्या भी है। एक ट्रेस कहता है “Claude ने commit abc123 पर लाइन 10-50 लिखी।” दो commits बाद, कोई उस ब्लॉक को रिफॉर्मेट करता है या उससे एक फंक्शन निकालता है। स्पेसिफिकेशन का जवाब git blame के माध्यम से chain करना है, और कंटेंट हैश उस कोड को ट्रैक करने में मदद कर सकते हैं जो घूमता है। लेकिन rebase और squash-merges वाले workflows में, chain टूट जाती है। ये कठिन समस्याएं हैं — वह प्रकार जिसे एक शुरुआती RFC को सामने लाना चाहिए।

गायब कार्रवाई

स्पेसिफिकेशन स्पष्ट रूप से स्पष्ट उपयोगों को अस्वीकार करता है: कोड ownership के लिए नहीं, quality assessment के लिए नहीं, training data provenance के लिए नहीं। यह “पारदर्शिता” कहता है। लेकिन पारदर्शिता एक साधन है, अंत नहीं।

यदि कोड review और tests पास करता है, तो क्योंकि एक LLM ने इसे लिखा है, क्या बदलता है? यदि यह buggy है, तो आप इसे वैसे भी ठीक करते हैं। स्पेसिफिकेशन कभी भी attribution को किसी ठोस कार्रवाई से नहीं जोड़ता। डेटा अंदर जाता है, लेकिन जवाब निकालने का कोई परिभाषित तरीका नहीं है। यही अंतर है — फॉर्मेट नहीं, बल्कि use case।

जहां यह दिलचस्प हो जाता है

यह वह है जो मुझे लगता है कि Agent Trace वास्तव में इंगित कर रहा है, भले ही स्पेसिफिकेशन अभी तक इसे नहीं कहता।

हर LLM-जेनरेटेड फंक्शन के पीछे reasoning tokens, गलत मोड़, retries, context switches, और tool invocations हैं। एक एजेंट केवल कोड उत्पन्न नहीं करता — यह वहां पहुंचने के लिए एक प्रक्रिया से गुजरता है। यह फ़ाइलें पढ़ता है, एक interface को गलत समझता है, backtrack करता है, एक अलग approach की कोशिश करता है, एक test चलाता है, failure को ठीक करता है, और एक solution पर पहुंचता है। वह प्रक्रिया final diff में अदृश्य है।

हुक पहले से ही केवल attribution से अधिक कैप्चर करता है। input surface को देखें:

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

मॉडल, सत्र, बातचीत, टूल, कमांड, अवधि, क्या यह एक background agent है, composer mode, हर tool invocation अपने input के साथ। यह केवल attribution data नहीं है। यह प्रक्रिया डेटा है। और प्रक्रिया डेटा वह जगह है जहां वास्तविक मूल्य रहता है:

• मूल्यांकन। कौन से मॉडल किन पैटर्न के साथ संघर्ष करते हैं? एक फंक्शन जिसने एक shot लिया वह उससे अलग है जिसने बारह retries लिए — भले ही output समान हो। “किसने इसे लिखा” नहीं बल्कि “इसे उत्पादित करना कितना कठिन था।”
• Agent-native codebases। यदि agents लगातार एक module के साथ संघर्ष करते हैं — बहुत सारे गलत मोड़, उच्च retry दरें, बार-बार context confusion — यह एक संकेत है कि कोड agents के काम करने के तरीके के लिए संरचित नहीं है। आप clarity के लिए, बेहतर interfaces के लिए, अधिक स्पष्ट contracts के लिए refactor कर सकते हैं। ट्रेस डेटा एक नक्शा बन जाता है जहां आपका codebase LLM सहयोग के लिए प्रतिकूल है।
• प्रक्रिया अनुकूलन। कौन से tool configurations बेहतर पहले-प्रयास कोड उत्पन्न करते हैं? कौन से prompting पैटर्न backtracking को कम करते हैं? आप line attribution से इनका उत्तर नहीं दे सकते। आपको यात्रा चाहिए, गंतव्य नहीं।

सही प्रश्न

Agent Trace प्रारंभिक है। यह attribution modeling, range durability, और query semantics के आसपास वास्तविक चुनौतियों वाला एक RFC है। लेकिन प्रवृत्ति सही है — जैसे-जैसे LLMs अधिक कोड लिखते हैं, हमें structured data की आवश्यकता है कि यह कैसे होता है।

इस स्पेसिफिकेशन का सबसे उपयोगी संस्करण “LLM ने क्या लिखा?” नहीं बल्कि “LLM वहां कैसे पहुंचा?” हो सकता है। लाइन-लेवल ledger एक शुरुआती बिंदु है। प्रक्रिया ट्रेस — reasoning, iterations, एक solution तक पहुंचने की लागत — वह जगह है जहां यह कुछ ऐसा बन जाता है जिसे teams वास्तव में LLMs के साथ बेहतर कोड लिखने के लिए उपयोग करती हैं।

यह वह स्पेसिफिकेशन है जिस पर मैं निर्माण करना चाहूंगा।