Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

सॉफ्टवेयर की दुनिया में, प्रोग्राम विशाल, जटिल शहरों की तरह बनाए जाते हैं। वे निर्देशों की लाखों पंक्तियों से बने होते हैं जो कंप्यूटर को यह बताते हैं कि उसे कैसे व्यवहार करना है, चीजें कैसे याद रखनी हैं, और जब कोई उपयोगकर्ता बटन पर क्लिक करता है तो उसे कैसे प्रतिक्रिया देनी है। दशकों से, इन शहरों को बदलने का मानक तरीका एक मानव वास्तुकार (architect) को हर उस नई ईंट का निरीक्षण करने के लिए भेजना रहा है जिसे एक कृत्रिम बुद्धिमत्ता (AI) रख सकती है। यह मानव समीक्षा इसलिए आवश्यक मानी जाती है क्योंकि प्रोग्राम के विभिन्न हिस्सों के बीच संबंध इतने गहरे और उलझे हुए होते हैं कि एक कोने में छोटी सी गलती दूसरे कोने में पतन का कारण बन सकती है। जब कोई परिवर्तन एक साथ सैकड़ों फाइलों को प्रभावित करने के लिए पर्याप्त बड़ा होता है, तो काम की जांच करने का कार्य एक बाधा बन जाता है; कोई भी अकेला मानव एक साथ परिवर्तनों के पूरे मानचित्र को अपने दिमाग में नहीं रख सकता। इस सीमा ने कई लोगों को यह मानने के लिए प्रेरित किया है कि सबसे जटिल वास्तुशिल्प बदलावों के लिए, एकमात्र सुरक्षित रास्ता पुराने ढांचे को गिराकर उसे फिर से शून्य से बनाना है, जो एक धीमी, महंगी और जोखिम भरी प्रक्रिया है।

एक हालिया केस स्टडी इस विचार को चुनौती देती है कि इतने बड़े बदलावों में सुरक्षा सुनिश्चित करने का एकमात्र तरीका मानव समीक्षा है। यह एक ऐसी पद्धति की खोज करती है जहाँ ध्यान तैयार उत्पाद की जाँच करने के बजाय, एक भी ईंट रखने से पहले ब्लूप्रिंट (खाके) को पूर्ण बनाने पर केंद्रित होता है। एआई से कोड लिखने और फिर इस उम्मीद करने के बजाय कि कोई मानव गलतियों को ढूंढ लेगा, यह दृष्टिकोण मशीन से पहले यह विस्तृत, औपचारिक विवरण लिखने के लिए कहता है कि वह वास्तव में क्या करने का इरादा रखती है। इस विवरण को मौजूदा कोड के विरुद्ध कड़ाई से जांचा जाता है, यह देखने के लिए नहीं कि कोड काम करता है या नहीं, बल्कि यह देखने के लिए कि क्या योजना स्वयं तर्कसंगत है। योजना को तब तक परिष्कृत, सुधारा और फ्रीज (स्थिर) किया जाता है जब तक कि वह निष्कर्ष (findings) देना बंद न कर दे। केवल तभी मशीन निर्माण शुरू करती है, और तब भी, उसे उस फ्रीज की गई योजना के विरुद्ध लगातार ऑडिट किया जाता है। परिणाम यह प्रदर्शन है कि एक विशाल, जटिल वास्तुशिल्प परिवर्तन को बिना किसी मानव द्वारा उत्पन्न कोड को पढ़े पूरा किया जा सकता है, बशर्ते कि इरादे को परिभाषित करने और सत्यापित करने की प्रक्रिया पर्याप्त मजबूत हो।

यह प्रयोग एक बड़े, प्रोप्राइटरी सॉफ्टवेयर एप्लिकेशन के भीतर आयोजित किया गया था जिसका उपयोग आर्टिफिशियल इंटेलिजेंस कोडिंग सहायता के लिए किया जाता है। 'टाइपस्क्रिप्ट' (TypeScript) नामक भाषा में लिखे गए इस सिस्टम में लगभग 3,650 फाइलों में फैले हुए 717,000 से अधिक लाइनों का कोड था। यह एक जीवित, सांस लेता हुआ सॉफ्टवेयर था जिसका दैनिक उपयोग किया जाता था, न कि कोई सैद्धांतिक मॉडल। एआई एजेंट को सौंपा गया कार्य एक कोर नियम को हटाना था जो इसके निर्माण के समय से ही सिस्टम को नियंत्रित कर रहा था। यह नियम, जिसे एक 'इनवेरिएंट' (invariant) कहा जाता है, यह गारंटी देता था कि जब भी कोई उपयोगकर्ता एआई के साथ बातचीत शुरू करता है, तो वह विंडो जो उस बातचीत को प्रदर्शित करती है, अनुरोध की पूरी अवधि के दौरान खुली रहेगी। यदि उपयोगकर्ता विंडो बंद कर देता है, तो बातचीत समाप्त हो जाएगी। लक्ष्य इस नियम को तोड़ना था: उपयोगकर्ता को विंडो बंद करने में सक्षम होना चाहिए, और बातचीत बैकग्राउंड में चलती रहनी चाहिए, ताकि उसे ठीक वहीं से फिर से खोला और शुरू किया जा सके जहाँ वह छोड़ी गई थी, बिना किसी डेटा को खोए या शब्दों को दोहराए।

