AI कोडिंग टूल्स की चर्चा अब तक ज़्यादातर डेवलपर असिस्टेंट के रूप में ही होती रही है: कुछ कोड लिखना, किसी एरर को समझाना, टेस्ट बनाना, या किसी बदलाव को रिव्यू करने में मदद करना।
यह सीमा अब बदलने लगी है।
OpenAI ने हाल ही में अपना Agents API पेश किया, जो डेवलपर्स को ऐसे लंबे समय तक चलने वाले एजेंट बनाने का तरीका देता है जो फाइलों के साथ काम कर सकें, कोड चला सकें, टूल्स इस्तेमाल कर सकें और दूसरे एजेंट्स के साथ समन्वय कर सकें। OpenAI का कहना है कि ये एजेंट केवल एक प्रॉम्प्ट-और-रिस्पॉन्स तक सीमित न रहकर लंबे समय तक काम करते रह सकते हैं।
लगभग उसी समय, एक और घटनाक्रम ने अलग वजह से मेरा ध्यान खींचा: कहा जा रहा है कि OpenAI अपने ही pull requests के लिए AI को अनिवार्य सिक्योरिटी रिव्यूअर के तौर पर इस्तेमाल कर रहा है। अगर रिव्यू में कोई सिक्योरिटी समस्या मिलती है, तो मर्ज को रोका जा सकता है।
यह AI कोड रिव्यू का एक छोटा सा विस्तार लग सकता है।
लेकिन यह उतना छोटा नहीं है।
यह डेवलपर की मदद करने वाले AI से कोड आगे बढ़ सकता है या नहीं, इस फैसले का हिस्सा बनने वाले AI की ओर एक बदलाव को दिखाता है।
हम CI/CD में ऑटोमेशन पर पहले से ही भरोसा करते हैं
सॉफ्टवेयर का अपने-आप रुक जाना कोई असामान्य बात नहीं है।
एक pull request पहले से ही इन वजहों से रुक सकता है:
- बिल्ड फेल हो गया;
- यूनिट टेस्ट फेल हो गए;
- सिक्योरिटी स्कैनर को कोई वल्नरेबिलिटी मिली;
- ज़रूरी रिव्यूअर ने बदलाव को अभी तक स्वीकार नहीं किया;
- कोई पॉलिसी चेक पास नहीं हुआ।
इसलिए पाइपलाइन में एक और गेट के रूप में AI रिव्यू आना कोई बिल्कुल नया विचार नहीं है।
फर्क इस बात में है कि फैसला कैसे लिया जाता है।
एक टेस्ट आमतौर पर एक तय शर्त को जांचता है। अपेक्षित नतीजा पहले से पता होता है।
एक AI रिव्यूअर को शायद कोड पढ़ना पड़े, आसपास के लॉजिक को समझना पड़े, और यह तय करना पड़े कि कुछ असुरक्षित लग रहा है या नहीं। यह कहीं ज़्यादा निर्णय-आधारित फैसला है।
अगर यह निर्णय किसी मर्ज को रोक सकता है, तो AI अब सिर्फ सलाह देने वाला नहीं रह जाता। उसे डिलीवरी प्रोसेस के भीतर कुछ अधिकार दे दिया गया है।
इसका मतलब यह नहीं कि AI को हर चीज़ स्वीकृत करनी चाहिए
यहाँ एक महत्वपूर्ण फर्क है।
किसी संदिग्ध बदलाव को AI द्वारा रोकना, और किसी बदलाव को AI द्वारा सुरक्षित घोषित करना — ये दोनों एक जैसे नहीं हैं।
अगर मॉडल को कुछ ऐसा दिखे जो ऑथेंटिकेशन या ऑथराइज़ेशन की समस्या जैसा लगे, तो pull request को रोककर दोबारा जांच के लिए कहना उपयोगी हो सकता है।
लेकिन अगर मॉडल को कुछ नहीं मिलता, तो इसका अपने-आप यह मतलब नहीं होना चाहिए:
कोड सुरक्षित है।
इसका मतलब सिर्फ इतना है कि इस खास रिव्यू में कोई समस्या नहीं मिली।
सामान्य नियंत्रण—टेस्ट, सिक्योरिटी स्कैनिंग, कोड ओनरशिप और ह्यूमन रिव्यू—अब भी अपनी भूमिका निभाते हैं।
अगर AI गलती कर दे तो क्या होता है?
यहीं पर CI/CD गवर्नेंस महत्वपूर्ण हो जाता है।
मान लीजिए एक AI रिव्यूअर किसी pull request को रोक देता है, लेकिन इंजीनियर को पता है कि यह फाइंडिंग एक फॉल्स पॉज़िटिव है।
कुछ बिल्कुल सामान्य सवालों का साफ जवाब होना चाहिए:
इस रोक को कौन ओवरराइड कर सकता है?
क्या इस अपवाद की समीक्षा किसी और व्यक्ति को करनी होगी?
क्या कारण रिकॉर्ड किया जाता है?
क्या टीमें यह देख सकती हैं कि AI को कितनी बार ओवरराइड किया जा रहा है?
ये नियंत्रण इसलिए ज़रूरी नहीं हैं क्योंकि AI कोई खास तौर पर खतरनाक चीज़ है। ये इसलिए ज़रूरी हैं क्योंकि किसी भी अनिवार्य नियंत्रण को गलतियों से निपटने का एक तरीका चाहिए होता है।
इसका एक और पहलू भी है।
अगर AI ज़्यादा कोड लिखने लगे और एक और AI उसे रिव्यू करे, तो टीमों को यह मान लेने से बचना चाहिए कि दोनों AI कदम मिलकर अपने-आप एक स्वतंत्र वेरिफिकेशन दे देते हैं। हो सकता है दोनों सिस्टम एक ही तरह की समस्याओं को नज़रअंदाज़ कर दें।
यहीं से एजेंट गवर्नेंस व्यावहारिक रूप लेना शुरू करता है
Atlassian AI को सॉफ्टवेयर-डेवलपमेंट लाइफसाइकिल में और गहराई तक ले जाते हुए पहले से ही “गवर्न्ड एजेंट लूप्स” शब्द का इस्तेमाल कर रहा है।
यह दिशा समझ में आती है।
जैसे-जैसे एजेंट कोड लिखने, टूल्स चलाने, pull requests बनाने और डेवलपमेंट सिस्टम्स के बीच काम करने में सक्षम होते जा रहे हैं, सवाल अब सिर्फ यह नहीं रह गया है:
एजेंट क्या कर सकता है?
टीमों को यह भी पूछना होगा:
एजेंट को क्या तय करने की अनुमति है?
कई संगठनों के लिए, सही तरीका धीरे-धीरे आगे बढ़ना हो सकता है:
AI एक बदलाव सुझाता है।
फिर AI एक बदलाव तैयार करता है।
फिर AI एक बदलाव को रिव्यू करता है।
शायद बाद में, AI को कुछ बदलावों को रोकने की अनुमति दी जाए।
हर कदम सिस्टम को थोड़ी और ज़िम्मेदारी देता है।
यह किसी एजेंट को तुरंत कोड लिखने, उसे स्वीकृत करने और डिप्लॉय करने देने से बिल्कुल अलग है।
सबसे अहम बदलाव
OpenAI के Agents API का दिलचस्प हिस्सा सिर्फ यह नहीं है कि एजेंट लंबे और ज़्यादा जटिल काम कर सकते हैं।
ज़्यादा अहम बदलाव यह है कि जब ये एजेंट उस काम के आसपास के नियंत्रणों का हिस्सा बन जाते हैं, तो क्या होता है।
डेवलपर की मदद करने वाला AI पहले से ही जाना-पहचाना है।
“यह बदलाव आगे नहीं बढ़ सकता” कह पाने वाला AI कुछ अलग ही बात है।
जैसे-जैसे AI एजेंट CI/CD पाइपलाइनों का हिस्सा बनते जा रहे हैं, टीमों को क्षमता जितनी ही सावधानी से अधिकार के बारे में भी सोचना होगा।
अब सवाल सिर्फ यह नहीं रहा कि AI वह काम कर सकता है या नहीं।
सवाल यह भी है कि हम उस फैसले का कितना हिस्सा AI को देने के लिए तैयार हैं।