AI से बने कोड की समीक्षा कैसे करें

AI से लिखे कोड की समीक्षा करने के लिए शुरुआत इससे करें कि क्या बदला है: कौन सी फ़ाइलें और क्यों। फिर किसी भी लाइन को पढ़ने से पहले खुद व्यवहार टेस्ट करें। उसके बाद उन जगहों की जाँच करें जहाँ AI कोड अक्सर गलत होता है: सर्वर-साइड अनुमति जाँच का न होना, ब्राउज़र को दिखते सीक्रेट, बिना वैलिडेशन के इनपुट, ऐसे पैकेज या फ़ंक्शन जो मौजूद नहीं हैं, और ऐसी चीज़ों में बदलाव जो आपने कभी माँगी ही नहीं थीं।

AI ऐसा कोड लिखता है जो आम तौर पर चलता है और अक्सर साफ़-सुथरा भी दिखता है। इसी से उसे बिना असली जाँच के मंज़ूर कर देना आसान हो जाता है। यह गाइड एक समीक्षा प्रक्रिया है जो इस बात पर निर्भर नहीं करती कि आप कोड अच्छी तरह पढ़ सकते हैं या बिल्कुल नहीं।

जोखिम के हिसाब से समीक्षा रखें

हर बदलाव को एक जैसे ध्यान की ज़रूरत नहीं है।

चरण 1: देखें क्या बदला

कोड पर फ़ैसला देने से पहले बदलावों की सूची लें:

• अगर प्रोजेक्ट Git में है, तो diff देखें: पिछले commit के बाद बदली हुई फ़ाइलें और लाइनें। देखें AI से बने ऐप के साथ Git कैसे इस्तेमाल करें।
• या सीधे AI से पूछें:

पिछले बदलाव में तुमने जो भी फ़ाइलें बदलीं, उनकी सूची दो, और हर एक के लिए एक वाक्य में बताओ कि क्या बदला और क्यों।

इस चरण पर चेतावनी के संकेत: अनुरोध से असंबंधित फ़ाइलें, हटाई गई फ़ाइलें, या कॉन्फ़िगरेशन या डिपेंडेंसी में ऐसे बदलाव जो आपने नहीं माँगे।

चरण 2: पहले व्यवहार टेस्ट करें

कोड पढ़ने से पता चलता है कि उसे क्या करना चाहिए; टेस्टिंग से पता चलता है कि वह असल में क्या करता है। पढ़ने से पहले:

• बदलाव को एक सामान्य यूज़र की तरह आज़माएं, डेस्कटॉप और फ़ोन-साइज़ स्क्रीन पर।
• गलत इनपुट के साथ आज़माएं: खाली फ़ील्ड, बहुत लंबा टेक्स्ट, ऋणात्मक संख्याएँ, बीते हुए दिन की तारीख।
• लॉग आउट होकर, और एक अलग यूज़र के रूप में आज़माएं।
• सबसे ज़रूरी फ़्लो दोबारा चलाएं: साइनअप, लॉगिन, मुख्य काम, पेमेंट।

अगर टेस्टिंग विफल होती है, तो पढ़ने का समय बच गया। इसे साफ़ तौर पर रिपोर्ट करें और AI को ठीक करने दें। देखें अच्छी बग रिपोर्ट कैसे लिखें।

चरण 3: सर्वर पर अनुमतियाँ जाँचें

यह सबसे ज़रूरी चीज़ है। AI टूल अक्सर पेज में बटन छिपा देते हैं, पर सर्वर को किसी भी माँगने वाले के लिए काम करने की अनुमति छोड़ देते हैं।

हर उस रूट या फ़ंक्शन के लिए जो डेटा पढ़ता या बदलता है, पूछें:

• क्या यह जाँचता है कि यूज़र लॉगिन है?
• क्या यह जाँचता है कि यह यूज़र इस रिकॉर्ड तक पहुँच सकता है?
• क्या यह जाँच सर्वर पर है, सिर्फ़ पेज में नहीं?

मैंने जो भी API रूट जोड़े या बदले हैं, उनमें से हर एक के लिए बताओ कि सर्वर पर वह कौन सी अनुमति जाँच करता है, और वह लाइन उद्धृत करो। जिस रूट में जाँच न हो, उसे चिह्नित करो।

फिर उसे टेस्ट करें: यूज़र A के रूप में लॉगिन करें, किसी रिकॉर्ड की ID नोट करें, फिर यूज़र B के रूप में लॉगिन करके उसी ID का अनुरोध करें। पूरी जाँच के लिए AI से बने ऐप्स की सुरक्षा चेकलिस्ट देखें।

चरण 4: लीक हुए सीक्रेट खोजें

• बदली हुई फ़ाइलों में किसी key या पासवर्ड जैसी चीज़ खोजें।
• जाँचें कि सीक्रेट keys environment variables से पढ़ी जाती हैं और सिर्फ़ सर्वर कोड में इस्तेमाल होती हैं।
• सीक्रेट variables पर VITE_ या NEXT_PUBLIC_ जैसे सार्वजनिक prefixes पर ध्यान दें; वे ब्राउज़र कोड में बिल्ड हो जाते हैं।