इस विशिष्ट परिवर्तन को मानक रिफैक्टरिंग (refactoring) के माध्यम से प्राप्त करना लगभग असंभव माना गया था। लेखक के आकलन में, कोड की परस्पर निर्भरता इतनी घनी थी कि प्रभावित घटकों को पूरी तरह से बदले बिना बातचीत के जीवनकाल (lifetime) को संशोधित करना सामान्य रूप से पूरे सिस्टम को तोड़ने के लिए पर्याप्त होता। इस कार्य में जटिल टाइमिंग संबंधी मुद्दों को प्रबंधित करना शामिल था, जैसे कि क्या होता है जब डेटा अभी भी स्ट्रीम हो रहा हो और उसी समय विंडो बंद हो जाती है, और एक लाइव स्ट्रीम से उपयोगकर्ता को फिर से कैसे जोड़ा जाए जो उनके बिना चल रही है। इसे हल करने के लिए, लेखक ने एक पांच-चरणीय प्रोटोकॉल का उपयोग किया जिसे आर्टिफिशियल इंटेलिजेंस को एक सख्त ट्रैक पर रखने के लिए डिज़ाइन किया गया था। प्रक्रिया ने एजेंट द्वारा अनुरोध का विश्लेषण करने और एक औपचारिक विनिर्देश (specification) बनाने के साथ शुरू की, जो एक विस्तृत दस्तावेज़ है जो बताता है कि परिवर्तन वास्तव में कैसे काम करना चाहिए।

प्रक्रिया का सबसे महत्वपूर्ण हिस्सा 'रिफाइनमेंट' (परिष्करण) चरण था। एजेंट को अपने स्वयं के विनिर्देश को अपने वास्तविक सोर्स कोड के विरुद्ध जांचने के लिए कहा गया था, ताकि किसी भी विरोधाभास या छूटे हुए विवरणों को खोजा जा सके। यह एक बार की जाँच नहीं थी। एजेंट ने इस ऑडिट के चौदह चक्र चलाए। प्रत्येक चक्र में, उसने अपनी ही योजना में त्रुटियां पाईं—शायद कोई ऐसी फ़ाइल जिसे वह अपडेट करना भूल गया था, या कोई ऐसी निर्भरता जिसे उसने गलत समझा था—और त्रुटियों को ठीक करने के लिए विनिर्देश को फिर से लिखा। इन चौदह दौरों के दौरान, योजना को लगभग पचासी बार सुधारा गया, जिससे छिपे हुए कनेक्शनों की खोज के कारण परिवर्तन का दायरा 110 फाइलों से बढ़कर 160 फाइलें हो गया। चौदहवें चक्र के अंत तक, विनिर्देश फ्रीज हो गया। यह एक निश्चित ब्लूप्रिंट था जिसे कोडबेस की वास्तविकता के विरुद्ध तब तक ऑडिट किया गया था जब तक कि अंतिम चक्र ने कोई निष्कर्ष नहीं दिया, जिसके बाद इसे सभी आगामी चरणों के लिए संदर्भ के रूप में लॉक कर दिया गया।

योजना को लॉक करने के बाद, एजेंट कार्यान्वयन (implementation) चरण की ओर बढ़ा। उसे फ्रीज किए गए विनिर्देश से मेल खाने के लिए आवश्यक कोड परिवर्तन उत्पन्न करने का निर्देश दिया गया। एजेंट ने आंशिक परिवर्तन करने से इनकार कर दिया, क्योंकि उसने सही ढंग से पहचान लिया था कि एक अधूरा माइग्रेशन सिस्टम को तोड़ देगा। इसके बजाय, उसने तीन अलग-अलग, पुष्ट चरणों में कार्य निष्पादित किया। एक बार कोड लिखे जाने के बाद, सत्यापन (verification) चरण शुरू हुआ। जिस तरह से योजना की जांच कोड के विरुद्ध की गई थी, अब नए कोड की जांच फ्रीज किए गए विनिर्देश के विरुद्ध की गई। एजेंट ने इस ऑडिट के सत्र सत्रों (cycles) को चलाया, वास्तविक स्क्रीन पर मौजूद कोड की तुलना विनिर्देश में लिखित नियमों से की। प्रत्येक चक्र में, उसने विचलन को पाया और सुधारा, उन सूक्ष्म वास्तुशिल्प दोषों को ठीक किया जिन्हें एक मानव शायद छोड़ देता। इन सत्रों के दौरान, एजेंट ने कोड में 116 दोषों को सुधारा। प्रक्रिया केवल तभी रुकी जब दो लगातार ऑडिट ने शून्य त्रुटियां वापस दीं, जिससे पुष्टि हुई कि कोड निर्धारित अभिसरण मानदंड (convergence criterion) के भीतर योजना से मेल खाता है।

