AI से बने कोड में बग्स को प्रोडक्शन तक पहुँचने से पहले कैसे पकड़ें

एक AI असिस्टेंट कुछ ही सेकंड में काम करता-दिखने वाला फ़ीचर बना सकता है। मुश्किल हिस्सा अब कोड जनरेट करना नहीं रहा — यह जानना है कि आप उस पर भरोसा कर सकते हैं या नहीं। AI मॉडल गलत होने पर भी आत्मविश्वासी रहते हैं, वे ऐसे API हैलुसिनेट कर देते हैं जो मौजूद ही नहीं हैं, और वे खुशी-खुशी किसी फेल हो रहे टेस्ट को असर्शन हटाकर "ठीक" कर देते हैं। अगर आप एजेंट जो भी आपको सौंपे उसे शिप कर देते हैं, तो आप असल में सॉफ़्टवेयर नहीं बना रहे; आप जुआ खेल रहे हैं।

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

1. चैट नहीं, diff पढ़ें

सबसे अधिक मूल्यवान आदत: AI के सारांश की जगह असल फ़ाइल बदलावों की समीक्षा करें। Claude Code, Cursor, और Copilot जैसे टूल बदलाव स्वीकार करने से पहले एक diff दिखाते हैं। इसे तीन सवालों के साथ सरसरी तौर पर देखें:

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

यह 30 सेकंड की स्कैनिंग "AI ने कोई बेवकूफी की" वाले ज़्यादातर पलों को पकड़ लेती है।

2. मशीन से मशीन की जाँच करवाएँ

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

• एक लिंटर (ESLint, Ruff, आदि) स्टाइल और आम गलतियों के लिए।
• एक टाइप चेकर (TypeScript, mypy) हैलुसिनेट-किए-गए-API और डेटा-के-गलत-आकार वाली बग्स की श्रेणी को पकड़ने के लिए।
• एक टेस्ट रनर व्यवहार के लिए।

तरकीब यह है कि इन्हें अनिवार्य बनाया जाए, इन्हें एक pre-commit hook में जोड़कर ताकि ये किसी भी commit के पहुँचने से पहले चलें। यहाँ JavaScript प्रोजेक्ट में Husky का उपयोग करता हुआ एक न्यूनतम उदाहरण है:

# .husky/pre-commit
npm run lint && npm run typecheck && npm test

अब अगर AI का कोड लिंटर में फेल होता है, टाइप तोड़ता है, या कोई टेस्ट फेल करता है, तो commit बस अस्वीकार कर दिया जाता है। एजेंट की गलती कभी आपकी ब्रांच तक नहीं पहुँचती। (Python में, समतुल्य है pre-commit फ़्रेमवर्क जो ruff, mypy, और pytest चलाता है।)

3. AI से टेस्ट लिखवाएँ — और चलवाएँ

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

"इस फ़ंक्शन के लिए टेस्ट लिखो जो खाली इनपुट, हैप्पी पाथ, और एक एज केस को कवर करें। फ़ंक्शन को खुद मत बदलो।"

फिर टेस्ट खुद चलाएँ, या CI में, और पुष्टि करें कि वे सचमुच असली व्यवहार जाँचते हैं। expect(result).toBeDefined() जैसा टेस्ट दिखावा है; expect(addTax(100, 0.2)).toBe(120) एक असली जाँच है। यह सुनिश्चित करने के लिए कम से कम एक असर्शन पढ़ें कि यह दूसरी तरह का है।

4. CI में एक क्वालिटी गेट जोड़ें

लोकल हुक्स आपकी मशीन की रक्षा करते हैं; एक CI जाँच प्रोजेक्ट की हर किसी से रक्षा करती है (थके हुए किसी शाम वाले भविष्य-के-आप समेत)। एक वर्कफ़्लो जोड़ें जो हर पुल रिक्वेस्ट पर लिंट, टाइप, और टेस्ट फिर से चलाए, और ब्रांच को इस तरह कॉन्फ़िगर करें कि पास होने तक merge ब्लॉक रहे। यह बिल्कुल वही विचार है जिसे बड़े प्लेटफ़ॉर्म अब एक प्रोडक्ट के रूप में बेच रहे हैं — GitHub का Code Quality, जो जुलाई 2026 में जनरली अवेलेबल हो रहा है, ऐसे गेट जोड़ता है जो maintainability या coverage गिरने पर merge ब्लॉक कर देते हैं, और Cursor ने अपनी /review कमांड को फिर से परिभाषित किया इस साल पहले एक pre-commit गेट के रूप में। आप एक साधारण GitHub Actions या GitLab CI जॉब से इसका 80% मूल्य मुफ़्त में पा सकते हैं।

5. जोखिम भरे 5% के लिए इंसान को लूप में रखें

ऑटोमेशन यह नहीं आँक सकता कि कोई फ़ीचर सही फ़ीचर है या नहीं, कोई आर्किटेक्चर फ़ैसला अच्छे से टिकेगा या नहीं, या उस "अप्रयुक्त" फ़ंक्शन को हटाना सुरक्षित है या नहीं। अपना असली ध्यान इनके लिए सुरक्षित रखें: auth, payments, या data deletion को छूने वाली कोई भी चीज़; database migrations; और साझा कोड में बदलाव जिन पर कई अन्य फ़ाइलें निर्भर हों। बाकी सब के लिए, सुरक्षा-जाल को अपना काम करने दें।

एक सरल नियम

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