AI-लिखा कोड सुरक्षित तरीके से कैसे रिव्यू करें: डेवलपर की असली चेकलिस्ट

AI किसी भी इंसान से तेज़ कोड लिखता है। यही उसकी सबसे बड़ी ताकत है, और यही वह चीज़ है जो आपकी रातों की नींद उड़ा सकती है। जब कोई डेवलपर GitHub Copilot, ChatGPT या कोई और AI कोडिंग असिस्टेंट इस्तेमाल करता है, तो आउटपुट सुथरा दिखता है, बिना एरर के कंपाइल होता है और बेसिक स्मोक टेस्ट पास कर लेता है। लेकिन उसमें अक्सर वह गहरी, संदर्भ-आधारित समझ नहीं होती जो उस बग को पकड़ सके, जो आपको प्रोडक्शन में तीसरे हफ़्ते तक नज़र नहीं आएगा।

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

AI के कोड को अलग क्या बनाता है

अगर आप सालों से कोड रिव्यू कर रहे हैं, तो आप जानते हैं कि जिस इंसान ने कोई फ़ंक्शन लिखा, वह आम तौर पर समझता है कि उसे क्या करना चाहिए, भले ही कोड गलत हो। वह सवालों के जवाब दे सकता है। उसके पास इरादा होता है।

AI के पास उस अर्थ में इरादा नहीं होता। वह प्रॉम्प्ट के आधार पर सांख्यिकीय रूप से संभावित कोड जनरेट करता है। उसने लाखों कोड उदाहरण देखे हैं, जिनमें गलत उदाहरण भी शामिल हैं। जब वह आउटपुट देता है, तो वह पैटर्न मिलाता है, समस्या हल नहीं करता।

सही होने का भ्रम

AI-जनरेटेड कोड की सबसे खतरनाक बात यह है कि वह कितना सही दिखता है। वह नामकरण के नियम मानता है। उसमें कमेंट होते हैं। वह आधुनिक सिंटैक्स इस्तेमाल करता है। अक्सर उसकी संरचना भी सही होती है। कोई डेवलपर उसे जल्दी से स्कैन करे तो बिना हिचक मंज़ूरी दे देगा।

लेकिन AI बार-बार कुछ खास विफलता के तरीकों से टकराता है:

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

वे पैटर्न जो चुपचाप टूटते हैं

वे खास पैटर्न जो कोड रिव्यू से बच निकलते हैं, लेकिन प्रोडक्शन में फ़ेल होते हैं:

एक भी लाइन पढ़ने से पहले

अच्छा कोड रिव्यू डिफ़ से शुरू नहीं होता। वह फ़ाइल खोलने से पहले शुरू होता है।

सही मानसिकता अपनाएँ

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

यह निंदा नहीं है। यह कैलिब्रेशन है। AI-जनरेटेड कोड अक्सर अच्छा होता है। लेकिन उसे ऐसे रिव्यूअर की ज़रूरत है जिसके पास सही संदेह हो।

सवाल कभी यह नहीं होता कि "यह सही लगता है?" सवाल हमेशा यह होता है कि "इसके फ़ेल होने के लिए क्या सच होना चाहिए?"

जानें कि AI को क्या बताया गया था

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

सबसे पहले खोजने वाली सिक्योरिटी होल

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

इंजेक्शन कमज़ोरियाँ

AI अक्सर स्ट्रिंग जोड़कर SQL, शेल कमांड या HTML बनाता है। यह सॉफ़्टवेयर डेवलपमेंट की सबसे पुरानी कमज़ोरियों में से एक है, और AI इसे लगातार दोहराता है क्योंकि उसका काफ़ी ट्रेनिंग डेटा भी यही करता है।

किन बातों पर ध्यान दें:

# Red flag: AI-generated SQL with string concatenation
query = "SELECT * FROM users WHERE name = '" + username + "'"

# What it should look like
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (username,))

प्रॉम्प्ट कॉपी करें

