हर AI कोडिंग एजेंट एक diff दे सकता है। असली समस्या यह जानने में है कि क्या वह diff एक केंद्रित और सुविचारित प्रक्रिया से आया है—या फिर आपके रिपॉजिटरी में की गई एक ऐसी हड़बड़ी भरी खोज से, जो संयोगवश सही नतीजे पर पहुँच गई। फिलहाल, अधिकांश टीमें इस अंतर को नहीं पहचान पाती हैं।

यह कोई तकनीकी सीमा नहीं है। यह विजिबिलिटी (visibility) की समस्या है।

जब कोई एजेंट प्रोडक्शन कोड की तीन लाइनें लिखता है, तो हो सकता है कि उसने केवल तीन फाइलें पढ़ी हों और टेस्ट चलाए हों। या फिर हो सकता है कि उसने चालीस असंबंधित फाइलों को छुआ हो, दर्जनों विफल कमांड चलाए हों, डिपेंडेंसी इंस्टॉल न होने के कारण आपके टेस्ट सुइट को छोड़ दिया हो, और इस सब के लिए आपसे शुल्क भी लिया हो। दोनों ही स्थितियों में diff बिल्कुल एक जैसा दिखता है। यात्रा का रिकॉर्ड न होने पर, आप केवल परिणाम की गुणवत्ता का अनुमान ही लगा सकते हैं।

चैट लॉग्स (Chat Logs) रसीदें (Receipts) क्यों नहीं हैं

कई टूल्स काम के प्रमाण के रूप में चैट ट्रांसक्रिप्ट (chat transcript) देते हैं। ट्रांसक्रिप्ट कोई रसीद नहीं है। यह आपकी मेज पर बिखरे हुए पुर्जों के एक डिब्बे की तरह है। इसमें हर विचार चक्र (thought loop), हर विफल प्रयास, हर सिस्टम प्रॉम्प्ट और हर अप्रासंगिक टूल कॉल शामिल होता है। यदि आपको तीन लाइन के पैच को सत्यापित करने के लिए बातचीत की हज़ार लाइनें पढ़नी पड़ती हैं, तो आपका रिव्यू वर्कफ़्लो पहले से ही खराब हो चुका है।

मानवीय ध्यान सीमित है। एजेंट का उद्देश्य संज्ञानात्मक प्रयास (cognitive effort) को बचाना है, न कि होमवर्क बढ़ाना। एक ट्रांसक्रिप्ट रिव्यूअर को जासूस बनने पर मजबूर करती है। एक रसीद उन्हें एक नज़र में ही जवाब दे देती है।

एक उपयोगी रसीद एक व्यावहारिक सारांश (practical summary) होती है। यह आपको बताती है कि एजेंट को क्या करने के लिए कहा गया था, उसने वास्तव में क्या किया, और वह अपने निष्कर्ष तक कैसे पहुँचा। यह विफलता को छुपाती नहीं है, बल्कि उसे उजागर करती है।

एक अच्छी रसीद कैसी दिखती है

एक समीक्षा योग्य (reviewable) रसीद को बिना गहराई में जाए विशिष्ट प्रश्नों के उत्तर देने चाहिए:

  • कार्य क्या था? इच्छित परिवर्तन का एक स्पष्ट विवरण, न कि केवल एक अस्पष्ट प्रॉम्प्ट की प्रतिध्वनि।
  • कौन सी फाइलें पढ़ी गईं? ताकि आप यह आंक सकते हैं कि क्या एजेंट ने सही स्रोतों से संदर्भ (context) बनाया।
  • किन फाइलों को संपादित (edit) किया गया? परिवर्तन का अंतिम प्रभाव (footprint)।
  • कौन से कमांड चलाए गए? बिल्ड स्टेप्स, लिंटर्स, फॉर्मैटर्स, या वे कस्टम स्क्रिप्ट्स जिन्हें एजेंट ने कॉल किया।
  • कौन से कमांड विफल रहे? केवल सफलताएँ ही नहीं। विफलताएँ बताती हैं कि एजेंट को कहाँ सुधार करना पड़ा या उसने कहाँ हार मान ली।
  • कौन से टेस्ट पास हुए या छोड़ दिए गए? छोड़े गए टेस्ट एक चेतावनी (red flag) हैं। रसीद में यह बताया जाना चाहिए कि उन्हें क्यों छोड़ा गया।
  • कुल लागत क्या थी? टोकन, API कॉल और कंप्यूट समय। इसमें केवल मॉडल ही नहीं, बल्कि आपके आर्किटेक्चर की लागत भी शामिल है।

यह फॉर्मेट रिव्यू को एक पुरातात्विक खुदाई (archaeological dig) के बजाय एक त्वरित सैनिटी चेक (sanity check) में बदल देता है। एक सीनियर इंजीनियर रसीद को देखकर एक मिनट से भी कम समय में कह सकना चाहिए कि "यह सही लग रहा है" या "यह संदिग्ध लग रहा है।"

केवल इतिहास नहीं, बल्कि फुटप्रिंट (Footprint) पढ़ें

