प्रत्येक AI कोडिंग एजंट 'diff' देऊ शकतो. खरी समस्या ही आहे की तो diff एका केंद्रित आणि विचारपूर्वक केलेल्या प्रक्रियेतून आला आहे की तुमच्या रिपॉझिटरीमध्ये (repository) वेड्यावाकड्या पद्धतीने फिरताना चुकून योग्यतेकडे पोहोचला आहे, हे ओळखणे. सध्या, बहुतेक टीम्समधील लोकांना यातील फरक सांगता येत नाही.
ही तांत्रिक मर्यादा नाही. ही दृश्यमानतेची (visibility) समस्या आहे.
जेव्हा एखादा एजंट प्रॉडक्शन कोडच्या (production code) तीन ओळी लिहितो, तेव्हा त्याने कदाचित तीन फाइल्स वाचल्या असतील आणि टेस्ट्स रन केल्या असतील. किंवा त्याने चाळीस असंबद्ध फाइल्सना स्पर्श केला असेल, डझनभर अयशस्वी कमांड्स रन केल्या असतील, डिपेंडन्सी इन्स्टॉलेशन (dependency install) बिघडल्यामुळे तुमची टेस्ट सुईट (test suite) वगळली असेल आणि त्या बदल्यात तुम्हाला पैसे आकारले असतील. दोन्ही परिस्थितीत diff सारखाच दिसतो. प्रवासाचा रेकॉर्ड असल्याशिवाय, अंतिम निकालाच्या गुणवत्तेबद्दल तुम्ही फक्त अंदाज लावू शकता.
चॅट लॉग्स (Chat Logs) हे पावत्या (Receipts) का नाहीत
अनेक टूल्स कामाचा पुरावा म्हणून चॅट ट्रान्सक्रिप्ट (chat transcript) देतात. ट्रान्सक्रिप्ट म्हणजे पावती नाही. ती तुमच्या टेबलावर टाकलेल्या सुट्या भागांच्या पेटीसारखी आहे. त्यात प्रत्येक विचार प्रक्रिया (thought loop), प्रत्येक अयशस्वी प्रयत्न, प्रत्येक सिस्टम प्रॉम्प्ट (system prompt) आणि प्रत्येक असंबद्ध टूल कॉल (tool call) समाविष्ट असतो. जर तुम्हाला तीन ओळींच्या पॅचची (patch) पडताळणी करण्यासाठी हजारो ओळींचे संभाषण वाचावे लागत असेल, तर तुमची रिव्ह्यू वर्कफ्लो (review workflow) आधीच बिघडलेली आहे.
मानवी लक्ष मर्यादित असते. एजंटचा उद्देश संज्ञानात्मक कष्ट (cognitive effort) वाचवणे हा आहे, गृहपाठ देणे नाही. ट्रान्सक्रिप्ट रिव्ह्यूअरला डिटेक्टिव्ह बनण्याची मागणी करते. पावती त्यांना एका नजरेत उत्तर देते.
एक उपयुक्त पावती म्हणजे एक व्यावहारिक सारांश असतो. एजंटला काय करण्यास सांगितले होते, त्याने प्रत्यक्षात काय केले आणि तो त्याच्या निष्कर्षापर्यंत कसा पोहोचला, हे ती तुम्हाला सांगते. ती अपयशाला लपवत नाही, तर त्यावर प्रकाश टाकते.
एक चांगली पावती कशी दिसते
रिव्ह्यू करता येण्याजोगी पावतीने सखोल शोध न घेता विशिष्ट प्रश्नांची उत्तरे दिली पाहिजेत:
- काम काय होते? अपेक्षित बदलाचे स्पष्ट वर्णन, केवळ अस्पष्ट प्रॉम्प्टची पुनरावृत्ती नाही.
- कोणत्या फाइल्स वाचल्या गेल्या? जेणेकरून एजंटने योग्य स्रोतांकडून संदर्भ (context) तयार केला आहे की नाही, याचा तुम्ही निर्णय घेऊ शकाल.
- कोणत्या फाइल्स एडिट केल्या गेल्या? बदलाचा अंतिम ठसा (footprint).
- कोणत्या कमांड्स रन केल्या गेल्या? बिल्ड स्टेप्स (build steps), लिंटर्स (linters), फॉरमॅटर्स (formatters) किंवा एजंटने वापरलेले कस्टम स्क्रिप्ट्स.
- कोणत्या कमांड्स अयशस्वी झाल्या? केवळ यश नाही. अपयश हे दर्शवते की एजंटला कुठे तात्पुरते उपाय (improvise) करावे लागले किंवा त्याने कुठे हार मानली.
- कोणत्या टेस्ट्स पास झाल्या किंवा वगळल्या गेल्या? वगळलेल्या टेस्ट्स हे धोक्याचे संकेत (red flag) आहेत. पावतीमध्ये ते का वगळले गेले, हे नमूद केले पाहिजे.
- एकूण खर्च किती होता? टोकन्स (tokens), API कॉल्स आणि कम्प्युट वेळ (compute time). यामध्ये केवळ मॉडेलचाच नाही, तर तुमच्या आर्किटेक्चरचाही खर्च समाविष्ट आहे.
हा फॉरमॅट रिव्ह्यूला पुरातत्वीय उत्खननाऐवजी (archaeological dig) एक जलद सॅनिटी चेक (sanity check) बनवतो. एका वरिष्ठ इंजिनिअरला पावती स्कॅन करून एका मिनिटाच्या आत "हे योग्य वाटते" किंवा "हे संशयास्पद वाटते" असे म्हणता आले पाहिजे.
केवळ इतिहास नाही, तर ठसा (Footprint) वाचा
एजंटच्या रनचा ठसा कामाचे स्वरूप दर्शवतो. एजंट तिकीटच्या (ticket) मर्यादेत राहिला का? की तो असंबद्ध मॉड्यूल्समध्ये (modules) शिरला आणि ज्या गोष्टींची कोणीही मागणी केली नव्हती त्या बदलल्या? "Files Read" सोबत "Files Edited"ची यादी देणारी पावती हे स्पष्ट करते.
ठसा पुनरावृत्ती देखील दर्शवतो. जो एजंट वारंवार एकाच अडचणीत अडकत राहतो—उदा. एकच कॉन्फिग फाईल तीन वेळा वाचणे किंवा अयशस्वी टेस्ट वारंवार रन करणे—तो कम्प्युट आणि कॉन्टेक्स्ट विंडो (context window) वाया घालवत आहे. तो पॅटर्न दृश्यमान असावा. जर एखाद्या एजंटला मायग्रेशन स्क्रिप्ट (migration script) रन करण्यासाठी नऊ प्रयत्न लागले असतील, तर पावतीमध्ये तसे नमूद केले पाहिजे. ही माहिती तुम्ही आउटपुटचे मूल्यमापन कसे करता हे बदलते. 'ब्रूट-फोर्स गोंधळातून' (brute-force chaos) तयार झालेला "योग्य" diff आणि स्वच्छ पद्धतीने तयार झालेला "योग्य" diff एकसारखे नसतात.
खराब डिझाइनचा छुपा खर्च
खर्च म्हणजे केवळ प्रति टोकन किंमत नाही. खराब डिझाइन केलेला वर्कफ्लो एजंटला एक अक्षरही तयार करण्यापूर्वीच महाग बनवतो. फुगलेले टूल स्कीमा (tool schemas), अनावश्यक फाईल इंडेक्सिंग आणि अतिशय व्यापक सिस्टम प्रॉम्प्ट्समुळे कॉन्टेक्स्ट विंडो वाढते. पावतीने हा अतिरिक्त खर्च (overhead) उघड केला पाहिजे.
जर जनरेशन स्वस्त झाले पण रिव्ह्यू कठीण झाला, तर तुम्हाला काहीच फायदा झालेला नाही. तुम्ही फक्त अडथळा (bottleneck) एका ठिकाणाहून दुसऱ्या ठिकाणी हलवला आहे. इंजिनिअरचा वेळ हा सहसा टीममधील सर्वात दुर्मिळ स्त्रोत असतो. प्रत्येक पुल रिक्वेस्ट (pull request) साठी रिव्ह्यूचा वेळ तीस मिनिटे वाढवून API खर्चात पाच डॉलर्स वाचवणे हा एक अत्यंत वाईट व्यवहार आहे. पावती तुम्हाला या व्यवहाराचे थेट ऑडिट करण्यास मदत करते.
प्रामाणिकपणा हे एक वैशिष्ट्य आहे
एक उपयुक्त पावती आवश्यकतेनुसार अस्वस्थ करणारी असावी. तिने असे तथ्य सादर केले पाहिजे ज्यामुळे एजंट अकार्यक्षम वाटेल, कारण त्या प्रामाणिकपणामुळे मानवाचा पुढचा निर्णय अधिक जलद आणि चांगला होतो.
उदाहरणे महत्त्वाची आहेत:
- "एका ओळीच्या बदलासाठी ३७ फाइल्स वाचल्या."
- "
npm installमध्ये peer dependency conflict झाल्यामुळे टेस्ट्स वगळल्या." - "एजंटने केलेल्या एका import दुरुस्त करण्यासाठी, विनंती केलेल्या व्याप्तीबाहेर (scope)
utils.pyमध्ये बदल केले." - "Linter ४ वेळा चालवला; पहिले तीन वेळा path misconfiguration मुळे अयशस्वी झाले."
हे रिसीटमधील (receipt) बग्स नाहीत. ते संकेत आहेत. ते रिव्ह्यूअरला कुठे शंका घ्यायची आहे हे सांगतात. ते प्लॅटफॉर्म टीमला हे देखील सांगतात की वर्कफ्लोमध्ये नेमकी कुठे सुधारणा करण्याची गरज आहे.
लहान रन, स्पष्ट देखरेख
एजंट्सना मोठ्या क्षेत्रावर मुक्तपणे काम करू देण्याची एक नैसर्गिक ओढ असते. संपूर्ण सर्व्हिस रिफॅक्टर करण्यासाठी एक मोठा प्रॉम्प्ट देणे जलद वाटते. पण तसे नाही. यामुळे कामाचा असा एक मोठा ढिगारा तयार होतो ज्याचे रिव्ह्यू करणे अशक्य होते. बदललेल्या ८० फाइल्सपैकी कोणत्या फाइल्समध्ये केलेले बदल हेतुपुरस्सर होते, हे शोधण्यात तुमचा संपूर्ण दुपार निघून जाईल.
लहान आणि तपासण्यायोग्य (inspectable) रन करणे अधिक चांगले आहे. कामासाठी स्पष्ट मर्यादा (boundaries) निश्चित करा. एजंट ज्या फाइल्स वाचू शकतो आणि ज्या फाइल्स लिहू शकतो, या दोन्ही याद्या वेगळ्या ठेवा. अयशस्वी कमांड्सचा इतिहास (history) जतन करा जेणेकरून अडथळे स्पष्टपणे दिसतील. वगळलेल्या (skipped) पडताळणीला स्पष्टपणे सूचित करा. सर्च APIs पासून ते टेस्ट रनर्सपर्यंत प्रत्येक बाह्य टूलच्या वापराची नोंद ठेवा.
ध्येय पूर्ण स्वायत्तता (total autonomy) मिळवणे हे नाही. ज्या स्वायत्ततेची कोणतीही व्यक्ती पडताळणी करू शकत नाही, ती केवळ जबाबदारीसह केलेली ऑटोमेशन आहे. खरे ध्येय रिव्ह्यूएबिलिटी (reviewability) हे आहे. एजंटचा प्रत्येक आउटपुट सहजपणे मंजूर किंवा नाकारण्यायोग्य असावा. असा कोणताही संदिग्ध मध्यमार्ग नसावा जिथे तुम्ही तपासण्यास खूप थकल्यामुळे कोड स्वीकारता.
कोणत्याही कोडिंग एजंटसाठी चाचणी
कोणताही एजंट किंवा प्लॅटफॉर्म स्वीकारण्यापूर्वी, एक प्रश्न विचारा: तो मानवाला पुढचे पाऊल आत्मविश्वासाने मंजूर करण्यासाठी पुरेसा पुरावा (evidence) देऊ शकतो का?
जर उत्तर 'हो' असेल, तर ते टूल व्यावसायिक वर्कफ्लोमध्ये योग्य ठरते. जर उत्तर 'नाही' असेल, तर तुम्ही उत्पादकता (productivity) विकत घेत नाही आहात. तुम्ही एक असे रहस्य विकत घेत आहात जे अधूनमधून कंपाईल (compile) होते. वीकेंड साईड प्रोजेक्टसाठी हे ठीक आहे, पण प्रोडक्शन इंजिनिअरिंगसाठी ते अस्वीकार्य आहे.
जे टीम्स एजंटच्या आउटपुटकडे न तपासता मिळालेली भेट समजतात, ते शेवटी अनडिटेक्टेड स्कोप क्रीपमुळे (undetected scope creep) निर्माण झालेला एखादा सूक्ष्म बग (subtle bug) रिलीज करतील. तो 'डिफ' (diff) निष्पाप वाटेल. रिसीटने सत्य सांगितले असते.
रिसीट्सची (receipts) आवश्यकता ठेवा. रिव्ह्यूसाठी डिझाइन करा. विश्वास ही रणनीती नाही. पुरावा ही रणनीती आहे.
AI टूलिंग आणि डेव्हलपर वर्कफ्लोबद्दल अधिक प्रत्यक्ष चर्चेसाठी, तुम्ही GyaanSetu on Telegram वर समुदायाला जोडू शकता.