जब भी यूज़र इनपुट सैनिटाइज़ेशन या पैरामीटराइज़ेशन के बिना डेटाबेस क्वेरी, शेल कमांड, फ़ाइल पाथ या HTML टेम्पलेट में जाता है, तो आपके सामने इंजेक्शन का जोखिम होता है। ऐसे वेरिएबल से जुड़ी स्ट्रिंग कॉन्कैटिनेशन खास तौर पर खोजें जो यूज़र इनपुट से आ सकते हैं।

हार्डकोडेड सीक्रेट

AI कभी-कभी उदाहरण कोड में API की, पासवर्ड या टोकन सीधे सोर्स में लिख देता है। इससे भी बुरा यह कि वह असली दिखने वाले लेकिन नकली क्रेडेंशियल भी बनाता है, जिन्हें डेवलपर यह सोचकर छोड़ देते हैं कि बाद में बदल देंगे, और फिर बदलते नहीं।

किसी भी AI-जनरेटेड कोड के मर्ज होने से पहले सीक्रेट स्कैनर चलाएँ। truffleHog, detect-secrets या gitleaks जैसे टूल ये चीज़ें अपने आप पकड़ लेते हैं। इन्हें अपनी CI पाइपलाइन में जोड़ें और इन्हें ब्लॉकिंग मानें।

सोर्स कोड में कोई भी क्रेडेंशियल एक लीक हुआ क्रेडेंशियल है, चाहे वह असली हो या ऐसा प्लेसहोल्डर जिसे कोई बदलना भूल गया।

असुरक्षित डिपेंडेंसी

AI ऐसे पैकेज सुझा सकता है जो पुराने हों, जिनकी देखरेख बंद हो चुकी हो, या जिनमें ज्ञात CVE हों। वह वल्नरेबिलिटी के लिए पैकेज रजिस्ट्री ब्राउज़ नहीं कर सकता। उसे नहीं पता कि किसी लाइब्रेरी के किस वर्ज़न में पिछले महीने कौन-सा महत्वपूर्ण सिक्योरिटी पैच आया।

AI-जनरेटेड कोड रिव्यू करने के बाद अपने डिपेंडेंसी ऑडिट टूल चलाएँ:

• Node.js प्रोजेक्ट्स के लिए npm audit
• Python के लिए pip-audit या safety
• Ruby के लिए bundle-audit

AI आउटपुट से आई कोई भी डिपेंडेंसी मर्ज करने से पहले मौजूदा वल्नरेबिलिटी डेटाबेस से वेरिफ़ाई की जानी चाहिए।

लॉजिक और सही होने की जाँच

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

वे एज केस जो AI ने छोड़ दिए

AI हैप्पी पाथ के लिए कोड बनाता है। वह प्रॉम्प्ट में बताए गए इनपुट को संभालता है। वह इन्हें नहीं संभालता:

• खाली कलेक्शन या null रेफ़रेंस
• मान्य रेंज की ठीक सीमा पर इनपुट
• एक ही फ़ंक्शन को एक साथ कई कॉल
• नेटवर्क टाइमआउट या आंशिक रिस्पॉन्स
• डिस्क भरना या मेमोरी खत्म होना

आपके द्वारा रिव्यू किए गए हर फ़ंक्शन के लिए पूछें: अगर सबसे महत्वपूर्ण इनपुट null हो तो क्या होगा? अगर यह फ़ंक्शन खाली लिस्ट के साथ कॉल हो तो क्या होगा? अगर नेटवर्क कॉल 200 लौटाए लेकिन बॉडी खाली हो तो क्या होगा?

अगर AI ने इन सवालों के जवाब कोड में नहीं दिए, तो या तो आपको खुद हैंडलिंग जोड़नी होगी या कोड को संशोधन के लिए वापस भेजना होगा।

एरर हैंडलिंग जो कुछ नहीं करती

AI को try-catch ब्लॉक जनरेट करना बहुत पसंद है। समस्या यह है कि वह उन ब्लॉकों में क्या डालता है। साइलेंट कैच हर जगह मिलते हैं। console.log(err) को लॉग करके ऐसे आगे बढ़ जाना जैसे कुछ हुआ ही न हो, आम बात है। जब कॉलर को किसी खास एरर की ज़रूरत हो, तब भी किसी जेनेरिक एरर को दोबारा थ्रो करना लगभग हर जगह होता है।

