AI टूल डेवलपरों को सॉफ़्टवेयर की समस्याएँ पहले से तेज़ी से खोजने में मदद कर रहे हैं। curl और PostgreSQL 19 के अनुभव दिखाते हैं कि अगली चुनौती यह तय करना है कि कौन-सी खोजें मायने रखती हैं, उन्हें सुरक्षित ढंग से ठीक करना और गहन कोड रिव्यू के लिए पर्याप्त समय निकालना।
जब बग खोजना उन्हें संभालने से आसान हो जाए
वर्षों तक curl ने उन सुरक्षा शोधकर्ताओं को इनाम दिया जिन्होंने उसके सॉफ़्टवेयर में असली कमज़ोरियाँ खोजीं। इस प्रोग्राम से 87 सुरक्षा कमज़ोरियों का पता चला और $100,000 से ज़्यादा इनाम दिए गए।
फिर आने वाली रिपोर्टों की गुणवत्ता बदल गई।
2025 से पहले, 15 प्रतिशत से ज़्यादा सबमिशन असली सुरक्षा कमज़ोरियों के रूप में पुष्ट होते थे। 2025 के दौरान यह आँकड़ा पाँच प्रतिशत से नीचे आ गया। कई रिपोर्ट विश्वसनीय लगती थीं, पर उनमें ऐसी समस्याएँ बताई गई थीं जिन्हें मेंटेनर दोहरा नहीं पाए या पुष्ट नहीं कर पाए।
curl के मेंटेनर Daniel Stenberg ने कहा कि प्रोजेक्ट को कम गुणवत्ता वाले सबमिशन की बढ़ती संख्या मिल रही थी, जिनमें से कई AI की मदद से बनाए गए थे। उनकी जाँच में वह समय लग रहा था जो सॉफ़्टवेयर को बेहतर बनाने में लगाया जा सकता था।
26 जनवरी 2026 को Stenberg ने घोषणा की कि curl का पेड बग बाउंटी बंद हो जाएगा। यह प्रोग्राम आधिकारिक रूप से 31 जनवरी को खत्म हो गया।
यह फ़ैसला असामान्य था, क्योंकि सिद्धांत रूप में ज़्यादा सुरक्षा समस्याएँ खोजना सॉफ़्टवेयर को ज़्यादा सुरक्षित बनाने में मदद करना चाहिए। फिर भी इस अनुभव ने दिखाया कि आसान खोज रखरखाव को कैसे मुश्किल भी बना सकती है।
AI टूल कोड को जाँच सकते हैं और सुझा सकते हैं कि कहीं कुछ गलत हो सकता है। लेकिन वे हर सुझाव को सही नहीं बना सकते। डेवलपर को फिर भी तय करना पड़ता है कि बताई गई समस्या सच में हो सकती है या नहीं, और उससे यूज़र्स को जोखिम है या नहीं।
यह काम तब मुश्किल हो जाता है जब रिपोर्ट प्रोजेक्ट के जाँच कर पाने से ज़्यादा तेज़ी से आने लगती हैं।
curl का अनुभव खास तौर पर इसलिए उजागर करने वाला था क्योंकि रिपोर्टों की गुणवत्ता सुधरने पर भी समस्या खत्म नहीं हुई।
curl की समस्या बदल गई, पर काम का बोझ बना रहा
अप्रैल 2026 तक Stenberg एक बिल्कुल अलग स्थिति बता रहे थे।
पुष्ट सुरक्षा कमज़ोरियों के रूप में मानी गई सबमिशन का अनुपात लौटकर लगभग 15 से 16 प्रतिशत हो गया था। ज़्यादा रिपोर्ट असली बग पहचान रही थीं, भले ही वे समस्याएँ सुरक्षा कमज़ोरी की श्रेणी में न आती हों।
गुणवत्ता सुधर गई थी, पर रिपोर्टों की संख्या भी बढ़ गई थी। वे 2025 की दर से लगभग दोगुनी रफ़्तार से आ रही थीं।
curl के लिए समस्या अब बहुत सारे अविश्वसनीय दावों की जाँच करने से बदलकर उपयोगी खोजों की बढ़ती संख्या को संभालने की हो गई थी।
पुष्ट सुरक्षा कमज़ोरी के लिए सिर्फ़ यह मान लेना काफ़ी नहीं कि समस्या मौजूद है। मेंटेनर को उसका कारण समझना, उसकी गंभीरता तय करना, सुधार तैयार करना और यह पक्का करना होता है कि फ़िक्स कोई नई समस्या पैदा न करे।
एक छोटे open source प्रोजेक्ट में इस काम के लिए शायद कुछ ही अनुभवी लोग उपलब्ध हों। वही योगदानकर्ता मौजूदा फ़ीचर भी संभालते हैं, बदलावों की समीक्षा करते हैं और रिलीज़ तैयार करते हैं।
इसलिए बेहतर खोजें असली फ़ायदे देती हैं, पर वे मेंटेनरों के जल्दी पूरा कर पाने से ज़्यादा काम भी सामने ला सकती हैं।
इसीलिए रिपोर्ट की गुणवत्ता और रिव्यू की क्षमता को अलग-अलग देखना चाहिए। सबमिशन के सख्त मानक बेकार की जाँच घटा सकते हैं। वे असली खामियों से पैदा होने वाले इंजीनियरिंग काम को खत्म नहीं कर सकते।
GitHub ने मई 2026 में एक मिलता-जुलता कदम उठाया, जब उसने अपने बग बाउंटी प्रोग्राम की शर्तें सख्त कीं। AI इस्तेमाल करने वाले शोधकर्ताओं को सबमिशन से पहले अपनी खोजों की जाँच करनी होगी और रिपोर्ट की गई समस्या का काम करता हुआ डेमो देना होगा।
यह नीति AI की मदद से होने वाले शोध को हतोत्साहित नहीं करती। वह रिपोर्ट करने वाले से कहती है कि मेंटेनरों को देने से पहले वह साबित करे कि उसका दावा भरोसेमंद है।
इससे प्रक्रिया की शुरुआत में टाला जा सकने वाला काम घटता है। PostgreSQL 19 दिखाता है कि जब मुश्किल समस्याएँ रिलीज़ की डेडलाइन के करीब बनी रहती हैं तो क्या हो सकता है।
PostgreSQL 19 में देरी की असली वजह क्या थी
PostgreSQL सबसे व्यापक रूप से इस्तेमाल होने वाले open source डेटाबेस सिस्टम में से एक है। इसका वर्शन 19 रिलीज़ मूल रूप से 2026 की शरद ऋतु में आने की उम्मीद थी।
रिलीज़ का शेड्यूल बदल गया, और वर्शन 19 से कई नियोजित फ़ीचर हटा दिए गए।
PostgreSQL के एक प्रमुख डेवलपर Peter Eisentraut ने अक्टूबर में लिखा कि लगभग आठ से दस महत्वपूर्ण फ़ीचर रिवर्ट किए गए थे। रिवर्ट का मतलब है पहले स्वीकार किए गए कोड बदलाव को हटाना, आम तौर पर इसलिए कि वह रिलीज़ में रहने के लिए तैयार नहीं है।
कुछ रिपोर्टों ने इन हटाए जाने को AI की मदद से हुए कोड रिव्यू से जोड़ा। तर्क यह था कि AI टूल ने इतने ज़्यादा बग खोज लिए कि डेवलपर रिलीज़ से पहले उन्हें ठीक नहीं कर सके।
AI ने समस्याएँ खोजने में योगदान दिया, लेकिन यह स्थिति का सिर्फ़ एक हिस्सा था।
Eisentraut ने कई कारण बताए। कुछ फ़ीचर में गंभीर डिज़ाइन समस्याएँ थीं जिनके लिए व्यापक बदलाव करने पड़ते। दूसरों में छोटी खामियाँ थीं जो LLM की मदद से हुए कोड रिव्यू से खोजना आसान हो गई थीं।
साथ ही, अनुभवी PostgreSQL योगदानकर्ताओं ने रिलीज़ चक्र का बड़ा हिस्सा सुरक्षा मुद्दों से निपटने में बिताया था। इससे नए फ़ीचर की समीक्षा के लिए कम समय बचा। इसलिए रिव्यू चक्र में देर से हुआ, और डेवलपरों को समस्याएँ तब मिलीं जब उन्हें हल करने के लिए बहुत कम समय बचा था।
PostgreSQL की जटिलता ने कुछ फ़िक्स को खास तौर पर कठिन बना दिया। फ़ीचर को डेटाबेस सेटिंग, डेटा टाइप और ऑपरेशन के कई संयोजनों में सही ढंग से काम करना होता है। जो बदलाव सामान्य स्थिति में चलता है, वह कई कम आम फ़ीचर साथ इस्तेमाल होने पर विफल हो सकता है।
AI की मदद से होने वाली टेस्टिंग इन असामान्य संयोजनों को खोजने में मदद कर सकती है। पर डेवलपमेंट के अंत के करीब मिली समस्या को सुलझाने में रिलीज़ शेड्यूल से ज़्यादा समय लग सकता है।
PostgreSQL योगदानकर्ता Tomas Vondra ने बारह रिवर्ट किए गए बदलावों के पीछे की चर्चाओं की जाँच की। उन्होंने एक को AI से जुड़ा और एक को संभवतः AI से जुड़ा बताया। बाकी ज़्यादातर रिवर्ट को AI से जोड़ने का साफ़ आधार उन्हें नहीं मिला।
Vondra ने इसे उपलब्ध डेवलपमेंट चर्चाओं के अपने आकलन के रूप में रखा, AI से खोजे गए हर बग की आधिकारिक गिनती के रूप में नहीं।
Christophe Pettus ने एक मिलती-जुलती व्याख्या दी। उन्होंने तर्क दिया कि एक अहम समस्या यह थी कि रिव्यू कब हुआ। सुरक्षा के काम ने अनुभवी योगदानकर्ताओं को व्यस्त रखा, इसलिए कुछ फ़ीचर रिव्यू सामान्य से देर से हुए।
ये बयान हर हटाए गए फ़ीचर का एक ही कारण स्थापित नहीं करते। पर ये दिखाते हैं कि यह जाना-पहचाना दावा अधूरा क्यों है कि AI ने डेवलपरों के ठीक कर पाने से ज़्यादा बग खोज लिए।
कुछ समस्याएँ डिज़ाइन से ही कठिन थीं। कुछ बेहतर टेस्टिंग से दिखने लगीं। बाकी देर से खोजी गईं क्योंकि रिव्यू के लिए ज़रूरी लोग कहीं और व्यस्त थे।
| स्रोत | किसकी जाँच की | क्या कहता है | क्या नहीं दिखाता |
|---|---|---|---|
| Peter Eisentraut, 9 अक्टूबर 2026 | लगभग आठ से दस महत्वपूर्ण फ़ीचर क्यों रिवर्ट किए गए | कई कारण: गंभीर डिज़ाइन समस्याएँ, छोटी खामियाँ जो LLM की मदद से हुए कोड रिव्यू से खोजना आसान हो गईं, और सुरक्षा का काम जिसने अनुभवी योगदानकर्ताओं को व्यस्त रखा। | AI से खोजे गए बग की गिनती, या हर हटाए गए फ़ीचर का एक ही कारण। |
| Tomas Vondra | बारह रिवर्ट किए गए बदलावों के पीछे की चर्चाएँ | एक AI से जुड़ा, एक संभवतः AI से जुड़ा, और बाकी ज़्यादातर को AI से जोड़ने का साफ़ आधार नहीं। | आधिकारिक गिनती। यह उपलब्ध चर्चाओं का उनका आकलन है। |
| Christophe Pettus | रिव्यू कब हुआ | सुरक्षा के काम ने अनुभवी योगदानकर्ताओं को व्यस्त रखा, इसलिए कुछ फ़ीचर रिव्यू सामान्य से देर से हुए। | कि सिर्फ़ यह समय ही हर हटाए गए फ़ीचर की व्याख्या करता है। |
| PostgreSQL प्रोजेक्ट, 15 अक्टूबर 2026 | रिलीज़ का शेड्यूल | 12 नवंबर को दूसरा रिलीज़ कैंडिडेट और 19 नवंबर 2026 को जनरल अवेलेबिलिटी, ताकि तय नवंबर अपडेट के फ़िक्स शामिल हो सकें। | कोई पक्की तारीख। जनरल अवेलेबिलिटी से पहले शेड्यूल बदल सकता है। |
| Snowflake Engineering, 16 सितंबर 2026 | AI की मदद से हुई टेस्टिंग और रिलीज़ के फ़ैसलों का एक अतिरिक्त विवरण | आगे पढ़ने के लिए सूचीबद्ध। | 16 सितंबर के बाद प्रकाशित कुछ भी, ऊपर के अक्टूबर के बयानों समेत। |
PostgreSQL प्रोजेक्ट की 15 अक्टूबर की घोषणा में 12 नवंबर को दूसरा रिलीज़ कैंडिडेट और 19 नवंबर 2026 को जनरल अवेलेबिलिटी तय की गई। प्रोजेक्ट ने कहा कि वह वर्शन 19 को सबके लिए उपलब्ध कराने से पहले अपने तय नवंबर अपडेट के फ़िक्स शामिल करना चाहता था।
इसलिए PostgreSQL का अनुभव इस बात का सबूत नहीं है कि AI ने रिलीज़ में देरी करवाई। यह दिखाता है कि ज़्यादा असरदार टेस्टिंग, जटिल सॉफ़्टवेयर और कोड रिव्यू का समय रिलीज़ के फ़ैसलों को कैसे प्रभावित कर सकते हैं।
टूल के समस्या खोजने के बाद क्या होता है
इस काम को एक सरल उदाहरण से बेहतर समझा जा सकता है।
मान लीजिए एक AI टूल किसी वेब एप्लिकेशन की समीक्षा करता है और चेतावनी देता है कि कोई अप्रत्याशित इनपुट सर्विस को क्रैश कर सकता है।
चेतावनी उपयोगी हो सकती है, पर डेवलपर को जाँचना पड़ता है कि वह इनपुट प्रभावित कोड तक सच में पहुँच सकता है या नहीं। हो सकता है एप्लिकेशन उसे पहले ही रोक देता हो, या टूल ने किसी पुरानी जाँच को गलत समझा हो।
अगर समस्या असली है, तो टीम को तय करना होता है कि वह कितनी गंभीर है। जो विफलता सिर्फ़ टेस्ट एनवायरनमेंट में होती है, वह उस कमज़ोरी से अलग है जिसका हमलावर दूर से फ़ायदा उठा सकता है।
इसके बाद ही डेवलपर तय कर सकते हैं कि सही सुधार क्या हो।
फ़िक्स को टेस्ट करना पड़ता है, और सुधारा हुआ सॉफ़्टवेयर रिलीज़ या अपडेट के ज़रिए यूज़र्स तक पहुँचना चाहिए।
AI कई चरणों में मदद कर सकता है। वह टेस्ट सुझा सकता है, कोड समझा सकता है और बदलाव प्रस्तावित कर सकता है। फिर भी नतीजों को जाँचने की ज़िम्मेदारी टीम की ही रहती है।
सॉफ़्टवेयर टीमें जब AI टूल का मूल्यांकन करती हैं, तो यह फ़र्क मायने रखता है।
कोई रिपोर्ट कि टूल ने सौ संभावित खामियाँ खोजीं, सॉफ़्टवेयर की गुणवत्ता में असल सुधार के बारे में बहुत कम बताती है। टीम को यह भी जानना होता है कि कितनी खोजें असली थीं, वे कितनी गंभीर थीं और क्या उन्हें हल किया गया।
curl और PostgreSQL के बीच यही व्यावहारिक संबंध है।
curl पर आने वाली रिपोर्टों की संख्या और गुणवत्ता का दबाव था। PostgreSQL के सामने सॉफ़्टवेयर की तैयारी को लेकर कठिन फ़ैसले थे, क्योंकि रिव्यू और फ़िक्स देर से हुए।
दोनों अनुभव किसी खोज के आसपास के काम को दिखाई देने लायक बनाते हैं।
डेवलपमेंट टीमों को क्या बदलना चाहिए
यही समस्या किसी ऐसी कंपनी में भी दिख सकती है जो ऑटोमेटेड सुरक्षा स्कैनर, AI कोड-रिव्यू टूल या सॉफ़्टवेयर टेस्टिंग प्लेटफ़ॉर्म इस्तेमाल करती है।
किसी टीम को सैकड़ों चेतावनियाँ मिल सकती हैं और यह पता न हो कि किन पर ध्यान देना है। अगर डेवलपर अपना ज़्यादातर समय गलत रिपोर्टों को खारिज करने में लगाते हैं, तो रिपोर्टिंग प्रक्रिया को सुधारने की ज़रूरत है।
GitHub का तरीका एक उपयोगी शुरुआती बिंदु देता है। किसी खोज की जाँच करने के लिए पर्याप्त सबूत माँगिए, जिनमें प्रभावित व्यवहार की साफ़ व्याख्या और, जहाँ व्यावहारिक हो, दोहराया जा सकने वाला उदाहरण शामिल हो।
लेकिन टीमों को यह भी देखना चाहिए कि समस्या पुष्ट होने के बाद क्या होता है।
अगर वैध खोजें इसलिए खुली पड़ी रहती हैं कि डेवलपर दूसरे कामों में व्यस्त हैं, तो मुद्दा अब रिपोर्ट की गुणवत्ता का नहीं रहता। संगठन को तय करना होगा कि इंजीनियरिंग का समय कैसे बाँटा जाए।
अगर फ़िक्स पूरे हो जाते हैं पर टेस्टिंग या रिलीज़ की मंज़ूरी का इंतज़ार करते हैं, तो उस चरण पर ध्यान देना होगा।
एक उपयोगी अभ्यास यह है कि हाल की खोजों के एक छोटे नमूने को सबमिशन से समाधान तक ट्रैक किया जाए। दर्ज कीजिए कि हर एक को वैलिडेट करने, ठीक करने, टेस्ट करने और रिलीज़ करने में कितना समय लगा।
| चरण | कितना समय लगा | काम किसने किया | किसका इंतज़ार रहा |
|---|---|---|---|
| वैलिडेट | भरें | भरें | भरें |
| फ़िक्स | भरें | भरें | भरें |
| टेस्ट | भरें | भरें | भरें |
| रिलीज़ | भरें | भरें | भरें |
TechiesJournal की वर्कशीट, डेटा नहीं। हाल की खोजों के एक छोटे नमूने की हर खोज के लिए इसकी कॉपी बनाइए।
नतीजे दिखा सकते हैं कि टीम को रिपोर्ट स्वीकार करने से पहले बेहतर ऑटोमेटेड जाँच चाहिए। वे यह उजागर कर सकते हैं कि रिव्यू का ज़्यादातर बोझ कुछ अनुभवी इंजीनियर उठा रहे हैं। या वे दिखा सकते हैं कि अहम फ़िक्स प्रोडक्शन तक पहुँचने में बहुत देर लगा रहे हैं।
ये फ़ैसले टीम के अपने सबूतों के आधार पर लिए जा सकते हैं, यह मान लेने के बजाय कि कोई और AI टूल समस्या सुलझा देगा।
मकसद सुरक्षा कमज़ोरियों की खोज को धीमा करना नहीं है। मकसद यह पक्का करना है कि संगठन अपनी खोजों पर कार्रवाई कर सके।
तेज़ खोज बेहतर सॉफ़्टवेयर का सिर्फ़ एक हिस्सा है
AI की मदद से होने वाला विश्लेषण ज़्यादा कोड जाँचना और ऐसी समस्याएँ उजागर करना संभव बना रहा है जो पहले छिपी रह सकती थीं।
यह उपयोगी प्रगति है।
curl का अनुभव दिखाता है कि आने वाली खोजों की गुणवत्ता क्यों मायने रखती है और वैध रिपोर्ट बढ़ने पर क्या होता है। PostgreSQL 19 दिखाता है कि रिव्यू का समय, बदलाव की जटिलता और अनुभवी डेवलपरों की उपलब्धता क्यों अहम बने रहते हैं।
सॉफ़्टवेयर टीमों के लिए सबक व्यावहारिक है। यह मापिए कि खोजों के आने के बाद उनका क्या होता है, सिर्फ़ यह नहीं कि टूल कितनी खोजते हैं।
AI की मदद से बग पहचानने का मूल्य भरोसेमंद खोजों को ऐसे भरोसेमंद फ़िक्स में बदलने से आता है जो यूज़र्स तक पहुँचें।
संदर्भ और आगे पढ़ने के लिए
curl और सुरक्षा कमज़ोरी रिपोर्टिंग
- Daniel Stenberg, The end of the curl bug-bounty, 26 जनवरी 2026। पुष्ट रिपोर्टों में गिरावट, प्रोग्राम का इतिहास और 31 जनवरी को बंद होना।
- Daniel Stenberg, High-Quality Chaos, 22 अप्रैल 2026। रिपोर्ट की गुणवत्ता में बाद का सुधार और संख्या में बढ़ोतरी।
- GitHub, Raising the bar for its bug bounty programme, 15 मई 2026। AI की मदद से बनी सत्यापित सुरक्षा रिपोर्टों से अपेक्षाएँ।
PostgreSQL 19 और कोड रिव्यू
- Peter Eisentraut, The reverts will continue until morale improves, 9 अक्टूबर 2026। रिलीज़ के दबाव, आर्किटेक्चर, सुरक्षा के काम और LLM की मदद से हुए कोड रिव्यू का डेवलपर का बयान।
- Tomas Vondra, Are we reverting patches because of bugs found by AI?। बारह रिवर्ट किए गए बदलावों की एक-एक करके जाँच।
- Christophe Pettus, The patch is coming from inside the house। रिव्यू के समय का विश्लेषण।
- PostgreSQL 19 Release Candidate 1 announcement, 15 अक्टूबर 2026। आधिकारिक संशोधित रिलीज़ शेड्यूल।
- Snowflake Engineering, PostgreSQL 19 release delay and feature reverts, 16 सितंबर 2026। AI की मदद से हुई टेस्टिंग और रिलीज़ के फ़ैसलों का एक अतिरिक्त विवरण।
TechiesJournal पर संबंधित पाठ
- Node.js Brotli Vulnerability: How Applications Become Exposed and What Developers Should Check। बताता है कि टीमें कैसे तय करती हैं कि रिपोर्ट की गई सुरक्षा कमज़ोरी उनके एप्लिकेशन पर असर डालती है या नहीं।
स्रोतों की समीक्षा की तारीख: 30 अक्टूबर 2026। सबके लिए उपलब्ध होने से पहले PostgreSQL का रिलीज़ शेड्यूल बदल सकता है।