7.2 कर्नेल के लिए विकास आँकड़े
Linux kernel 7.2 विकास आँकड़े 2026 के मध्य से प्रति रिलीज़ ठीक किए गए बगों में तेज़ वृद्धि दिखाते हैं, जो AI coding tools और agents के अधिक उपयोग के साथ मेल खाती है। टिप्पणीकार इस पर बहस करते हैं कि क्या यह वास्तविक गुणवत्ता लाभ दर्शाता है या सिर्फ मशीन-जनित patches की बाढ़ है जो काम का बोझ maintainers पर डालती है और चतुर workarounds के पीछे नए बग छिपा सकती है। जहाँ कई लोग AI को एक व्यावहारिक उत्पादकता बढ़ाने वाला मानते हैं—जो kernel community में औज़ार अपनाने के पिछले उदाहरणों की तरह है—वहीं अन्य लोग “slop” code, implementations की कमजोर मानवीय समझ, और दीर्घकालिक reliability मापने के कठोर तरीकों की कमी को लेकर चिंतित हैं.
संपादकीय फ्रेमिंग और कर्नेल आँकड़े
- मूल HN शीर्षक को संपादकीय रूप से “प्रति रिलीज़ ठीक किए गए बग” पर ज़ोर देने के लिए बदला गया था; मॉडरेटरों ने इसे वापस बदल दिया और भेजने वालों को याद दिलाया कि वे शीर्षकों के ज़रिए लेखों को नए ढंग से न पेश करें।
- कुछ टिप्पणीकार रिपोर्ट किए गए प्रति रिलीज़ ठीक किए गए बगों की वृद्धि को LLM-चालित योगदानों के प्रमाण के रूप में देखते हैं; अन्य ज़ोर देते हैं कि लेख स्वयं अधिक सतर्क है, और वर्तमान LLM उपयोग को कर्नेल समुदाय और प्रक्रियाओं पर एक “विशाल प्रयोग” कहता है।
LLMs: औज़ार बनाम “slop”
- समर्थकों का तर्क है कि LLMs ऑनबोर्डिंग की बाधाओं को काफ़ी कम कर देते हैं, खासकर कर्नेल विकास या ऐसे ही प्रोजेक्ट्स में जटिल प्रक्रियाओं और boilerplate के लिए।
- वे वास्तविक उत्पादकता लाभ बताते हैं: एजेंट बग दोहरा सकते हैं, डिबग कर सकते हैं, और सुधार सुझा सकते हैं, जबकि मनुष्य मुख्यतः समीक्षा करते हैं।
- आलोचक निम्न-गुणवत्ता वाले (“slop”) पैच और PRs की बाढ़ की ओर ध्यान दिलाते हैं, और कहते हैं कि यह खुला योगदान हतोत्साहित करती है और maintainers पर बोझ डालती है।
क्षमता, समझ, और औज़ारों का उपयोग
- एक पक्ष का दावा है कि LLMs का उपयोग competence से असंबद्ध है; महत्वपूर्ण यह है कि योगदानकर्ता अपने द्वारा सबमिट किए गए बदलावों को समझते हैं या नहीं।
- अन्य लोग तर्क देते हैं कि व्यवहार में LLM पर भारी निर्भरता अक्सर सतही समझ और shortcut लेने से जुड़ी होती है।
- एक बहस में एक उपमा दी गई है कि LLMs पर प्रतिबंध लगाना ऐसा होगा जैसे समझ साबित करने के लिए सभी कोड assembly में लिखना; कुछ लोग इसे त्रुटिपूर्ण मानते हैं क्योंकि compilers deterministic होते हैं, LLMs नहीं।
- थ्रेड इस बात पर बहस करता है कि क्या किसी उच्च-स्तरीय भाषा (जैसे C) को समझना मशीन व्यवहार के विश्वसनीय mental models का संकेत है; undefined behavior और जटिलता को counterexamples के रूप में उद्धृत किया गया है।
सहीपन, बग, और सत्यापन
- संशयवादियों का तर्क है कि LLM कोड “probable” होता है, भरोसेमंद रूप से सही नहीं, और सूक्ष्म बग (जैसे data races) ला सकता है, यहाँ तक कि बहुत अनुभवी डेवलपर्स द्वारा किए गए LLM-सहायित पैचों में भी।
- अन्य लोग जवाब देते हैं कि मनुष्य भी ऐसी गलतियाँ करते हैं; code review और testing ने कम-से-कम एक उजागर race condition को रिलीज़ से पहले पकड़ लिया।
- समर्थक सुझाव देते हैं कि मज़बूत automated tests और यहाँ तक कि formal methods भी humans और LLMs दोनों से आने वाले regressions को सीमित कर सकते हैं, हालांकि आलोचक ज़ोर देते हैं कि tests sample-based होते हैं और पूरे input space को कवर नहीं करते।
डाउनस्ट्रीम प्रभाव और ecosystem व्यवहार
- कुछ maintainers कम user-filed bug reports देखते हैं, और संदेह करते हैं कि agents समस्याओं की रिपोर्ट करने के बजाय चुपचाप उनके आसपास काम कर रहे हैं।
- LLMs को नाज़ुक या “insane” workarounds उत्पन्न करते हुए देखा जाता है (जैसे subprocess hacks और log parsing), जो API design और semantic versioning guarantees को कमजोर कर सकते हैं।