एजेंट रन का फुटप्रिंट काम के स्वरूप को दर्शाता है। क्या एजेंट टिकट की सीमाओं के भीतर रहा? या वह असंबंधित मॉड्यूल में भटक गया और उन चीजों को बदल दिया जिनकी किसी ने मांग नहीं की थी? एक रसीद जो "Files Read" के साथ "Files Edited" को सूचीबद्ध करती है, इसे स्पष्ट कर देती है।

फुटप्रिंट दोहराव (repetition) को भी उजागर करता है। एक एजेंट जो बार-बार एक ही गतिरोध (dead end) पर पहुँचता है—जैसे एक ही कॉन्फ़िग फ़ाइल को तीन बार पढ़ना, या बार-बार विफल होने वाले टेस्ट को चलाना—वह कंप्यूट और कॉन्टेक्स्ट विंडो (context window) को बर्बाद कर रहा है। वह पैटर्न दिखाई देना चाहिए। यदि किसी एजेंट को माइग्रेशन स्क्रिप्ट चलाने में नौ प्रयास लगे, तो रसीद में ऐसा लिखा होना चाहिए। यह जानकारी आपके आउटपुट के मूल्यांकन के तरीके को बदल देती है। ब्रूट-फोर्स अराजकता (brute-force chaos) के माध्यम से तैयार किया गया एक "सही" diff, सफाई से तैयार किए गए सही diff के समान नहीं है।

खराब डिज़ाइन की छिपी हुई लागत

लागत केवल प्रति टोकन की कीमत नहीं है। एक खराब तरीके से डिज़ाइन किया गया वर्कफ़्लो एजेंट को एक भी अक्षर लिखने से पहले ही महंगा बना देता है। भारी-भरकम टूल स्कीमा, अनावश्यक फ़ाइल इंडेक्सिंग और अत्यधिक व्यापक सिस्टम प्रॉम्प्ट, ये सभी कॉन्टेक्स्ट विंडो को बढ़ा देते हैं। रसीद को इस ओवरहेड (overhead) को उजागर करना चाहिए।

यदि जनरेशन (generation) सस्ता हो जाता है लेकिन रिव्यू कठिन हो जाता है, तो आपने कुछ भी हासिल नहीं किया है। आपने केवल बाधा (bottleneck) को एक जगह से दूसरी जगह स्थानांतरित कर दिया है। किसी टीम में इंजीनियर का समय आमतौर पर सबसे दुर्लभ संसाधन होता है। प्रति पुल रिक्वेस्ट (pull request) रिव्यू का समय तीस मिनट बढ़ाकर API लागत में पाँच डॉलर बचाना एक बहुत ही बुरा सौदा है। रसीद आपको इस सौदे का सीधे ऑडिट करने में मदद करती है।

ईमानदारी एक फीचर है

एक उपयोगी रसीद को आवश्यकता पड़ने पर असहज करने वाला होना चाहिए। इसे ऐसे तथ्यों की रिपोर्ट करनी चाहिए जो एजेंट को अक्षम (inefficient) दिखाएं, क्योंकि वह ईमानदारी अगले मानवीय निर्णय को तेज़ और बेहतर बनाती है।

उदाहरण महत्वपूर्ण हैं:

  • "Read 37 files for a one-line change."
  • "Skipped tests because npm install failed with a peer dependency conflict."
  • "Edited utils.py outside the requested scope to fix an import the agent introduced."
  • "Ran the linter 4 times; first three failed due to path misconfiguration."

These are not bugs in the receipt. They are signals. They tell the reviewer where to focus skepticism. They also tell the platform team where the workflow itself needs tightening.

Smaller Runs, Clearer Oversight

There is a natural temptation to let agents run wild across large surfaces. One giant prompt to refactor an entire service feels fast. It is not. It creates an unreviewable lump of work. Your afternoon disappears into tracing which of eighty changed files were intentional.

Small, inspectable runs are better. Define clear boundaries for the task. Separate the list of files the agent may read from the list it may write. Capture a history of failed commands so the dead ends are visible. Flag skipped verifications explicitly. Note every external tool use, from search APIs to test runners.

The goal is not total autonomy. Total autonomy that no human can verify is just automation with liability. The real goal is reviewability. Every agent output should be easy to approve or easy to reject. There should be no ambiguous middle ground where you accept code because you are too tired to investigate.

The Test for Any Coding Agent

Before adopting any agent or platform, ask one question: Can it leave enough evidence for a human to approve the next step confidently?

If the answer is yes, the tool fits into a professional workflow. If the answer is no, you are not buying productivity. You are buying a mystery that occasionally compiles. That is fine for a weekend side project. It is unacceptable for production engineering.

Teams that treat agent outputs as unexamined gifts will eventually ship a subtle bug introduced by an undetected scope creep. The diff will look innocent. The receipt would have told the truth.

Require receipts. Design for review. Trust is not a strategy. Evidence is.

For more hands-on discussions around AI tooling and developer workflows, you can join the community at GyaanSetu on Telegram.