देखें API keys कैसे सुरक्षित रखें।

चरण 5: इनपुट और एरर जाँचें

• सर्वर पर वैलिडेशन। ब्राउज़र की जाँच छोड़ी जा सकती है। ज़रूरी फ़ील्ड, लंबाई, फ़ॉर्मेट और अनुमत मान सर्वर पर भी जाँचे जाएं।
• डेटाबेस क्वेरी पैरामीटर इस्तेमाल करती हैं, यूज़र इनपुट को सीधे क्वेरी में जोड़कर टेक्स्ट नहीं बनाती।
• एरर चुपचाप निगली नहीं जातीं। कुछ न करने वाला try/catch विफलताओं को छिपाता है। एरर लॉग होनी चाहिए, और यूज़र को सरल संदेश दिखना चाहिए।
• यूज़र को आंतरिक विवरण न दिखें: stack traces और डेटाबेस एरर लॉग में रहने चाहिए।

चरण 6: जाँचें कि चीज़ें असली हैं

AI मॉडल कभी-कभी ऐसा कोड बनाते हैं जो सही दिखता है, पर ऐसी चीज़ों का ज़िक्र करता है जो मौजूद ही नहीं हैं।

• पैकेज: हर नई डिपेंडेंसी एक असली, रखरखाव वाला पैकेज होना चाहिए, ठीक उसी नाम से। ऐसे नामों से सावधान रहें जो लोकप्रिय नामों की टाइपो जैसे लगें।
• फ़ंक्शन और API विकल्प: अगर कोड कोई लाइब्रेरी फ़ंक्शन या बाहरी API विकल्प कॉल करता है जो आपने कभी नहीं देखा, तो आधिकारिक दस्तावेज़ जाँचें।
• प्लेसहोल्डर कोड: TODO, mock, fake, हार्ड-कोडेड सैंपल डेटा, या ऐसे फ़ंक्शन जो एक तय मान लौटाते हैं, इन्हें खोजें।

क्या तुमने कोई नए पैकेज जोड़े हैं? हर एक का सटीक नाम दो, बताओ कि वह किस काम आता है, और क्या हम उसके बिना काम चला सकते हैं।

चरण 7: जाँचें कि यह फ़िट होता है

कोड काम कर सकता है और फिर भी ऐप को बाद में बदलना कठिन बना सकता है:

• दोहराव। एक ही लॉजिक कई जगह कॉपी होगा तो वे अलग होते जाएंगे।
• एकरूपता। उसे उन पैटर्न का पालन करना चाहिए जो बाकी ऐप इस्तेमाल करता है।
• आकार। 600 लाइनें जो 20 लाइन के अनुरोध से बनीं, उस पर सवाल बनता है।
• मृत कोड। नए संस्करणों के साथ छोड़े गए पुराने संस्करण।

क्या प्रोजेक्ट में कोई कोड है जो इस बदलाव के कारण अब इस्तेमाल नहीं हो रहा, या कोई लॉजिक कहीं और दोहराया गया है? कुछ मत बदलो; बस सूची दो।

आम गलतियाँ

• साफ़ दिखने की वजह से मंज़ूर कर देना। सुथरा कोड भी अनुमति जाँच छोड़ सकता है।
• टेस्ट करने के बजाय सिर्फ़ पढ़ना। पहले टेस्ट करें, फिर पढ़ें।
• सिर्फ़ सही रास्ते की जाँच। खराब इनपुट, गलत यूज़र और लॉग आउट अवस्था भी आज़माएं।
• असंबंधित फ़ाइल बदलावों को नज़रअंदाज़ करना। पूछें कि हर फ़ाइल क्यों बदली।
• AI की स्व-समीक्षा पर पूरी तरह भरोसा। उसकी समीक्षा को पहला पास मानें और टेस्टिंग से पुष्टि करें।
• एक हफ़्ते के बदलावों की एक साथ समीक्षा। छोटे बदलावों की समीक्षा तभी करें जब वे हों।

चेकलिस्ट

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

Mythex पर कोड की समीक्षा

• Ask mode कोड को बदले बिना उसके बारे में सवालों का जवाब देता है, जो “हर बदलाव समझाओ” और “कौन से रूट में अनुमति जाँच नहीं है” जैसे सवालों के लिए आदर्श है। देखें Chat।
• Code view हर प्लान पर फ़ाइल ट्री, एडिटर और टर्मिनल दिखाता है (Free पर केवल पढ़ने योग्य, Pro पर संपादन योग्य), ताकि आप खुद पढ़ सकें कि क्या बदला। देखें Code editor।
• /test एजेंट को आपके प्रीव्यू में उपयोगकर्ता की तरह क्लिक करवाता है और टूटे फ़्लो की रिपोर्ट देता है।
• Checkpoints आपको ऐसा बदलाव वापस लेने देते हैं जो समीक्षा में विफल हो।

अगर कोई डेवलपर आपके लिए समीक्षा कर रहा है, तो AI से बने ऐप पर डेवलपर के साथ कैसे काम करें हैंडऑफ़ समझाता है; और अगर समीक्षा में कोई बग निकले, तो AI से बने ऐप को कैसे डीबग करें देखें।

सवाल