AI कोड के हर एक्सेप्शन हैंडलर की अलग से जाँच होनी चाहिए:

• क्या यह सच में एरर को संभालता है, या बस उसे छिपाता है?
• क्या कॉल करने वाले कोड को पता है कि कुछ गलत हुआ?
• क्या यह एरर इस तरह लॉग होता है कि बाद में उसे ढूँढा जा सके?
• क्या इस कैच ब्लॉक के चलने के बाद एप्लिकेशन एक सुसंगत स्थिति में है?

ऑफ़-बाय-वन और सीमा की गलतियाँ

लूप की सीमाएँ वह जगह हैं जहाँ AI इंसानों से ज़्यादा दर पर लगातार गलती करता है। AI कोड अक्सर वहाँ < इस्तेमाल करता है जहाँ <= चाहिए, किसी ऐरे के आखिरी छोर से एक एलिमेंट आगे तक इटरेट करता है, या जब 0 से शुरू होना चाहिए तब 1 से रेंज शुरू करता है। ये बग छोटे टेस्ट में दिखते ही नहीं, और बड़े पैमाने पर असली डेटा प्रोसेस करते समय विनाशकारी होते हैं।

AI-जनरेटेड कोड के किसी भी लूप या रेंज के लिए पहले इटरेशन, आखिरी इटरेशन और शून्य-एलिमेंट वाले मामले को हाथ से ट्रेस करें।

आपका रिव्यू तेज़ करने वाले टूल

मैनुअल रिव्यू ज़रूरी है, पर अकेला काफ़ी नहीं है। ऑटोमेटेड टूल उन श्रेणियों की समस्याएँ पकड़ते हैं जो समय के दबाव में इंसानों से छूट जाती हैं, और वे यह लगातार करते हैं।

स्टैटिक एनालिसिस और लिंटर

स्टैटिक एनालिसिस आपकी पहली रक्षा पंक्ति है। यह किसी इंसान के कोड देखने से पहले चलता है और सबसे आसान दिखने वाली समस्याएँ अपने आप पकड़ लेता है।

भाषा के अनुसार सुझाए गए टूल:

इन टूल को हर पull request पर अपने आप चलने के लिए कॉन्फ़िगर करें। जो AI-जनरेटेड कोड स्टैटिक एनालिसिस पास नहीं करता, वह इंसानी रिव्यू तक नहीं पहुँचना चाहिए।

AI-सहायता वाला कोड रिव्यू

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

AI आउटपुट को किसी दूसरे AI रिव्यूअर से चलाना इंसानी रिव्यू का विकल्प नहीं है। यह एक फ़िल्टर है जो इंसानी रिव्यू को तेज़ और ज़्यादा केंद्रित बनाता है।

कोड रिव्यू के लिए PicassoIA पर LLM इस्तेमाल करें

PicassoIA के लार्ज लैंग्वेज मॉडल ठीक इसी तरह के तर्क वाले काम के लिए बनाए गए हैं। आप कोड स्निपेट पेस्ट कर सकते हैं, रिव्यू-केंद्रित प्रॉम्प्ट दे सकते हैं, बिना टूल बदले और API keys संभाले, कुछ ही सेकंड में संरचित विश्लेषण पा सकते हैं।

कोड रिव्यू के लिए GPT 5 कैसे इस्तेमाल करें

GPT 5 कोड विश्लेषण के लिए सबसे सक्षम मॉडलों में से एक है। इसकी ताकत व्यापक संदर्भ में है: यह एक बड़ा फ़ंक्शन मेमोरी में रख सकता है, कई आपस में जुड़ी समस्याएँ पहचान सकता है, और हर एक को साफ़ समझा सकता है।

चरण-दर-चरण:

1. PicassoIA पर GPT 5 खोलें
2. वह AI-जनरेटेड फ़ंक्शन या मॉड्यूल पेस्ट करें जिसका रिव्यू चाहिए
3. यह प्रॉम्प्ट संरचना इस्तेमाल करें:

