पहले निष्कर्ष: उस घटना का मूल कारण यह नहीं था कि एजेंट ने गलत कोड लिखा, बल्कि यह था कि हमने डिफ़ॉल्ट रूप से मान लिया कि "डेवलपमेंट एनवायरनमेंट को CDP-स्तरीय सुरक्षा की आवश्यकता नहीं है।" इस धारणा ने टीम को 23 घंटे के पुनर्लेखन कार्य की कीमत चुकानी पड़ी। नीचे समय-रेखा के अनुसार समीक्षा है, उम्मीद है कि यह उन साथियों की मदद करेगी जो AI कोडिंग एजेंट को R&D प्रक्रिया में एकीकृत कर रहे हैं।
दुर्घटना की समय-रेखा: "डेड कोड साफ़ करने" से लेकर "src खाली होने का पता चलने" तक
पहले दिन दोपहर 4 बजे, हम एक क्रॉस-बॉर्डर ERP करने वाली टीम के लिए कोड रीफैक्टरिंग कर रहे थे। प्रोजेक्ट Node.js + TypeScript था, src डायरेक्टरी में लगभग 1400 फ़ाइलें थीं, जिनमें से कई तीन महीने पहले के इटरेशन से बचे पुराने मॉड्यूल थे। टीम AI कोडिंग एजेंट का उपयोग करके स्वचालित रूप से "असंदर्भित डेड कोड" की पहचान और सफ़ाई करना चाहती थी।
एजेंट मल्टी-मॉडल एकीकृत एक्सेस वाले मॉडल गेटवे से जुड़ा था, कार्य prompt में लिखा था "पुष्टि करें कि कोई संदर्भ नहीं है और फ़ाइलें हटा दें"। इसने import ग्राफ़ को स्कैन किया, पाया कि src के अंतर्गत एक डायरेक्टरी की संदर्भ श्रृंखला टूट गई है, इसे डेड कोड माना और बैच डिलीशन निष्पादित किया। समस्या यह थी कि वह डायरेक्टरी वास्तव में गतिशील रूप से लोड होने वाली प्लगइन डायरेक्टरी थी, संदर्भ संबंध रनटाइम कॉन्फ़िगरेशन में लिखे गए थे, जो स्टैटिक विश्लेषण में दिखाई नहीं देते थे।
दूसरे दिन दोपहर 3 बजे, फ्रंटएंड सहकर्मी ने स्थानीय सेवा चलाई और त्रुटि रिपोर्ट हुई, तब हमें पता चला कि src डायरेक्टरी में 200 से कम फ़ाइलें बची हैं। git log जांचने पर, नवीनतम commit पिछले दिन दोपहर 4 बजे का था, खोज के समय तक 23 घंटे बीत चुके थे। इन 23 घंटों में, 3 इंजीनियरों ने लगभग 60 फ़ाइलें बदलीं, सभी commit नहीं की गईं।
डेवलपमेंट एनवायरनमेंट की डेटा सुरक्षा, आपकी सोच से अलग है
प्रोडक्शन एनवायरनमेंट की सुरक्षा तर्क है "कम परिवर्तन, ऑडिट करने योग्य, मुख्य-बैकअप युक्त"। डेवलपमेंट एनवायरनमेंट ठीक विपरीत है: फ़ाइलें बिखरी हुई, परिवर्तन लगातार, बड़ी मात्रा में मध्यवर्ती अवस्थाएं वर्ज़न रिपॉज़िटरी में नहीं गईं। मैंने पिछले महीने हमारी टीम के डेटा की गणना की, प्रति व्यक्ति प्रतिदिन लगभग 40 फ़ाइल परिवर्तन होते हैं, लेकिन git commit केवल 3 से 5 बार होता है। शेष परिवर्तन, सभी एडिटर कैश और अस्थायी ब्रांच में हैं।
इससे भी अधिक परेशानी यह है कि बहुत से लोग मानते हैं कि "Git इतिहास बराबर है पुनर्प्राप्ति योग्य"। Git केवल वही पुनर्प्राप्त कर सकता है जो आपने commit किया है। असबमिट किए गए परिवर्तन, एजेंट द्वारा बैच में हटाई गई फ़ाइलें, .env में स्थानीय कॉन्फ़िगरेशन, Git इन सबकी परवाह नहीं करता। उस घटना में, हमने git reflog और IDE के Local History से पुनर्प्राप्त करने का प्रयास किया, केवल 30% से कम सामग्री वापस मिली।
दैनिक बैकअप इस तरह के परिदृश्य को क्यों नहीं बचा सकता
मूल रूप से हमारे पास प्रतिदिन रात 2 बजे का पूर्ण बैकअप था। RPO के अनुसार, सबसे खराब स्थिति में 24 घंटे का नुकसान। लेकिन घटना दोपहर 3 बजे हुई, बैकअप पिछले दिन रात 2 बजे का था, बीच में 37 घंटे का अंतराल। पुनर्प्राप्ति 37 घंटे पहले का कोड था, यानी इन दो दिनों का पूरा इटरेशन फेंकना।
RPO=24 घंटे का अर्थ है, आप अधिकतम एक दिन के कार्यभार का नुकसान स्वीकार कर सकते हैं। प्रोडक्शन डेटाबेस के लिए, यह मीट्रिक शायद मुश्किल से पर्याप्त है। डेवलपमेंट एनवायरनमेंट के लिए, एक दिन का कार्यभार एक पूर्ण फ़ीचर इटरेशन हो सकता है। पारंपरिक दैनिक बैकअप की ग्रैन्युलैरिटी, डेवलपमेंट एनवायरनमेंट की परिवर्तन आवृत्ति से बिल्कुल मेल नहीं खाती।
ब्लॉक-स्तरीय CDP RPO को सेकंड स्तर तक कम करता है, यही डेवलपमेंट एनवायरनमेंट की उचित सुरक्षा है
बाद में हमने ब्लॉक-स्तरीय CDP समाधान अपनाया। पारंपरिक बैकअप से अंतर यह है: पारंपरिक बैकअप फ़ाइल या दिन के अनुसार स्नैपशॉट लेता है, CDP IO ब्लॉक के अनुसार कैप्चर करता है, हर डेटा ब्लॉक लिखे जाने पर एक बार रिकॉर्ड करता है। RPO 24 घंटे से सेकंड स्तर तक कम हो जाता है, सैद्धांतिक रूप से किसी भी समय बिंदु पर रोलबैक किया जा सकता है।
विशिष्ट संचालन में, हमने डेवलपमेंट मशीन पर CDP agent स्थापित किया, जो फ़ाइल सिस्टम के ब्लॉक-स्तरीय परिवर्तनों को लगातार कैप्चर करता है। घटना के बाद, हमने एक समय बिंदु चुना, एजेंट द्वारा डिलीशन निष्पादित करने से 2 मिनट पहले, और पूरे वर्कस्पेस को रोलबैक किया। 1400 फ़ाइलें सभी वापस आ गईं, जिनमें उन 23 घंटों के असबमिट परिवर्तन भी शामिल थे। रोलबैक में 4 मिनट से कम समय लगा।
यहाँ एक चेतावनी है: CDP सर्वशक्तिमान नहीं है। यह ब्लॉक डिवाइस स्तर पर सुरक्षा करता है, यदि एजेंट सीधे क्लाउड स्टोरेज API कॉल करके ऑब्जेक्ट हटाता है, तो CDP भी नहीं बचा सकता। इसलिए हमने मॉडल गेटवे की कॉल श्रृंखला में ऑपरेशन श्वेतसूची जोड़ी, जो भी delete, rm, drop से संबंधित निर्देश हों, उनके लिए मानवीय द्वितीयक पुष्टि अनिवार्य है।
AI कोडिंग एजेंट की API कॉल श्रृंखला को अतिरिक्त सुरक्षा परत की आवश्यकता है
उसके बाद मैंने एजेंट की कॉल श्रृंखला को पुनर्व्यवस्थित किया। यह मॉडल गेटवे के माध्यम से विभिन्न मॉडलों तक रूट करता है, token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म इस श्रृंखला में एकीकृत एक्सेस और कार्य के अनुसार स्वचालित मॉडल चयन का कार्य करता है। हमारे प्रोजेक्ट में इसका उपयोग मल्टी-मॉडल सहायक विकास के लिए किया गया, लाभ यह है कि एक Key से GPT-4o, Claude, DeepSeek, Qwen जैसे मुख्यधारा मॉडल कॉल किए जा सकते हैं, प्रत्येक मॉडल के लिए अलग से SDK और प्रमाणीकरण बनाए रखने की आवश्यकता नहीं।
लेकिन मॉडल रूटिंग स्वयं सुरक्षा समस्या का समाधान नहीं करती। हमने token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म की कॉल परत के बाहर, एक और अनुमति सत्यापन परत लगाई: एजेंट द्वारा शुरू किए गए फ़ाइल ऑपरेशन अनुरोध, पहले श्वेतसूची से गुज़रते हैं, फिर गेटवे में प्रवेश करते हैं। इस तरह भले ही मॉडल का निर्णय गलत हो, विनाशकारी ऑपरेशन फ़ाइल सिस्टम तक नहीं पहुँच पाते।
अब पीछे मुड़कर देखें, token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म "सुचारु रूप से जोड़ने" की समस्या का समाधान करता है, CDP "हटाने पर वापस आ सके" की समस्या का समाधान करता है। दोनों प्रतिस्थापन संबंध नहीं हैं। एक AI कोडिंग एजेंट को कुशलतापूर्वक मल्टी-मॉडल कॉल करने देने के लिए ज़िम्मेदार है, दूसरा उसके गलती करने पर सहारा देने के लिए। बाद में हमने CDP को डेवलपमेंट एनवायरनमेंट का डिफ़ॉल्ट कॉन्फ़िगरेशन बना दिया, नए इंजीनियरों की मशीनें तुरंत उपयोग के लिए तैयार।
यदि आप भी AI कोडिंग एजेंट का उपयोग रीफैक्टरिंग के लिए कर रहे हैं, तो सुझाव है कि पहले दो बातें सुनिश्चित करें: डेवलपमेंट एनवायरनमेंट का RPO क्या है, और एजेंट के डिलीशन ऑपरेशन में मानवीय पुष्टि चरण है या नहीं। इन दो प्रश्नों के उत्तर, यह निर्धारित करते हैं कि आपकी अगली घटना में नुकसान 4 मिनट का होगा या 23 घंटे का।
लेखक: Zhou Mingzhe
प्रकाशन तिथि: 23 अक्टूबर 2026