कोडिंग एजंट्सचे मूल्यमापन करणाऱ्या इंजिनिअरिंग टीम्स सहसा चुकीच्या प्रश्नापासून सुरुवात करतात. त्यांना हे जाणून घ्यायचे असते की एजंट किती स्वायत्त (autonomous) होऊ शकतो. तो पाइपलाइनचा किती भाग स्वतः हाताळू शकतो? तो कोणालाही त्रास न देता स्पेसिफिकेशन (spec) लिहू शकतो का, रिपॉझिटरी एडिट करू शकतो का आणि प्रोडक्शनमध्ये पुश करू शकतो का? डेमोमुळे या गोष्टीचा मोह निर्माण करणे सोपे जाते. तुम्हाला एक उत्कृष्ट वर्कफ्लो दिसतो जिथे एका सिंगल प्रॉम्प्टमुळे अनेक एडिट्स आणि डिप्लॉयमेंट्सची साखळी सुरू होते, आणि तुमच्या संस्थेतही तीच क्षमता मिळवण्याची इच्छा प्रबळ होते. पण चकाकी हा डिझाइनचा खराब सिद्धांत आहे. अधिक महत्त्वाचे प्रश्न खूप कमी रोमांचक आहेत: या गोष्टीला अधिकार कोणी दिला, ती प्रत्यक्षात कोणत्या सिस्टम्सना स्पर्श करू शकते आणि जेव्हा ती अपरिहार्यपणे काहीतरी चूक करते तेव्हा काय होते?
स्वायत्ततेचा सापळा
रोमांचक स्वायत्तता हा एक सापळा आहे. हे आपल्याला अशा बॉट्सचे कौतुक करण्यास प्रवृत्त करते जे स्पेसिफिकेशन तयार करतात, रिपॉझिटरीमध्ये बदल करतात आणि कोड डिप्लॉय करतात, आणि शांतपणे काम पूर्ण झाल्याचा दावा करतात. हे इंजिनिअरिंग नाही. हे 'शेल ॲक्सेस'सह (shell access) अंधाधुंद विश्वास ठेवण्यासारखे आहे. काम तयार करणे खूपच सोपे होते. कोणतेही मॉडेल काही सेकंदात कोड, डॉक्युमेंटेशन किंवा आर्किटेक्चर प्लॅन्स तयार करू शकते. पण सॉफ्टवेअर डेव्हलपमेंटमधील खरा खर्च कधीही टायपिंग स्पीडवर अवलंबून नव्हता. तो नेहमीच व्हॅलिडेशन (validation), रिव्ह्यू (review) आणि "हो, हे बरोबर आहे आणि शिप करण्यासाठी सुरक्षित आहे" असा काळजीपूर्वक घेतलेला निर्णय असतो. जनरेट केलेले काम स्वस्त असते. मंजुरी (Approval) महाग असते. ज्या कंपन्या मंजुरीची प्रक्रिया स्वच्छ आणि सुसंगतपणे कशी हाताळायची हे समजून घेतील, त्याच खऱ्या अर्थाने विश्वसनीय सिस्टम्स तयार करू शकतील.
सेल्फ-रिव्ह्यू का अपयशी ठरतो
धोके अंदाजित स्वरूपात दिसून येतात. एक मॉडेल प्लॅन तयार करते आणि नंतर तो प्लॅन चांगला आहे की नाही याचे मूल्यमापन करते. एक एजंट तुमचा कोडबेस एडिट करतो आणि त्याचे बदल सुरक्षित का आहेत हे तुम्हाला समजावून सांगतो. एक टूल कमांड एक्झिक्युट करते आणि परवानगी घेण्याऐवजी माफी मागते. यातील प्रत्येक गोष्ट एकाच मूळ अपयशाचे प्रतिनिधित्व करते. जर एखादा एजंट स्पेसिफिकेशन तयार करत असेल, तर ते सत्य मानण्यापूर्वी त्या एजंटच्या बाहेरच्या एखाद्या गोष्टीने त्यावर स्वाक्षरी (sign off) करणे आवश्यक आहे. जर एखादा एजंट कोडमध्ये बदल करत असेल, तर वेगळ्या प्रक्रियेने 'डिफ' (diff) तपासणे आवश्यक आहे. जनरेटरला स्वतःचा व्हॅलिडेटर म्हणून काम करू देणे हा कोणताही शॉर्टकट नाही. तो सोयीच्या नावाखाली लपवलेला एक स्ट्रक्चरल बग (structural bug) आहे.
प्रॉम्प्ट्स म्हणजे परवानगी देणारी यंत्रणा नाही
तुम्ही चतुर शब्दावलीने एजंटला सुरक्षित करू शकत नाही. मॉडेलला सावध राहण्यास किंवा काहीतरी डिलीट करण्यापूर्वी विचारण्यास सांगणे म्हणजे सीमा (boundary) तयार करणे नव्हे. प्रॉम्प्ट्स म्हणजे परवानगी देणारी यंत्रणा (permission systems) नाहीत. तुम्ही एजंटला प्रोडक्शनच्या जवळ नेण्यापूर्वी, त्याच्या क्षमतांची प्रामाणिक तपासणी करणे आवश्यक आहे. तो संपूर्ण रिपॉझिटरी वाचू शकतो का? तो शेल कमांड्स एक्झिक्युट करू शकतो का? तो ब्राउझर उघडू शकतो का? तो ग्राहकांचा डेटा त्याच्या कॉन्टेक्स्ट विंडोमध्ये (context window) घेऊ शकतो का? बहुतेक टीम्सना याची पूर्ण उत्तरे माहित नसतात. त्यांना वाटते की टूल फक्त सँडबॉक्समध्ये (sandbox) मर्यादित आहे, परंतु प्रत्यक्षात त्याच्याकडे क्रिटिकल पाथ्सवर (critical paths) 'राईट ॲक्सेस' (write access) असतो. आधी पृष्ठभागाचे क्षेत्र (surface area) मॅप करा. मग भिंती बांधा.
टियर्ड कंट्रोल सिस्टम तयार करा
एकदा तुम्हाला एजंट काय करू शकतो हे समजले की, जोखमीनुसार अडथळे (friction) ठरवणारी एक कंट्रोल सिस्टम डिझाइन करा. कमी जोखमीच्या कृती, जसे की अंतर्गत डॉक्युमेंटेशन अपडेट करणे किंवा कोड फॉरमॅटिंग करणे, आपोआप चालू शकतात. मध्यम जोखमीच्या कृती, जसे की मॉड्यूल रिफॅक्टरिंग करणे किंवा नवीन डिपेंडन्सी जोडणे, अशा चेकपॉइंटवर येणे आवश्यक आहे जिथे एखादा माणूस किंवा पडताळलेली टेस्ट सुईट (test suite) त्या कृतीची पुष्टी करेल. उच्च जोखमीच्या कृती, जसे की प्रोडक्शनमध्ये डिप्लॉय करणे, इन्फ्रास्ट्रक्चरमध्ये बदल करणे किंवा संवेदनशील डेटा वापरणे, यासाठी अशा वेगळ्या मंजुरीकर्त्याची (approver) गरज आहे जो जनरेशन प्रक्रियेत सामील नव्हता. प्रत्येक कृतीचा ऑडिट ट्रेल (audit trail) असणे आवश्यक आहे. नक्की कोणत्या फाईल्स वाचल्या गेल्या, कोणते टूल्स वापरले गेले आणि कोणते निर्णय घेतले गेले, हे तुम्ही पुन्हा पाहू शकले पाहिजे. एजन्टिक डेव्हलपमेंट (Agentic development) म्हणजे रिव्ह्यू वगळण्याचा परवाना नाही. कंटाळवाणा अडथळा (Boring friction) हे एक वैशिष्ट्य आहे. जेव्हा गोष्टी भरकटू लागतात, तेव्हा योग्य अप्रूव्हल गेट सर्किट ब्रेकरप्रमाणे काम करते.
सीमा जोखमीनुसार ठरवा
तुमच्या सीमा प्रत्यक्ष धोक्यानुसार कॅलिब्रेट करा. प्रत्येक मार्कडाउन फॉरमॅटिंगमधील बदलाला अनुपालन (compliance) समारंभ बनवल्यास तुमच्या टीमचे काम थांबून जाईल. परंतु एजंट आत्मविश्वासाने वागत असल्यामुळे उच्च-धोका असलेल्या कृतींना निरुपद्रवी मानणे तितकेच मूर्खपणाचे आहे. ध्येय प्रमाणात नियंत्रण ठेवणे हे आहे, नाट्यमय निर्बंध घालणे नाही.
आर्टिफॅक्ट्स लहान आणि निरीक्षणीय ठेवा
सर्वात उपयुक्त एजंट सिस्टम्स तुम्हाला मोठ्या स्वायत्त प्रक्रियांनी प्रभावित करण्याचा प्रयत्न करत नाहीत. ते लहान, पुनरावलोकन करण्यायोग्य आर्टिफॅक्ट्स तयार करतात. एक अचूक योजना. एक केंद्रित diff. एक वाचनीय लॉग. प्रचंड स्वायत्त अंमलबजावणी डीबग करणे हे एक दुस्वप्न असते. जेव्हा पन्नास फाईल्सच्या एजंट सेशननंतर काहीतरी बिघडते, तेव्हा तुम्हाला हेतू, अंमलबजावणी आणि त्याचे परिणाम (side effects) हे सर्व एकाच वेळी सोडवावे लागतात. प्रभावाचा विस्तार (blast radius) मर्यादित ठेवा. एजंटने कोणत्या फाईल्स वाचल्या आणि कोणती टूल्स वापरली, हे जाणून घेण्यावर आग्रह धरा. दृश्यमान (Observable) सिस्टम्स या देखभाल करण्यायोग्य (maintainable) सिस्टम्स असतात. 'ब्लॅक-बॉक्स' स्वायत्तता म्हणजे केवळ चांगल्या मार्केटिंगसह असलेले तांत्रिक कर्ज (technical debt) आहे.
प्रवेश देण्यापूर्वी सहा महत्त्वाचे प्रश्न
एजंटला कोणतीही वास्तविक जबाबदारी देण्यापूर्वी, सहा कठीण प्रश्नांद्वारे तुमच्या सेटअपची चाचणी घ्या.
- सिस्टमकडे प्रत्यक्षात कोणती क्षमता आहे?
- कोणत्या कृती बाय डिफॉल्ट नाकारल्या आहेत, ज्या सिस्टम प्रॉम्प्टमधील एका नम्र वाक्याने रोखण्याऐवजी इन्फ्रास्ट्रक्चर स्तरावर ब्लॉक केल्या आहेत?
- कोणत्या कृतींसाठी स्पष्ट मंजुरीची आवश्यकता आहे?
- एजंटने वापरण्यापूर्वी कोणते आर्टिफॅक्ट्स 'फ्रीझ' केले जातात, जेणेकरून तो स्वतःच्या इनपुट्समध्ये गुपचूप फेरफार करू शकणार नाही?
- जनरेटरपासून पूर्णपणे वेगळा असलेला कोणता व्हॅलिडेटर अंतिम आउटपुटची पडताळणी करतो?
- कोणता लॉग, कोणत्याही संभ्रमाशिवाय, नेमके काय घडले याचा पुरावा देतो?
ही मूलभूत इंजिनिअरिंग हायजीन आहे. जनरेटरला व्हॅलिडेटरपासून वेगळे ठेवा. मानवी अधिकार सीमेवर ठेवा.
खरी परीक्षा
तिथे