AI द्वारा लिखे गए कोड का शिकार बनने से बचने के लिए आर्किटेक्चर को अलग करना आवश्यक है
TuBrief 편집팀
2026년 7월 7일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
जेनरेटिव AI जिस गति से कोड तैयार कर रहा है, वह डरावनी है। हालाँकि, सीनियर इंजीनियरों और तकनीकी लीड्स के सामने असली समस्या कुछ और है। मशीन द्वारा एक सेकंड में लिखे गए कोड को सत्यापित करने और उसे मौजूदा सिस्टम में एकीकृत करने की प्रक्रिया में संज्ञानात्मक अधिभार (cognitive overload) उत्पन्न होता है। गूगल क्लाउड की DORA 2025 रिपोर्ट के अनुसार, AI का उपयोग डिप्लॉयमेंट की आवृत्ति तो बढ़ाता है, लेकिन सिस्टम की अस्थिरता भी बढ़ाता है। इसका मतलब है कि लोग रात भर उन गड्ढों को भर रहे हैं जो आँख बंद करके कोड को कॉपी-पेस्ट करने से उत्पन्न हुए हैं। मैनुअल रूप से कोड पढ़ने और डिबगिंग करने के तरीके से इस गति का सामना करना असंभव है। कोड को कचरे में बदलने से रोकने के लिए, हमें शुरू से ही एक ऐसा आर्किटेक्चर वातावरण बनाना होगा जो AI द्वारा लिखे गए लॉजिक पर भरोसा न करे और सत्यापन को स्वचालित करे।
AI द्वारा सुझाया गया कोड व्यावसायिक संदर्भ को नहीं समझता है। देखने में भले ही यह ठीक लगे, लेकिन यह अक्सर डोमेन के भीतर के सूक्ष्म नियमों को तोड़ देता है। इसलिए, AI द्वारा लिखे गए लॉजिक को एक बाहरी सिस्टम के रूप में माना जाना चाहिए जो किसी भी समय खराब हो सकता है। यही कारण है कि डिज़ाइन चरण से ही एक 'एंटी-करप्शन लेयर' (Anti-Corruption Layer) को शामिल करना आवश्यक है, जो स्पष्ट अमूर्त इंटरफेस (abstract interface) को परिभाषित करता है ताकि दूषित पदार्थ डोमेन क्षेत्र में प्रवेश न कर सकें।
सॉफ्टवेयर आर्किटेक्चर को अलग करना ही पर्याप्त नहीं है। इस बात का हमेशा जोखिम रहता है कि AI कोड दुर्भावनापूर्ण लाइब्रेरी को आयात करे या लोकल फाइल सिस्टम के साथ छेड़छाड़ करे। जब स्ट्राइप ने अपना ऑटोनॉमस एजेंट सिस्टम 'Minions' डिज़ाइन किया था, तो उन्होंने AI कोड को एक स्वतंत्र वर्चुअल मशीन के अंदर चलाया जो होस्ट मशीन से अलग थी और प्रोटोकॉल स्तर पर नेटवर्क एक्सेस को ब्लॉक कर दिया था; यह उदाहरण बहुत कुछ सिखाता है। प्रोडक्शन वातावरण की रक्षा के लिए, हमें CI/CD पाइपलाइन के भीतर कर्नल-लेवल के नियंत्रण तंत्र को लागू करना होगा।
हमें एक 'जीरो ट्रस्ट' निष्पादन वातावरण बनाना चाहिए जो अविश्वसनीय कोड को बाहर निकलने से रोकता है। सिस्टम विफलता प्रतिक्रिया समय में कमी इसका एक अतिरिक्त लाभ है।
डेवलपर्स के लिए AI द्वारा बनाए गए सैकड़ों लाइनों के कोड को अपनी आँखों से देखना खतरनाक है। जब दिमाग थक जाता है, तो 'ऑटोमेशन बायस' (automation bias) काम करने लगता है, जिससे हम बिना सोचे-समझे ठीक दिखने वाले कोड को पास कर देते हैं। मशीन द्वारा लिखे गए लॉजिक की खामियों को इंसान नहीं, बल्कि निष्पादन योग्य टेस्ट कोड पकड़ना चाहिए। AI को वास्तविक कार्यान्वयन कोड लिखने का आदेश देने से पहले, क्रम को उलट दें और उसे पहले टेस्ट केस बनाने के लिए कहें जो संचालन विनिर्देशों (operating specifications) को परिभाषित करते हैं। यह एक ऐसा नियम है जो 5 श्रेणियों को पहले परिभाषित करने के लिए मजबूर करता है: सामान्य प्रवाह, सीमा स्थितियाँ, अपवाद हैंडलिंग, असामान्य इनपुट और विफलता रिकवरी परिदृश्य।
मैनुअल प्रॉम्प्टिंग के माध्यम से बनाए गए कोड की लाइन कवरेज बहुत अधिक नहीं होती है। Defog की एजेंट ऑपरेशनल डेटा के अनुसार, मानव इंजीनियरों द्वारा AI के साथ बातचीत करके प्राप्त टेस्ट लाइन कवरेज औसतन केवल 32% थी। इसके विपरीत, जब सोर्स कोड स्टेटिक एनालिसिस और रनटाइम सैंडबॉक्स बिल्ड को स्वचालित टेस्ट एजेंटों के साथ जोड़ा गया, तो बिना मानवीय हस्तक्षेप के 81% रिग्रेशन टेस्ट लाइन कवरेज प्राप्त हुआ। मशीन द्वारा मशीन की निगरानी करना कहीं अधिक सटीक है।
प्राकृतिक भाषा अनुवाद परिणामों या गतिशील JSON ऑब्जेक्ट्स जैसे लॉजिक के लिए, जहाँ आउटपुट स्ट्रिंग्स की 1-टू-1 तुलना करना मुश्किल है, 'LLM-as-a-Judge' तकनीक का उपयोग करें। AgentProctor जैसे फ्रेमवर्क को टेस्टिंग इंफ्रास्ट्रक्चर पर तैनात करें और मूल्यांकन मानदंड टेम्प्लेट को जजिंग मॉडल में डालें। यदि जजिंग मॉडल यह निर्धारित करता है कि लौटाया गया कोड सुरक्षा बाधाओं का उल्लंघन करता है और उसे एक मात्रात्मक रेटिंग देता है, और यदि वह मानकों को पूरा नहीं करता है तो बिल्ड को ब्लॉक कर दें, तो इससे इंसानों को रॉ कोड देखने की पीड़ा से मुक्ति मिल सकती है।
जैसे-जैसे मशीन द्वारा लिखे गए कोड की मात्रा बढ़ती है, सिस्टम में संज्ञानात्मक ऋण (cognitive debt) जमा होता जाता है। एक अजीब स्थिति पैदा हो जाती है जहाँ कोड तो चल रहा है, लेकिन कोई नहीं जानता कि वह क्यों चल रहा है। चूँकि AI टूल केवल तात्कालिक समस्याओं को हल करने पर ध्यान केंद्रित करते हैं, इसलिए कुछ महीनों बाद पूरे सिस्टम को रिफैक्टर करने पर भारी लागत चुकानी पड़ती है। कोडबेस के पीछे छिपे डिज़ाइन इरादे को संरक्षित करने के लिए, 'एजेंट डिसीजन रिकॉर्ड' प्रक्रिया को टीम मानक के रूप में अपनाएं। यह एक ऐसी प्रक्रिया है जहाँ मशीन-पठनीय प्रारूप में रिकॉर्ड रखा जाता है कि यह संरचना क्यों चुनी गई और किन विकल्पों को छोड़ दिया गया।
चूँकि इंसानी याददाश्त पर भरोसा नहीं किया जा सकता, इसलिए कमिट इतिहास में AI द्वारा कोड लिखे जाने का निशान छोड़ने के काम को भी ऑटोमेशन पाइपलाइन में शामिल किया जाना चाहिए। git-ai जैसे एक्सटेंशन लाइब्रेरी का उपयोग करके, आप कमिट संदेश के मुख्य भाग को गंदा किए बिना refs/notes/ai स्वतंत्र मेटाडेटा पथ में एजेंट के योगदान नोट्स रिकॉर्ड कर सकते हैं। Git पाइपलाइन निर्माण के चरण स्पष्ट हैं:
pre-commit hooks सेट करें।AI-Footprint: model=gpt-4o) और सह-लेखक जानकारी को जबरन डालें।इस तरह मेटाडेटा जमा करने से, आप बाद में वास्तविक समय में आपूर्ति श्रृंखला के आँकड़े निकाल सकते हैं कि कौन सी खामी या सुरक्षा भेद्यता किस AI मॉडल संस्करण से सबसे अधिक उत्पन्न हुई थी। यह उस नरक जैसी स्थिति को रोकने के लिए एक सुरक्षा उपाय है जहाँ हैंडओवर दस्तावेज़ न होने के कारण आपको हज़ारों लाइनों का कोड खंगालना पड़ता है।
यदि अनियंत्रित रूप से उत्पन्न कोड पुल रिक्वेस्ट कतार में जमा होने लगते हैं, तो मैनुअल कोड समीक्षा ठप हो जाएगी। उत्पादकता बनाए रखने के लिए, समीक्षा प्रक्रिया को मशीन-केंद्रित नियतात्मक फीडबैक गेट और मानव-केंद्रित संरचनात्मक प्रभाव मूल्यांकन में विभाजित किया जाना चाहिए। जैसे ही कोड CI वातावरण में अपलोड होता है, 3-स्तरीय गुणवत्ता आश्वासन गेट का उपयोग करना एक विकल्प है।
पहला, एक अल्ट्रा-फास्ट लिंटिंग गेट रखें जो 5 सेकंड के भीतर सिंटैक्स संरचना की वैधता और टाइप हिंट मिलान का निर्धारण करता है। यदि यह यहाँ विफल होता है, तो इसे तुरंत अस्वीकार कर दिया जाता है। दूसरा, केवल संशोधित फ़ाइल के प्रभाव क्षेत्र के भीतर के यूनिट टेस्ट को लगभग 2% तक सीमित करें और चयनात्मक प्रभाव परीक्षण करें। तीसरा, परीक्षण विफल होने पर, संदर्भ के साथ एरर स्टैक को एजेंट को वापस भेजें और उसे अधिकतम 2 बार तक स्वयं सुधारने के लिए एक 'ऑटोनॉमस करेक्शन ऑटोमेशन लूप' चलाएं।
केवल इस ऑटोनॉमस करेक्शन लूप से गुजरने वाला साफ-सुथरा कोड ही सीनियर डेवलपर की स्क्रीन पर दिखाई देता है। मानव समीक्षक अब टाइपो खोजने या कन्वेंशन पर उंगली उठाने में समय बर्बाद नहीं करते हैं। एक सीनियर इंजीनियर का समय केवल इस बात की समीक्षा करने में लगना चाहिए कि क्या डोमेन सीमाएँ घटकों के बीच सीधे जुड़ाव के कारण टूट गई हैं, यह जांचने में कि क्या ट्रैफ़िक बढ़ने पर निचले स्तर के पर्सिस्टेंस लेयर की सुरक्षा के लिए 'बैक-प्रेशर' लागू किया गया है, और सिस्टम संरचना और इन्फ्रास्ट्रक्चर अर्थव्यवस्था का विश्लेषण करने में, जैसे कि SQL N+1 प्रदर्शन ओवरहेड। यह बाढ़ की तरह आने वाले कोड के बीच प्रोडक्शन सिस्टम की रक्षा करने का एकमात्र तरीका है।