एजेंटिक कोडिंग अपनाने वाली ज़्यादातर टीमों में अड़चन कोड जेनरेशन से हटकर रिव्यू में आ जाती है. इस लूप को ठीक किए बिना स्पीड में कुल फ़ायदा लगभग ज़ीरो रहता है.
बड़े पैमाने के CI एनवायरनमेंट में (जहाँ हर रात लाखों टेस्ट चलते हैं और सैकड़ों इंजीनियर्स काम करते हैं) एजेंट का सबसे ज़्यादा फ़ायदेमंद काम कोड जेनरेट करना नहीं, बल्कि सही ओनर तक काम को पहुँचाना और उसकी ट्रायेज करना है.
एक काम आने वाला एजेंट आउटपुट सिर्फ़ पैटर्न मैच नहीं करता. वह जाँच में टिकता है और यह भी समझाता है कि कोई नतीजा क्यों आया.
एविडेंस जमा करने और सही कॉन्टेक्स्ट तैयार करने वाली लेयर को डिज़ाइन करना, जेनरेशन लेयर को डिज़ाइन करने से ज़्यादा मायने रखता है.
एजेंटिक कोडिंग पर ज़्यादातर चर्चा अभी भी एक आसान वादे से शुरू होती है: ज़्यादा कोड, और तेज़ी से लिखना.
कभी-कभी यह आगे बढ़कर एक बड़े विज़न में बदल जाता है, जहाँ एजेंट काम की प्लानिंग करते हैं, PR खोलते हैं और कम-से-कम इंसानी मदद के साथ बदलावों को शिप करते हैं. लेकिन ज़्यादातर इंजीनियरिंग टीमों के लिए नज़दीकी भविष्य में इसका सबसे साफ़ फ़ायदा इससे छोटा है. इसका मकसद इटरेशन की लागत को कम करना है.
सॉफ़्टवेयर डिलीवरी का मतलब सिर्फ़ कोड जेनरेशन नहीं है. कोड लिखना एक लंबे लूप का सिर्फ़ एक स्टेज है, जिसमें रिव्यू, टेस्टिंग, डिप्लॉयमेंट और कुछ गड़बड़ होने पर इन्वेस्टिगेशन भी शामिल हैं. जो ज़्यादातर टीमें रिव्यू लूप को दोबारा डिज़ाइन किए बिना एजेंटिक कोडिंग अपनाती हैं, उनमें अड़चन बस आगे के स्टेज पर चली जाती है.
सिर्फ़ कोड जेनरेशन तेज़ करने से टीम अपने-आप तेज़ नहीं हो जाती. इससे बस रिव्यू, वेरिफ़िकेशन और भरोसा बनाने में ज़्यादा मेहनत लग सकती है.
कई इंजीनियरिंग एनवायरनमेंट में सबसे ज़्यादा समय पहला ड्राफ़्ट तैयार करने में नहीं, बल्कि उस पर भरोसा करने में लगता है.
क्या इस बदलाव से वाकई में समस्या ठीक हुई या सिस्टम बेहतर हुआ? क्या इससे कहीं और कोई रिग्रेशन तो नहीं आया? फ़ेल होने की वजह कोड में है, एनवायरनमेंट में, टेस्ट्स में या किसी डिपेंडेंसी में? जो फ़िक्स सुझाया गया है, क्या वह फ़ेल होने की वजह को ठीक कर रहा है या सिर्फ़ दिखाई दे रहे लक्षण को?
एजेंट यहाँ मदद कर सकते हैं. इसका मतलब यह नहीं कि वे इंजीनियर्स की जगह ले लें. वे उलझे हुए एविडेंस पर एक स्ट्रक्चर्ड फ़र्स्ट पास कर सकते हैं: लॉग्स देखना, हाल के बदलावों की तुलना करना, ज़रूरी सिग्नल्स की समरी बनाना, संभावित वजहों को ट्रेस करना, जाँच करना, और ऐसे नतीजे देना, जिस पर लोग आगे सवाल कर सके.
कई टीमों में एजेंट का सबसे ज़्यादा फ़ायदा शुरुआत से पूरा कोड जेनरेट करने में नहीं है. एजेंट समस्या की संभावित वजहों और दायरे को कम कर सकता है, ताकि इंजीनियर को घंटों खुद से खोजबीन न करनी पड़े.
यह बात बड़े पैमाने के डिबगिंग वर्कफ़्लो में खास तौर पर साफ़ दिखती है. मान लीजिए रात में CI लाखों टेस्ट चला रहा है और सैकड़ों इंजीनियर्स द्वारा बदले गए कोडबेस पर काम कर रहा है (हमारे एक क्लाइंट के यहाँ यह सच में होता है). जब कोई चीज़ फ़ेल होती है, तो यह पता लगाना मुश्किल होता है कि इसे कौन संभाले. समस्या ऐप्लिकेशन कोड में हो सकती है, किसी डिपेंडेंसी में, टेस्ट हार्नेस में या स्टैक के किसी और हिस्से में. लॉग्स कई गीगाबाइट तक हो सकते हैं और जिस टीम को सबसे पहले समस्या दिखती है, ज़रूरी नहीं कि वही टीम उस समस्या की ज़िम्मेदारी लेती हो.
ऐसे वर्कफ़्लो में आमतौर पर किसी एक एजेंट से फ़िक्स नहीं लिखवाया जाता है. यहाँ ऐसे सिस्टम की ज़रूरत होती है, जो समस्या के संभावित दायरे को छोटा कर सके.
एक काम आने वाली पाइपलाइन लॉग्स निकाल कर ला सकती है, ज़रूरी एविडेंस चुन सकती है, काम की चीज़ों की समरी बना सकती है, सैंडबॉक्स में कोड देख सकती है और कॉन्फ़िडेंस स्कोरिंग, ट्रेसेबिलिटी और अगले स्टेप्स के सुझावों के साथ एक स्ट्रक्चर्ड रूट-कॉज़ एनालिसिस तैयार कर सकती है. कॉन्फ़िडेंस स्कोर तैयार करने के लिए एक सब्जेक्ट मैटर एक्सपर्ट एजेंट के शुरुआती आउटपुट को मार्क करता है. इसके बाद इस आउटपुट को LLM-as-a-judge में दिया जाता है, ताकि आगे की स्कोरिंग ऑटोमेट की जा सके और साथ ही इंसानी जजमेंट के साथ अलाइनमेंट बना रहे.
मकसद इंजीनियरिंग जजमेंट को खत्म करना नहीं है, बल्कि रिव्यू करने वालों को एक बेहतर शुरुआती पॉइंट देना है. रिग्रेशन ट्रायेज, PR रिव्यू, टेस्ट रिपेयर, रिलीज़ वैलिडेशन और डिप्लॉयमेंट के बाद की इन्वेस्टिगेशन, इन सभी का स्ट्रक्चर एक जैसा है. इनमें बहुत सारा एविडेंस होता है, रिव्यू की ज़रूरत होती है और कई चीज़ें साफ़ नहीं होतीं. इनमें एजेंट से इंजीनियरिंग प्रोसेस की जगह लेने को नहीं कहा जाता, बल्कि प्रोसेस को आगे बढ़ाने में मदद करने को कहा जाता है.
इसी वजह से टीमों को यह भी ध्यान रखना चाहिए कि वे इन सिस्टम्स का असेसमेंट कैसे करती हैं.
सही सवाल यह नहीं है कि कोई एजेंट अकेले में कुछ इम्प्रेसिव बना सकता है या नहीं. बेहतर सवाल यह है कि क्या यह कहीं और कोई नई रुकावट पैदा किए बिना वर्कफ़्लो को बेहतर बनाता है.
इसका मतलब यह देखना है कि क्या आउटपुट इतना स्पेसिफ़िक है कि उसे वेरिफ़ाई किया जा सके, क्या वह सिर्फ़ पैटर्न मैच करने के बजाय वजह और नतीजे का कनेक्शन समझाता है और क्या वह रिव्यू को आसान बनाता है, मुश्किल नहीं. कोई जवाब सही लग सकता है, लेकिन इसका मतलब यह नहीं कि वह उपयोगी भी है. प्रैक्टिस में टीमें एजेंट के आउटपुट पर तब भरोसा करती हैं, जब वह बारीकी से जाँच में टिकता है और उन्हें ऐसी ठोस चीज़ देता है जिसकी वे जाँच कर सकें.
इससे एक बड़ी बात समझ आती है कि वाकई में काम आने वाले एजेंटिक सिस्टम सिर्फ़ जेनरेशन पर निर्भर नहीं करते. यह भी उतना ही ज़रूरी है कि एविडेंस कैसे जमा किया जाता है, कॉन्टेक्स्ट कैसे तैयार किया जाता है, आउटपुट कैसे चेक किए जाते हैं और रिव्यू करने वाले को यह साफ़ तौर पर समझ आता रहे कि किसी नतीजे पर कितना भरोसा किया जा सकता है.
इसी वजह से एजेंटिक इंजीनियरिंग का नज़दीकी भविष्य शायद ऐसा नहीं होगा कि एक ही बड़ी छलाँग में पूरी तरह ऑटोनॉमस सिस्टम बन जाए. ज़्यादा संभावना है कि कई अच्छी तरह डिज़ाइन किए गए छोटे-छोटे लूप बनें, जहाँ एजेंट टीमों को अपने काम को इंस्पेक्ट, रिव्यू, वेरिफ़ाई और रिफ़ाइन करने में मदद करें और हर स्टेप के बीच बेकार की मेहनत कम हो.
यह बड़ी ऑटोनॉमी वाली कहानी जितना ड्रामैटिक नहीं हो सकता, लेकिन यह इस बात के कहीं ज़्यादा करीब है कि वाकई में काम आने वाले सिस्टम असल में कैसे अपनाए जाते हैं.