Review this code for: (1) security vulnerabilities, (2) unhandled edge cases,
(3) error handling issues, (4) logic errors. For each issue found, explain
the risk and suggest a specific fix. Reference line numbers or variable names.

प्रॉम्प्ट कॉपी करें

4. आउटपुट को आलोचनात्मक नज़र से देखें। सुझावों को आँख मूँदकर न मानें।
5. संशोधित कोड वापस पेस्ट करें और उसे उन खास समस्याओं को दोबारा वेरिफ़ाई करने को कहें जो उसने चिह्नित की थीं।

GPT 5.1 भी उपलब्ध है, अगर आप बहु-चरणीय रिव्यू पाइपलाइन ऑटोमेट करना चाहते हैं, तो एजेंट-आधारित वर्कफ़्लो के लिए।

सिक्योरिटी ऑडिट के लिए Claude 4.5 Sonnet

Claude 4.5 Sonnet सूक्ष्म सिक्योरिटी समस्याएँ पहचानने में खास मज़बूत है। जहाँ GPT व्यापकता की ओर झुकता है, वहाँ Claude खास सिक्योरिटी परिदृश्यों में गहराई में जाने में उत्कृष्ट है।

सिक्योरिटी-केंद्रित रिव्यू के लिए Claude 4.5 Sonnet उन प्रॉम्प्ट के साथ खास तौर पर प्रभावी है जो उससे थ्रेट मॉडल के ज़रिए चरण-दर-चरण तर्क करने को कहते हैं। कुछ ऐसा: "मान लें कि हमलावर username पैरामीटर को नियंत्रित करता है। इस कोड में वह पैरामीटर जितने रास्ते लेता है, उन सबको ट्रेस करें और बताएँ कि उसका शोषण कहाँ हो सकता है।"

Claude 4 Sonnet और Claude Opus 4.7 भी PicassoIA पर उपलब्ध हैं, ज़्यादा मुश्किल रिव्यू कार्यों या लंबे कोडबेस के लिए जिनमें गहरे तर्क की ज़रूरत हो।

गहरे तर्क के लिए DeepSeek R1

DeepSeek R1 चेन-ऑफ़-थॉट तर्क इस्तेमाल करता है, जिससे वह जटिल कोड पथों में तर्क ट्रेस करने में खास अच्छा है। अगर आपके पास कई ब्रांच, नेस्टेड कंडीशनल या जटिल स्टेट मैनेजमेंट वाला फ़ंक्शन है, तो DeepSeek R1 हर ब्रांच पर स्पष्ट रूप से तर्क करेगा, ऊँचे स्तर पर सार नहीं देगा।

जो डेवलपर एक ही कोड को कई मॉडलों से चलाकर नतीजों की तुलना करना चाहते हैं, उनके लिए DeepSeek V3.1 और Kimi K2 Instruct भी विकल्प हैं। जिन समस्याओं पर सभी मॉडल सहमत हों, उन्हें ठीक करना है। असहमति वाले बिंदु हाथ से जाँचने लायक हैं।

एक ही AI-जनरेटेड कोड को दो या तीन अलग-अलग LLM से चलाना सबसे अधिक रिटर्न देने वाले रिव्यू चरणों में से एक है। इसमें पाँच मिनट लगते हैं और वह पकड़ लेता है जो एक अकेला रिव्यूअर छोड़ देता है।

अपना रिव्यू वर्कफ़्लो बनाएँ

अच्छी रिव्यू प्रक्रिया हर बार इधर-उधर से जुगाड़ करके नहीं बनती। यह एक दोहराने लायक चेकलिस्ट है जो आदत बन जाती है।

वह चेकलिस्ट जिसे आप दोबारा इस्तेमाल कर सकते हैं

AI-जनरेटेड कोड के लिए यह संक्षिप्त रिव्यू चेकलिस्ट है। इसे हर बार इस्तेमाल करें, कोई चरण छोड़े बिना।

चरण 1: पढ़ने से पहले