पूरे ऑपरेशन ने 189 फाइलों को छुआ, और पुराने कोड के निष्कर्षण (extraction) को शामिल करते हुए कुल 288 फाइलें बदली गईं। परिवर्तनों में 34,000 से अधिक नई लाइनें शामिल थीं और 16,000 से अधिक लाइनें हटाई गईं। उल्लेखनीय रूप से, यह विशाल पुनर्गठन तीन दिनों में पूरा हुआ। इस कार्य के लिए आवश्यक आर्टिफिशियल इंटेलिजेंस प्रोसेसिंग की लागत 2,430 अमेरिकी डॉलर थी। पूरे तीन दिनों की अवधि के दौरान, प्रोग्राम को एक बार भी किसी मानव द्वारा नहीं चलाया गया। सॉफ्टवेयर को पहली बार सत्र सत्रों के बाद वास्तव में निष्पादित किया गया था, जब लेखक ने अंततः नए व्यवहार का परीक्षण किया।

परिणाम सफल रहा। जब प्रोग्राम लॉन्च किया गया, तो नया व्यवहार बिल्कुल वैसा ही था जैसा विनिर्देश में वर्णित किया गया था। एक उपयोगकर्ता बातचीत शुरू कर सकता है, विंडो बंद कर सकता है, और बातचीत बैकग्राउंड में चलती रह सकती है। जब उपयोगकर्ता विंडो को फिर से खोलता है, तो बातचीत तुरंत फिर से शुरू हो जाती है, बिना किसी डेटा हानि या टेक्स्ट के दोहराव के। साइडबार में एक नया 'स्टॉप' बटन दिखाई दिया, जो उपयोगकर्ता को यदि आवश्यक हो तो बैकग्राउंड प्रक्रिया को समाप्त करने की अनुमति देता है। मौजूदा स्वचालित परीक्षण (automated tests), जो वर्षों से सॉफ्टवेयर पर चल रहे थे, ने कोई विफलता नहीं दिखाई, जो इंगित करता है कि नए सिस्टम ने पुरानी कार्यक्षमता को नहीं तोड़ा। सॉफ्टवेयर को वर्शन 2.3.0 के रूप रूप में सार्वजनिक रूप से जारी किया गया, और रिलीज के बाद लगभग तीस सत्रों के उपयोग में कोई बग नहीं देखा गया।

यह केस स्टडी यह दावा नहीं करती है कि आर्टिफिशियल इंटेलिजेंस अब सभी परिदृश्यों में मानव इंजीनियरों की जगह ले सकता है, न ही यह सुझाव देती है कि यह विधि हर प्रकार की समस्या के लिए काम करती है। लेखक सावधानीपूर्वक नोट करते हैं कि यह एक एकल, विशिष्ट उदाहरण था जो एक एकल कोडबेस पर आधारित था, और परिणामों को अन्य सिस्टम या अन्य कार्यों पर स्वतः लागू नहीं माना जा सकता है। अध्ययन स्पष्ट रूप से इस विचार को खारिज करता है कि पूर्व-मौजूदा परीक्षणों के सेट ने इस समस्या को हल किया होता, क्योंकि वांछित व्यवहार परिवर्तन से पहले अस्तित्व में नहीं था। पुराने कोड में जांच के लिए कोई "सही" उत्तर मौजूद नहीं था; शुद्धता को शून्य से परिभाषित किया जाना था। अध्ययन यह भी स्वीकार करता है कि यह प्रक्रिया एक विशिष्ट, शक्तिशाली एआई मॉडल पर निर्भर थी और परिणाम कमजोर मॉडलों के साथ भिन्न हो सकते हैं।

इस कार्य का महत्व जटिलता को प्रबंधित करने के एक नए तरीके के प्रदर्शन में निहित है। अंतिम उत्पाद के निरीक्षण के बजाय योजना को कड़ाई से परिभाषित करने और सत्यापित करने पर भार स्थानांतरित करके, शोधकर्ताओं ने दिखाया कि एक मशीन बिना मानवीय हस्तक्षेप के परस्पर निर्भर कोड के बारूदी सुरंग (minefield) के माध्यम से नेविगेट कर सकती है। मुख्य बात यह नहीं थी कि मशीन अचूक थी, बल्कि यह थी कि प्रक्रिया ने इसे अपनी गलतियों को पकड़ने के लिए बार-बार अवसर दिया, इससे पहले कि वे स्थायी हो जातीं। विनिर्देश को चौदह बार चुनौती दी गई, और कोड की सत्र सत्र बार जांच की गई, जिससे एक स्व-सुधार लूप बना जिसने अनुभवजन्य स्टॉपिंग रूल (empirical stopping rule) के आधार पर इरादे और वास्तविकता के बीच मिलान की ओर सिस्टम को निर्देशित किया। इस पूरी प्रक्रिया के लॉग, जो 1,500 से अधिक पृष्ठों में फैले हुए हैं, निरीक्षण के लिए प्रकाशित किए गए हैं, जो एक पारदर्शी दृष्टिकोण प्रदान करते हैं कि कैसे एक मशीन बिना किसी मानव के कंधे के ऊपर देखे, एक कोर वास्तुशिल्प नियम को ध्वस्त कर सकती है और उसे ईंट-दर-ईंट फिर से बना सकती है।