क्वामे बोएटेंग द्वारा
AI-सहायित कोडिंग को अक्सर पेयर प्रोग्रामिंग के तेज़ संस्करण के रूप में वर्णित किया जाता है। अब यह तुलना बहुत सीमित है। जब कोई एजेंट किसी रिपॉज़िटरी का निरीक्षण कर सकता है, कई फ़ाइलों में बदलाव कर सकता है, टूल चला सकता है, प्रीव्यू बना सकता है और पुल रिक्वेस्ट खोल सकता है, तो सहयोग की केंद्रीय समस्या अब केवल यह नहीं रह जाती कि “क्या यह कोड लिख सकता है?” बल्कि यह हो जाती है कि “क्या लोग देख सकते हैं, समीक्षा कर सकते हैं, अनुमोदन दे सकते हैं और बाद में यह पुनर्निर्मित कर सकते हैं कि क्या हुआ था?”
इसीलिए एजेंट-सहायित सॉफ़्टवेयर टीमों में सबसे महत्वपूर्ण डिज़ाइन बदलाव शायद निजी प्रॉम्प्ट से दृश्यमान वर्कस्पेस की ओर बढ़ना है। उदाहरण के लिए, Slack Code को प्रोजेक्ट चैनलों को कोडिंग एजेंटों, कोड-डिफ़ ऑडिटिंग, लाइव HTML प्रीव्यू, फ़ीडबैक और अनुमोदन वर्कफ़्लो, स्वचालित संग्रहण और ऑडिट लॉग के साथ संयोजित करने वाला बताया गया है। GitHub के Copilot ऐप ने भी प्रोजेक्ट्स के बीच इश्यू और पुल रिक्वेस्ट व्यवस्थित करने के लिए “My work” पेन जोड़ा है। ये सुविधाएँ एक व्यावहारिक सिद्धांत की ओर संकेत करती हैं: एजेंट का काम किसी अपारदर्शी उत्तर जैसा कम और नियंत्रित उत्पादन प्रक्रिया से गुज़रते हुए चेंज सेट जैसा अधिक दिखना चाहिए।
चैट काम का रिकॉर्ड नहीं है
किसी एजेंट के साथ बातचीत किसी विचार की खोज के लिए उपयोगी हो सकती है, लेकिन यह रिकॉर्ड के लिए एक कमज़ोर प्रणाली है। महत्वपूर्ण विवरण एक लंबे थ्रेड में दबे रह सकते हैं: कौन-सी फ़ाइलें बदलीं, कौन-से कमांड चले, एजेंट ने कौन-सी धारणाएँ बनाईं, समीक्षक ने क्या अस्वीकार किया और अंतिम परिणाम पहले प्रस्ताव से अलग है या नहीं।
एक टिकाऊ वर्कस्पेस इन विवरणों को निरीक्षण योग्य बनाता है। इसे अनुरोध को किसी विशिष्ट रिपॉज़िटरी या प्रोजेक्ट से जोड़ना चाहिए, एजेंट की योजना सुरक्षित रखनी चाहिए, टूल की कार्रवाइयाँ और फ़ाइलों में बदलाव दिखाने चाहिए, टेस्ट और प्रीव्यू से लिंक करना चाहिए और यह दर्ज करना चाहिए कि परिणाम को किसने अनुमोदित किया। सटीक इंटरफ़ेस अलग हो सकता है—इश्यू ट्रैकर, पुल रिक्वेस्ट, सहयोग चैनल या एजेंट कंसोल—लेकिन सत्र समाप्त होने के बाद भी जानकारी सुरक्षित रहनी चाहिए।
यह केवल अनुपालन के लिए ही नहीं, बल्कि सामान्य इंजीनियरिंग कारणों से भी महत्वपूर्ण है। यदि दो सप्ताह बाद कोई बग दिखाई देता है, तो टीम को अंतिम डिफ़ से अधिक जानकारी चाहिए होगी। उसे मूल आवश्यकता, बनाई गई योजना, टेस्ट के प्रमाण, समीक्षक की टिप्पणियाँ और यह जानना पड़ सकता है कि किसी जोखिमपूर्ण समझौते को मनुष्य ने स्पष्ट रूप से स्वीकार किया था या नहीं। टिकाऊ रिकॉर्ड उस जाँच को छोटा कर देता है।
दृश्यमान काम की पाँच परतें
कोडिंग एजेंट अपनाने वाली टीमें प्रत्येक बदलाव को एक छोटे, निरीक्षण योग्य केस फ़ाइल की तरह देख सकती हैं। पाँच परतें विशेष रूप से उपयोगी हैं:
- उद्देश्य: इश्यू, स्वीकृति मानदंड, सीमाएँ और अनुरोधित दायरा।
- योजना: फ़ाइलों में बदलाव करने से पहले एजेंट का प्रस्तावित दृष्टिकोण। किसी गैर-मामूली कार्य के लिए यह सजावट नहीं, बल्कि अनुमोदन जाँच-बिंदु है।
- डिफ़: सटीक जोड़, हटाव, निर्भरता में बदलाव, कॉन्फ़िगरेशन संपादन और जनरेट की गई एसेट।
- प्रमाण: टेस्ट परिणाम, लिंट आउटपुट, सुरक्षा जाँच, स्क्रीनशॉट और जहाँ प्रासंगिक हो वहाँ लाइव या डिप्लॉय किए जा सकने वाला प्रीव्यू।
- निर्णय रिकॉर्ड: समीक्षक की टिप्पणियाँ, अनुरोधित बदलाव, अनुमोदन, अस्वीकृति, रोलबैक या आगे का काम।
उद्देश्य यह नहीं है कि हर बदलाव को किसी भारी-भरकम समिति से गुज़ारा जाए। टाइपो और भुगतान-प्रवाह में बदलाव के लिए एक जैसे नियंत्रण नहीं होने चाहिए। उद्देश्य यह है कि जाँच का स्तर संभावित प्रभाव के अनुपात में हो।
अनुमोदन कार्रवाइयों से जुड़े होने चाहिए
“ह्यूमन इन द लूप” उपयोगी नियंत्रण बनने के लिए बहुत अस्पष्ट है। कोई व्यक्ति परिणामस्वरूप बने डिफ़ को देखे बिना योजना को अनुमोदित कर सकता है, या यह ध्यान दिए बिना कोड बदलाव को मंज़ूरी दे सकता है कि एजेंट ने डिप्लॉयमेंट फ़ाइल में भी बदलाव किया है। बेहतर वर्कफ़्लो स्पष्ट करते हैं कि अनुमोदन से क्या करने की अनुमति मिलती है।
उदाहरण के लिए, कोई टीम एजेंट को रिपॉज़िटरी पढ़ने और स्थानीय टेस्ट स्वचालित रूप से चलाने की अनुमति दे सकती है, किसी निर्दिष्ट शाखा के बाहर लिखने से पहले अनुमोदन आवश्यक कर सकती है और मर्ज या डिप्लॉय करने से पहले अलग अनुमोदन आवश्यक कर सकती है। एजेंट डेटाबेस माइग्रेशन का प्रस्ताव दे सकता है, लेकिन उसे प्रोडक्शन में निष्पादित करने से प्रतिबंधित किया जा सकता है। एजेंट किन कार्यों को पूरा कर सकते हैं और किन्हें केवल सुझा सकते हैं, इसे वर्गीकृत करने के लिए UAE का प्रस्तावित दृष्टिकोण इसी व्यापक पैटर्न को दर्शाता है: स्वायत्तता कार्य के आधार पर दी जानी चाहिए, वैश्विक रूप से मान नहीं लेनी चाहिए।
अनुमोदनों का दायरा और समाप्ति भी आवश्यक है। “लैंडिंग-पेज की कॉपी अपडेट करें” के लिए दिया गया अनुमोदन चुपचाप किसी नए एनालिटिक्स पैकेज की अनुमति नहीं देना चाहिए। कल अनुमोदित की गई योजना आज के महत्वपूर्ण रूप से बदले हुए डिफ़ पर स्वतः लागू नहीं होनी चाहिए। इंटरफ़ेस को इन सीमाओं को स्पष्ट रूप से दिखाना चाहिए।
प्रीव्यू समीक्षा को निरीक्षण में बदल देते हैं
जब लोग स्रोत फ़ाइलों से अनुमान लगाने के बजाय परिणाम का निरीक्षण कर सकते हैं, तो कोड समीक्षा अक्सर आसान हो जाती है। लाइव HTML प्रीव्यू टूटी हुई स्पेसिंग, गायब स्थितियाँ, ऐसे नियंत्रण जिन्हें एक्सेस नहीं किया जा सकता, या नेविगेशन में अनपेक्षित बदलाव दिखा सकता है, जिसे समीक्षक टेक्स्ट डिफ़ में नज़रअंदाज़ कर सकता है।
प्रीव्यू शुद्धता का प्रमाण नहीं होते। उन्हें टेस्ट और स्रोत समीक्षा का स्थान लेने के बजाय उनके साथ होना चाहिए। लेकिन वे चर्चा के लिए एक साझा वस्तु बनाते हैं: समीक्षक किसी विशिष्ट स्क्रीन, स्थिति या इंटरैक्शन की ओर संकेत कर सकता है और प्रस्तावित बदलाव से जुड़ा फ़ीडबैक छोड़ सकता है।
यह विशेष रूप से तब मूल्यवान होता है जब समीक्षा में गैर-विशेषज्ञ भी शामिल हों। कोई प्रोडक्ट मैनेजर फ़्रेमवर्क में बदलाव का आकलन करने में सक्षम न हो, लेकिन यह पुष्टि करने के लिए सही व्यक्ति हो सकता है कि वर्कफ़्लो आवश्यकता के अनुरूप है। कोई डिज़ाइनर दृश्य प्रतिगमन को मान्य कर सकता है। कोई सुरक्षा विशेषज्ञ अनुमतियों और डेटा प्रबंधन पर ध्यान केंद्रित कर सकता है। एजेंट-सहायित वर्कस्पेस प्रत्येक प्रश्न को उसका उत्तर देने के लिए सबसे उपयुक्त व्यक्ति तक पहुँचा सकता है।
डिफ़ को केवल रंग नहीं, संदर्भ भी चाहिए
परिचित लाल-और-हरे रंग वाला डिफ़ अब भी आवश्यक है, लेकिन एजेंट द्वारा बनाए गए बदलाव इतने व्यापक हो सकते हैं कि समीक्षक अभिभूत हो जाए। टीमों को एजेंट से कहना चाहिए कि कमिट या बदलाव समूहों को सीमित रखे, प्रत्येक महत्वपूर्ण फ़ाइल में बदलाव का कारण बताए और जनरेट की गई या विक्रेता की फ़ाइलों को अलग से चिह्नित करे।
उपयोगी समीक्षा संकेतों में शामिल हैं:
- उपयोगकर्ता को दिखाई देने वाला कौन-सा व्यवहार बदला?
- कार्यान्वयन के समर्थन के लिए ही किन फ़ाइलों में बदलाव किया गया?
- एजेंट ने मौजूदा व्यवहार के बारे में कौन-सी धारणाएँ बनाईं?
- कौन-से परीक्षण जोड़े गए, बदले गए या चलाए ही नहीं गए?
- क्या इस बदलाव का अनुमतियों, डेटा प्रतिधारण, बिलिंग या बाहरी APIs पर असर पड़ सकता है?
ये प्रश्न समीक्षा को “इसे देख लें” जैसे अस्पष्ट अनुरोध से बदलकर एक दोहराई जा सकने वाली जाँच बना देते हैं। वे एक आम विफलता की स्थिति को उजागर करने में भी मदद करते हैं: एक विश्वसनीय लगने वाला फ़ीचर, जिसके साथ अधूरा परीक्षण अपडेट या अनजाने में किया गया कॉन्फ़िगरेशन बदलाव जुड़ा हो।
महत्वपूर्ण तर्क को संग्रहित करें
हर मॉडल वार्तालाप के हर टोकन को सुरक्षित रखना अपने-आप में उपयोगी नहीं होता। लंबे इतिहास को संग्रहित करना महँगा और खोजना कठिन हो सकता है, जबकि संदर्भ-संक्षेपण पर शोध चेतावनी देता है कि सारांश महत्वपूर्ण जानकारी खो सकते हैं। इसलिए एक व्यावहारिक ऑडिट ट्रेल को बिना किसी चयन के सब कुछ सहेजने के बजाय निर्णय-प्रासंगिक कलाकृतियों को सुरक्षित रखना चाहिए।
कम-से-कम अनुरोध, स्वीकृत योजना, अंतिम diff, टूल और परीक्षण परिणाम, preview या deployment संदर्भ, समीक्षक के निर्णय और दी गई किसी भी छूट को सुरक्षित रखें। यदि किसी एजेंट ने बाहरी स्रोतों का उपयोग किया या आंतरिक दस्तावेज़ प्राप्त किए, तो संबंधित स्रोत संदर्भ और वह बिंदु दर्ज करें जहाँ उन्होंने बदलाव को प्रभावित किया। उच्च-जोखिम वाले कार्य के लिए पूरा इंटरैक्शन और निष्पादन लॉग सुरक्षित रखना उचित हो सकता है।
जहाँ दाँव ऊँचे हों वहाँ रिकॉर्ड को छेड़छाड़-स्पष्ट बनाएँ, और संकट आने से पहले प्रतिधारण नियम तय करें। ऐसा ऑडिट ट्रेल जो किसी चैनल के संग्रहित होते ही गायब हो जाए—या संशोधित परिणाम और मूल परिणाम में अंतर न कर सके—गंभीर जाँच का समर्थन नहीं करेगा।
सॉफ़्टवेयर करियर के लिए इसका क्या बदलाव है
उभरता हुआ कौशल केवल बेहतर prompts लिखना नहीं है। यह ऐसा कार्य तैयार करना है जिसे कोई दूसरा व्यक्ति जाँच और विश्वास के साथ देख सके। डेवलपर्स को स्वीकृति मानदंड निर्दिष्ट करने, कार्यों को छोटे हिस्सों में बाँटने, बड़े पैमाने पर diffs की समीक्षा करने, सार्थक परीक्षण बनाने और यह तय करने में सहज होना होगा कि एजेंट को कहाँ रुककर पूछना चाहिए।
उत्पाद और डिज़ाइन पेशेवरों की previews की समीक्षा करने और आशय स्पष्ट करने में बड़ी भूमिका होगी। QA इंजीनियर स्वीकृति gates और विफलता के मामलों को परिभाषित करने में मदद कर सकते हैं। इंजीनियरिंग प्रबंधकों को अदृश्य जोखिम लेने को पुरस्कृत किए बिना throughput मापना होगा। तकनीकी लेखक और संचालन विशेषज्ञ निर्णयों, अपवादों और runbooks को स्थायी बनाने में योगदान दे सकते हैं।
एक उपयोगी अभ्यास है किसी नियमित फ़ीचर को लेकर उसकी साक्ष्य-श्रृंखला का मानचित्र बनाना: अनुरोध, योजना, branch, diff, परीक्षण, preview, स्वीकृति, release और rollback। फिर पूछें कि भविष्य का कोई टीम-सदस्य कहाँ अनुमान लगाने को मजबूर होगा। हर अनुमान बेहतर workspace, अधिक स्पष्ट अनुमति या अधिक टिकाऊ रिकॉर्ड का उम्मीदवार है।
एक सरल संचालन नियम
एजेंटों को एक दृश्यमान और पूर्ववत किए जा सकने वाले दायरे में तेज़ी से काम करने दें। उन्हें एक परिभाषित workspace दें, संवेदनशील कार्रवाइयों को सीमित करें, महत्वपूर्ण सीमाओं पर स्वीकृति अनिवार्य करें, बदलाव के साथ साक्ष्य जोड़ें और अंतिम निर्णय सुरक्षित रखें। उद्देश्य स्वचालन को तब तक धीमा करना नहीं है जब तक वह मैन्युअल कोडिंग जैसा न लगने लगे। उद्देश्य गति को जवाबदेही के अनुकूल बनाना है।
एजेंट-सहायित विकास में सबसे अच्छा सहयोगी वह प्रणाली नहीं है जो अकेले सबसे अधिक कोड तैयार करे। वह ऐसी प्रणाली है जिसका काम समझा, चुनौती दी, स्वीकृत, पूर्ववत और उससे सीखा जा सके।