• क्या मुझे पता है कि यह कोड किस प्रॉम्प्ट से बना?
• क्या मैंने स्टैटिक एनालिसिस टूल चलाए हैं?
• क्या मैंने सीक्रेट स्कैनर चलाया है?
• क्या मैंने नई डिपेंडेंसी को वल्नरेबिलिटी डेटाबेस से जाँचा है?

चरण 2: सिक्योरिटी

• क्या यूज़र इनपुट वाली कोई स्ट्रिंग कॉन्कैटिनेशन SQL, शेल या HTML में जा रही है?
• क्या सोर्स में कोई क्रेडेंशियल, टोकन या API की है?
• क्या कोई नेटवर्क कॉल है जो रिस्पॉन्स को वेरिफ़ाई या सैनिटाइज़ नहीं करती?
• क्या कोई फ़ाइल ऑपरेशन यूज़र-नियंत्रित पाथ इस्तेमाल करता है?
• क्या कोई फ़ंक्शन ऑथेंटिकेशन या ऑथराइज़ेशन चेक छोड़ता है?

चरण 3: लॉजिक

• null या खाली इनपुट के साथ क्या होता है?
• सीमा मानों (0, -1, अधिकतम) पर क्या होता है?
• क्या एक्सेप्शन हैंडलर सच में एरर संभाल रहे हैं या छिपा रहे हैं?
• क्या लूप की सीमाएँ सही हैं? पहला और आखिरी इटरेशन हाथ से ट्रेस करें।
• क्या इस फ़ंक्शन में कॉल के क्रम या स्टेट के बारे में छिपी धारणाएँ हैं?

चरण 4: टेस्टिंग

• क्या मौजूदा टेस्ट नए कोड पथों को कवर करते हैं?
• क्या ऊपर पहचाने गए एज केस के लिए टेस्ट हैं?
• क्या टेस्ट विफलता के पथों को कवर करते हैं, सिर्फ़ हैप्पी पाथ को नहीं?

कब रिजेक्ट करें और कब सुधारें

हर AI कोड संशोधन के लायक नहीं होता। उसका कुछ हिस्सा सीधे रिजेक्ट होना चाहिए।

रिजेक्ट करें जब:

• सिक्योरिटी कमज़ोरियाँ संरचनात्मक हों, सतही नहीं (उदाहरण के लिए, पूरा ऑथेंटिकेशन तरीका ही खराब हो)
• लॉजिक बिज़नेस आवश्यकता से इस तरह मेल न खाए कि उसे पैच करना बहुत गहरा हो
• कोड मौजूदा परंपराओं से टकराने वाला आर्किटेक्चरल पैटर्न लाए

सुधारें जब:

• समस्याएँ खास फ़ंक्शन या ब्लॉक तक सीमित हों
• संरचना सही हो, लेकिन कुछ एज केस छूटे हों
• एरर हैंडलिंग अपर्याप्त हो, पर मुख्य लॉजिक ठीक हो

लक्ष्य AI कोड को तब तक ठीक करना नहीं है जब तक वह रिव्यू पास न कर ले। लक्ष्य सुरक्षित, सही कोड शिप करना है। कभी-कभी सबसे कुशल रास्ता बेहतर प्रॉम्प्ट के साथ साफ़ दोबारा लिखना होता है।

PicassoIA पर आज़माएँ

अगर यह लेख आपको सोचने पर मजबूर कर रहा है कि AI मॉडल कोड के बारे में कैसे तर्क करते हैं, तो अगला सबसे अच्छा कदम खुद परखना है। PicassoIA आपको GPT 5, Claude 4.5 Sonnet, DeepSeek R1, Kimi K2 Instruct, Gemini 3 Pro और दर्जनों दूसरे मॉडल एक ही जगह, बिना किसी सेटअप के, उपलब्ध कराता है।

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

PicassoIA पर उपलब्ध मॉडल सिर्फ़ कोड लिखने के लिए नहीं हैं। वे उस पर तर्क करने, उसका ऑडिट करने और उसे सुरक्षित बनाने के लिए हैं। यही वह चक्र है जो AI-सहायता वाले डेवलपमेंट को सचमुच काम का बनाता है: एक मॉडल से जनरेट करें, दूसरे से रिव्यू करें, और भरोसे के साथ शिप करें।