क्या Claude ने rsync में बग बढ़ाए?

 (alexispurslane.github.io)
2 पॉइंट द्वारा GN⁺ 2026-06-06 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude-सहायित रिलीज़ केवल rsync v3.4.2 और v3.4.3 दो ही हैं, और severity-weighted bug/10 commits के आधार पर यह दिखाने वाला कोई प्रमाण नहीं है कि इनमें पिछली रिलीज़ों की तुलना में असामान्य रूप से अधिक बग थे
  • sev/10c मुख्य मेट्रिक है, जिसमें बग severity स्कोर को 0~1 पर normalize करके हर रिलीज़ के लिए जोड़ा जाता है, फिर commits की संख्या से भाग देकर प्रति 10 commits के मान में बदला जाता है
  • v3.4.2 में 50 commits·9 Claude commits·0 bugs·0.00 sev/10c था, और v3.4.3 में 34 commits·28 Claude commits·17 bugs·3.29 sev/10c था; दोनों IQR के दो सिरों के आसपास आते हैं, और इनमें से कोई भी outlier नहीं है
  • Exact permutation test का p-value 46% था, Fisher's exact test का p-value 74% था, और odds ratio 1.06 था; यानी Claude रिलीज़ें किसी भी random 2 releases से बदतर हैं या median से ऊपर होने की अधिक संभावना रखती हैं, इसका लगभग कोई संकेत नहीं मिलता
  • v3.4.1 Claude लागू होने से पहले की रिलीज़ थी, फिर भी 59 bugs·9 commits·39.39 sev/10c के साथ पूरे डेटा में सबसे खराब मान उसी का था; rsync विवाद का केंद्र यह है कि historical distribution के बिना एक single regression को Claude से जोड़ दिया गया

पृष्ठभूमि और सवाल

  • मई 2026 के अंत में rsync विवाद एक Mastodon पोस्ट से शुरू हुआ, जिसमें v3.4.3 regression और उस रिलीज़ के Claude commits को जोड़ा गया; बाद में यह Hacker News और GitHub issue "Please Do Not Vibe Fuck Up This Software" तक फैल गया, और उस issue में 300 से अधिक टिप्पणियाँ जमा हुईं
  • बार-बार दोहराया गया मुख्य दावा यह था कि Claude-सहायित development ने पहले से स्थिर टूल में बग डाल दिए, और डेटा-आधारित सवाल यह था कि क्या Claude-सहायित रिलीज़ें ऐतिहासिक रिलीज़ों की तुलना में असामान्य रूप से अधिक buggy थीं
  • Lobsters पर यह सुझाव आया कि रिलीज़-दर-रिलीज़ regressions की time chart देखी जाए, और विश्लेषण का फोकस एक ही सवाल रहा: “क्या Claude-सहायित रिलीज़ें असामान्य रूप से अधिक buggy हैं?”

डेटा का दायरा और reproducibility

  • डेटा RsyncProject/rsync की v2.4.6 से v3.4.3 तक की उन 36 रिलीज़ों का है जिनके लिए bug data उपलब्ध है; Claude commits वाली रिलीज़ें केवल v3.4.2 और v3.4.3 हैं
  • मेट्रिक, methodology और data source का चयन इंसान ने सीधे किया, और इसमें statistics में master's degree रखने वाली जीवनसाथी की सलाह शामिल थी
  • डेटा संग्रह, DuckDB लोडिंग, view creation और statistical analysis scripts GLM 5.1 ने लिखे, लेकिन सभी numbers, statistics, cards और graphs statistical analysis चलाने वाले Python script ने automatic templates के जरिए डाले
  • reproducibility के लिए alexispurslane/rsync-analysis repository पूरी pipeline को शुरू से अंत तक चला सकती है

मेट्रिक और bug attribution का तरीका

  • मुख्य मेट्रिक severity-weighted bugs per 10 commits, यानी sev/10c है, और इसका formula है sev/10c = (Σ severity/100 ÷ total_commits) × 10
  • commits को base branch में committer date के क्रम से sort किया गया, और हर release range को पिछले tag से उस tag तक के commits के रूप में लिया गया; pre·rc tags को boundaries से बाहर रखकर final release में absorb किया गया
  • bug sources तीन हैं: GitHub issues, rsync Bugzilla, और rsync mailing list; GitHub issues और mailing list bugs को report होने के ठीक पहले deploy हुई नवीनतम release से जोड़ा गया
  • Bugzilla items में “Version” field उस release को स्पष्ट करती है जिसमें bug report हुआ था, इसलिए उन्हें उसी release से जोड़ा गया
  • release-level analysis इसलिए चुना गया क्योंकि आलोचना का स्वरूप ही यह था कि “Claude commits वाली पूरी release ज्यादा buggy हो गई,” और अधिकतर bugs में यह स्पष्ट नहीं होता कि वे ठीक किस commit से आए

severity आकलन का तरीका

  • सभी bug reports को Qwen 3 35B ने 0~100 severity score दिया, और prompt में उसे वास्तविक user impact के नज़रिए से senior reliability engineer की भूमिका दी गई
  • 90~100 स्कोर silent data corruption·data loss·remote code execution या unauthorized access security vulnerabilities के लिए, 70~89 crashes·hangs·backup failures·build failures के लिए, और 50~69 workaround योग्य functional regressions के लिए रखा गया
  • Bugzilla और mailing list में body के बिना केवल titles थे, इसलिए model ने सिर्फ title देखकर मूल्यांकन किया; और जानकारी कम होने पर उसे 40~60 के middle range की ओर झुकने के लिए कहा गया
  • output के लिए structured output के JSON schema का उपयोग हुआ, जिसमें केवल integer severity स्वीकार की गई, और temperature 0 पर फिक्स रखा गया ताकि एक ही input पर एक ही score आए
  • feature requests, spam, AI से जुड़ी non-technical आपत्तियाँ, और खाली submissions जैसे 0-score issues को base bug count से बाहर रखा गया

Claude रिलीज़ों के statistical results

  • v3.4.2 में 50 commits में से 9 Claude commits थे, वास्तविक bugs 0 थे, sev/10c 0.00 था, और यह 0 percentile release थी
  • v3.4.3 में 34 commits में से 28 Claude commits थे, bugs 17 थे, sev/10c 3.29 था, और यह 77 percentile release थी
  • ऐतिहासिक IQR 0.29~2.59 sev/10c था; v3.4.2 IQR के ठीक नीचे और v3.4.3 IQR के ठीक ऊपर थी, यानी दोनों रिलीज़ें मध्य वितरण के दो उल्टे किनारों को घेरे हुए हैं
  • Exact permutation test में 595 संभव 2-release combinations में से 272 का mean Claude group mean 1.65 sev/10c या उससे अधिक निकला, इसलिए p-value 46% आई
  • Fisher's exact test ने median 0.74 sev/10c के आधार पर देखा कि क्या Claude रिलीज़ें median से ऊपर अधिक बार आती हैं, और इसका परिणाम p-value 74% तथा odds ratio 1.06 रहा

commits की संख्या और बदलाव का आकार

  • Claude रिलीज़ों में औसतन 42 commits थे, जबकि बिना Claude वाली रिलीज़ों में औसतन 185 commits थे; किसी random 2 releases के पास इतने या इससे अधिक commits होने की संभावना 88% थी
  • GitHub compare API के अनुसार Claude रिलीज़ों में औसतन 3,756 lines बदलीं, जबकि बिना Claude वाली रिलीज़ों में औसतन 696 lines; किसी random 2 releases में इतने या इससे अधिक changed lines होने की संभावना 5% थी
  • severity-weighted bug count Claude रिलीज़ों में औसतन 5.6 था, जबकि बिना Claude वाली रिलीज़ों में औसतन 14.9; किसी random 2 releases में इतने या इससे अधिक severity-weighted bugs होने की संभावना 77% थी
  • निष्कर्ष यह है कि Claude रिलीज़ों में changed lines बहुत अधिक थीं, लेकिन commits की संख्या या severity-weighted bug count अधिक नहीं था

version regime और पूर्व outliers

  • v2.x रिलीज़ों का औसत 1.11 sev/10c था, जबकि v3.x रिलीज़ों का औसत 4.23 sev/10c था; यानी v3.x में bug rate अधिक दिखता है
  • केवल v3.x की तुलना करने पर भी Claude रिलीज़ें मध्य स्तर पर या उससे बेहतर आती हैं; Claude को outlier जैसा दिखाने के लिए अपेक्षाकृत शांत पुराने दौर से तुलना करनी पड़ेगी और Claude से पहले हुए बदलावों का दोष Claude पर डालना होगा
  • Wald–Wolfowitz runs test में Claude के बिना 35 रिलीज़ों पर observed runs 13, random expectation 18.5, z=-1.88, p=0.060 मिला; 0.05 threshold पर यह randomness को खारिज करने जितना मजबूत नहीं है
  • v3.4.1 Claude से पहले की रिलीज़ थी, फिर भी 59 bugs·9 commits·39.39 sev/10c के साथ इसने पूरे dataset में सबसे ऊँचा bug rate दर्ज किया
  • v3.4.1, v3.4.0 के अगले दिन आई एक hotfix release थी, और इसने सभी दूसरी रिलीज़ों को कम-से-कम एक digit के अंतर से पीछे छोड़ते हुए सबसे ऊँचा bug rate दिखाया, लेकिन उस समय AI को दोष देने का कोई आधार नहीं था

व्याख्या और सीमाएँ

  • डेटा के अनुरूप व्याख्या यह है कि “अभी की दो Claude रिलीज़ें सांख्यिकीय रूप से ऐतिहासिक रिलीज़ों से अलग नहीं दिखतीं”
  • v3.4.3 का 3.29 sev/10c और 77 percentile होना इसे ऊँचा तो बनाता है, लेकिन यह extreme value नहीं है; इससे ऊँचे score वाली 8 ऐतिहासिक रिलीज़ें मौजूद हैं
  • “Claude ने स्पष्ट रूप से चीज़ों को बदतर बनाया” यह दावा release distribution, permutation test, या Fisher test—किसी से भी समर्थित नहीं होता
  • दूसरी ओर, “Claude commits आम तौर पर आगे भी चीज़ों को बदतर नहीं बनाएँगे” यह निष्कर्ष भी इस डेटा से नहीं निकलता; फिलहाल इतना ही कहा जा सकता है कि ये दो रिलीज़ें सामान्य दायरे में हैं
  • इस मेट्रिक की सीमा यह है कि यह commit complexity या security work intensity को control नहीं कर पाता, इसलिए यह एक blunt tool है

चर्चा किए गए confounding factors

  • Hacker News के एक user का मानना था कि CVE response security fixes ने 2007 से code में मौजूद coding errors को उजागर किया
  • Lobsters के एक user ने causal chain दी: “LLM → known security issues में वृद्धि → सामान्य से अधिक बदलाव की ज़रूरत → सामान्य से अधिक regressions”
  • Andrew Tridgell ने बताया कि AI-generated CVE reports की बाढ़ ने rsync के attack surface में तेज़ और व्यापक बदलाव की माँग पैदा की
  • इन confounding factors को शामिल करने पर समस्या Claude से ज़्यादा बढ़े हुए security work और उससे आई higher change volume के करीब लगती है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2026-06-06
Hacker News की टिप्पणियाँ

  • कमिट देखते हुए मूल कमिट और उसे revert करने वाला कमिट मिला: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
    जिन paths में malloc होना चाहिए था, उन्हें भी calloc में बदल दिया गया, मानो सभी allocation के लिए calloc सख्त super-set compatible हो। बड़े allocation या recursive allocation में इसकी लागत काफ़ी बढ़ सकती है। Claude से लिखे गए code में ऐसी चीज़ों का review से निकल जाना एक अच्छा उदाहरण लगता है। revert यहाँ है: https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., और revert का explanation भी आधा पढ़ो तो LLM वाला अंदाज़ दिखता है। मूल पोस्ट लिखने वाले की भावना समझ में आती है

    • कमिटों की संख्या भी अपने आप में संदिग्ध है। पिछले दो महीनों में rsync में गए कमिटों की संख्या उससे पहले के 2 साल के लगभग बराबर है, और उनमें ज़्यादातर Claude से लिखे गए कमिट हैं। ऐसे बदलाव भी अंदर चले गए, इससे लगता है कि AI इस्तेमाल को लेकर उत्साह में लोग धीरे-धीरे लापरवाह होते जा रहे हैं
    • “Claude से लिखा गया” कहना सही नहीं है। revert कमिट https://github.com/RsyncProject/rsync/issues/959 का संदर्भ देता है, और उस issue में लेखक खुद कहता है, “memory को 0 करने वाला बदलाव मेरा idea था और मेरा ही change था”
      security report में array के अंत से आगे के element के उपयोग की बात आई थी, और उसका मानना था कि allocation को 0-initialize कर देने से अगर भविष्य में ऐसा मिलता-जुलता bug फिर आए, तो valid pointer की जगह null pointer dereference पर रुकने की संभावना ज़्यादा होगी। Claude का उपयोग सिर्फ commit bundle को organize करने के लिए हुआ था, और थोड़ा भी edit हो तो co-authored tag लग जाता है, इसलिए इसका मतलब यह नहीं कि बदलाव Claude ने लिखा। वह साफ़ कहता है कि असली code उसने खुद लिखा
    • मैं यह मानकर नहीं चलूँगा कि वह फ़ैसला Claude ने लिया था। यह कोई बड़ा कमिट था जिसमें चुपके से कोई side change घुस गया हो, ऐसा भी नहीं; commit message की शुरुआत ही “नई allocate की गई memory को पूरी तरह 0-initialize करें” से होती है और कमिट सचमुच वही करता है। शुरू में prompt क्या रहा होगा, इसकी कल्पना ही समझ नहीं आती
      यह पूरी तरह संभव है कि किसी इंसान ने पहले इसे सुधार समझा हो और फिर RSS regression देखकर दोबारा सोचा हो। और यह भी कोई प्राकृतिक नियम नहीं कि यह बदलाव RSS ज़रूर बढ़ाए। calloc संभव है कि OS से अभी-अभी मिले नए memory mapping के पहले से 0 होने की जानकारी के आधार पर special-case करता हो। अगर यहाँ AI को दोष देना है, तो उसका मतलब ज़्यादा से ज़्यादा यह होगा कि AI ने vulnerability reports में उछाल पैदा किया, उससे urgent fixes की बाढ़ आई, और urgent fixes कभी-कभी दूसरी समस्याएँ भी बना देते हैं
    • क्या ज़माना आ गया है, AI के साथ Linux overcommit भी जुड़ गया। मेरी निजी राय में 10.8GB आजकल कोई बहुत बड़ी बात नहीं, और sprintf buffer उससे भी बड़ा हो सकता है। अगर नहीं है, तो होना चाहिए, और अगर नहीं हो सकता तो snprintf इस्तेमाल करना शुरू करना चाहिए

  • टिप्पणी करने से पहले rsync लेखक द्वारा लिंक किया गया यह लेख पढ़ने की सलाह दूँगा: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
    खुलासा कर दूँ, कई सालों से Tridge से संपर्क नहीं हुआ, लेकिन वह लंबे समय तक सहकर्मी और mentor रहे हैं। किसी मुहिम में कूदने से पहले उनका नज़रिया देख लेना क़ीमती है

    • यह सबसे ऊपर वाला comment होना चाहिए। यह काफ़ी दुखद है कि उन्हें ऐसा लेख तक लिखना पड़ा। जिन लोगों को उनकी बिल तक नहीं चुकानी, वे भी बहुत ज़्यादा फ़ैसले सुना रहे हैं
    • “मैंने सोचा कि नए test suite की core structure को master में पहले सार्वजनिक रूप से बनाना बेहतर होगा” वाला हिस्सा पूरी तरह समझ में नहीं आता। अगर सिर्फ tests update किए होते या सिर्फ master पर push किया होता, तो लोग इतने नाराज़ नहीं होते
      लेकिन उन्होंने release branch पर भी breaking changes push कर दिए। सालों से चल रहे workflow को तोड़ना लोगों को नाराज़ करने का सबसे पक्का तरीका है, और ऊपर से कमिट में “Claude” दिख जाए तो आग में घी डालने जैसा है
    • उनकी प्रतिक्रिया मुझे सच में बहुत अच्छी तरह लिखी हुई लगी

  • मैं इस बहस में सीधे तौर पर निवेशित नहीं हूँ, लेकिन कुछ बातें संदिग्ध लगती हैं। सबसे ज़्यादा bugs जिस release से जोड़े गए, वह जनवरी वाला release है जो Claude co-authored commits पहली बार आने वाले release से ठीक पहले था; इसलिए यह सवाल उठता है कि क्या LLM-लिखे commits बिना attribution के इस release में शामिल हुए हो सकते हैं।
    release attribution methodology भी खास अच्छी नहीं है। minor version update में आए bugs अक्सर उस minor version के उस patch release को attributed हो जाते हैं जो सबसे लंबे समय तक रहा हो। यह मानना मुश्किल है कि 3.4.1 ने वास्तव में बहुत सारे bugs introduce किए; संभव है कि 3.4.0 के अगले ही दिन आने की वजह से उस release में पैदा हुए bugs, 3.4.1 पर दर्ज हो गए हों। साथ ही, हाल के releases को bug report होने का समय कम मिला है, इसलिए यह bias भी हो सकता है कि वे कम buggy दिखें

    • सहमत। लेख में यह कहना कि “rsync के इतिहास का सबसे खराब release, Claude आने से पहले था और किसी ने ध्यान नहीं दिया” लेखक को निष्पक्ष नहीं, बल्कि चमकदार statistical terms में अपनी राय लपेटने वाला दिखाता है।
      “चौंका देने जितना स्पष्ट”? बस एक graph बना दीजिए। और v3.4.1 की तारीख 2025-01-16 है, इसलिए तकनीकी रूप से वह AI-assisted coding era के भीतर ही आता है, बस attribution standard practice बनने से पहले
    • releases काफ़ी कम आते हैं, यह देखते हुए मैंने भी उसी हिस्से को देखना शुरू किया। un-attributed LLM-written commits वाली समस्या से बचना है तो analysis में v3.3.0 के पहले और बाद की bug severity comparison शामिल होनी चाहिए। तारीख 2024-04-06 है
    • LLM को कई तरीकों से इस्तेमाल किया जा सकता है। एक छोर पर इंसान बहुत सीधे शामिल रहता है और सिर्फ local changes कराता है, और दूसरे छोर पर सब कुछ उसे सौंप देता है।
      मैंने बहुत-सा ऐसा code देखा है जो LLM ने generate किया, लेकिन commit message में co-author नहीं जोड़ा गया। आम तौर पर ऐसा tag तभी लगता है जब codebase के साथ interface पूरी तरह Claude/Codex जैसे tools के ज़रिए हो, और ऐसे commits अक्सर बहुत verbose होते हैं लेकिन बदलाव क्यों किए गए यह लगभग नहीं बताते, सिर्फ code changes का summary देते हैं। दूसरी ओर, मैंने ऐसे developers भी देखे हैं जो Claude को सिर्फ tool की तरह इस्तेमाल करते हैं। वे VSCode और Claude terminal के बीच आते-जाते हैं, सही code को खुद verify करते हैं, और सिर्फ plumbing work Claude को देते हैं। हो सकता है लेखक ने भी छोटे स्तर से शुरू किया हो और समय के साथ उपयोग बढ़ा हो
    • पहला और दूसरा point एक-दूसरे के विरोधाभासी लगते हैं। अगर 3.4.1 के सारे bugs को 3.4.0 से attributed होना चाहिए, तो un-attributed LLM commits के project में आने का समय और पहले खिसक जाता है, और ऐसा होने पर यह hypothesis और भी बेतुकी लगती है।
      बड़ी समस्या यह है कि इस hypothesis के समर्थन में ज़रा भी evidence नहीं है कि पहले के releases में LLM commits चुपके से आए और इसी वजह से bug rate बढ़ा। जब तक यह पहले से मान न लिया जाए कि bugs की संख्या ज़्यादा होने का मतलब AI intervention है, तब तक इसका कोई आधार नहीं; और वह circular reasoning होगा। तीसरा point ठीक है। bug ढूँढने में आम तौर पर कितना समय लगता है और हर version release cycle में कहाँ बैठता है, इसका analysis मैंने किया है; चाहें तो पोस्ट कर सकता हूँ
    • सबसे खुली और चौंकाने वाली गलती से शुरू करें तो Claude वाला stats कुल 2 data points पर आधारित है

  • यहाँ एक महत्वपूर्ण meta-level irony है। मूल लेख AI के उपयोग का बचाव करता है, लेकिन data का analysis करने और नतीजे पेश करने में भी साफ़ तौर पर AI का इस्तेमाल करता दिखता है।
    उस प्रक्रिया में लेखक ने statistics का इस्तेमाल उन तरीकों से किया जिन्हें वह खुद ठीक से समझता नहीं था, और कई गलत निष्कर्षों तक पहुँचा। संबंधित चर्चा यहाँ देखी जा सकती है: https://news.ycombinator.com/item?id=48417626। संक्षेप में, इस अध्ययन में पर्याप्त statistical power नहीं है, और यह बिना उचित आधार के “कोई अंतर नहीं है” जैसा दावा कर रहा है। आखिरकार, LLM से data interpret करवाते हुए लेखक ने वही गलती कर दी जिसकी जाँच यह अध्ययन करना चाहता था: आत्मविश्वास से झूठी बात कह देना

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

  • मुझे लगता है कि इस मामले पर गुस्सा लोग अगर rsync maintainer पर दबाव डालेंगे तो नतीजा सिर्फ यह होगा कि दूसरे लोग AI उपयोग को ज़िम्मेदारी से disclose करना बंद कर देंगे। विवाद से बचने के लिए वे commits में Claude attribution बंद कर देंगे

    • मुझे AI उपयोग disclosure की ज़्यादा परवाह नहीं है। अगर वह कोई ऐसा व्यक्ति नहीं है जिसे मैं सीधे जानता हूँ, तो मैं यह नहीं मानता कि इंसान द्वारा लिखा code, AI द्वारा लिखे code से अनिवार्य रूप से बेहतर होता है।
      वैसे भी commit और push किए गए code की ज़िम्मेदारी इंसान की ही होती है। यह कभी बदला नहीं। वह हाथ से लिखा गया हो, बिल्ली के keyboard पर चलने से बन गया हो, या AI ने बनाया हो, मुझे फ़र्क नहीं पड़ता। project का code quality कई वजहों से गिर सकता है, और सिर्फ इस बात पर अटक जाना कि code AI ने बनाया या नहीं, productive नहीं है। कोई AI की आलोचना के लिए बहाना ढूँढना चाहता है, और कोई AI का बचाव करना चाहता है, तो कर सकता है, लेकिन project code quality को परखने का यह सही तरीका नहीं है
    • विवाद से अलग भी, ऐसे tags बंद करना ही सही है। किसी trillion-dollar company को free advertising देने की कोई वजह नहीं। Generated-by जैसे trailers तब प्रासंगिक होते हैं जब आप किसी third-party project में contribute कर रहे हों, और तब उनका disclosure करना शिष्टाचार है
    • यह कुछ ऐसा लगता है: “अगर तुम किसी अनैतिक या immoral काम पर गुस्सा करोगे, तो मैं उससे भी ज़्यादा अनैतिक या immoral काम करूँगा!”
      LLM-generated code का attribution बंद करना धोखा है। क्योंकि इसका मतलब है यह कहना कि code आपने लिखा। और सच कहें तो यह LLM से code generate कराने के पूरे विचार से मेल भी खाता है। आखिरकार, यह अक्सर license और copyright notices हटाकर input को उगल देने जैसा ही होता है
    • पता नहीं यह बुरी बात है भी या नहीं। Anthropic marketing department के नज़रिए से शायद हाँ, लेकिन अगर agent developer toolbox का बस एक और tool है, तो attribution कुछ अटपटा लगता है। आखिर commit की ज़िम्मेदारी developer की ही है
    • यह तर्क हर बार आता है, लेकिन मनाने वाला नहीं है। यह सही है कि किसी समस्या को सार्वजनिक रूप से उठाने से उसे छिपाने की incentive बनती है, लेकिन उससे क्या निष्कर्ष निकाला जाए, यह समझ नहीं आता।
      AI बुरा है या नहीं, यह बहस थोड़ी देर के लिए अलग रख दें, तो उदाहरण के तौर पर tax evasion बुरा और unethical है, और दिखे तो उसे pointed out करना चाहिए। लेकिन सिर्फ इसलिए कि इससे उसे छिपाने की incentive बनती है, यह नतीजा नहीं निकलता कि हमें चुप रहना चाहिए और कुछ कहना ही नहीं चाहिए

  • Andrew ने rsync को बनाया और इतने समय तक maintain किया, इसके लिए मैं आभारी हूँ, लेकिन मैं अपने home network में machines के बीच file backups के लिए rsync पर बहुत निर्भर हूँ, इसलिए मैंने समय लगाकर Homebrew के rsync version को 3.4.1 पर pin करने का तरीका ढूँढा।
    उसके बाद के दो versions के bugs सच में डरावने हैं, और यह सब शुरू करने वाली मूल report भी वैसी ही है। उम्मीद से कहीं ज़्यादा जटिल निकली प्रक्रिया मैंने यहाँ लिखी है: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

  • यह लेख जवाबों से ज़्यादा सवाल छोड़ता है, इसलिए निष्कर्ष निकालना मुश्किल है। Claude कमिट से ठीक पहले का v3.4.1 सबसे ज़्यादा buggy क्यों था, और “किसी ने इसे नोटिस क्यों नहीं किया”, यह समझ नहीं आता। इसे बस human error कहकर टाल देना कुछ ज़्यादा ही अजीब लगता है
    और v3.4.2 में bugs 0 क्यों हैं, या bug score 0 क्यों है, यह भी सवाल है। ऐसे outliers जो दूसरे commits में दिखते नहीं, उन्हें aggregate statistics में मिलाकर “Claude bugs बनाता है?” स्कोर को नीचे जाने देना भी अजीब है। सच कहूँ तो समझ नहीं आता कि लेखक की analysis में यह red flag क्यों नहीं था। ऐसा लगता है कि advanced statistics चलाने के नाम पर आधा-अधूरा analysis को बहुत complex finished product की तरह पेश किया गया है

    • मुझे नहीं पता कि v3.4.1 को human error न मानने की वजह क्या है, उस पूर्वधारणा के अलावा कि ऐसा हो ही नहीं सकता
      v3.4.2 भी original metrics में feature requests और questions को फ़िल्टर करने से पहले 4 bugs था, और उससे पहले उससे भी ऊपर था, लेकिन overall analysis में इससे कोई बड़ा फ़र्क नहीं पड़ा। यह interquartile range के भीतर था, वह भी निचले हिस्से में। जब Claude releases सिर्फ़ दो ही हैं, तो एक outlier को सिर्फ़ इसलिए हटाना कि वह मज़ेदार या अजीब लगता है, मेरे हिसाब से ज़्यादा खराब और ज़्यादा मनमाना होगा

  • अगर बात यह है कि “commit complexity, security focus, और bug severity को control नहीं किया गया। यह one-line typo fix और CVE patch में फ़र्क नहीं करता, यानी एक blunt instrument है। लेकिन आलोचकों का ‘Claude हालात और बिगाड़ देता है’ वाला आरोप भी blunt instrument है, इसलिए blunt instrument से जवाब देना सबसे fair है”, तो इससे सहमत होना मुश्किल है
    यूज़र के नज़रिए से यह समझना ज़रूरी है कि bugs की प्रकृति क्या और खराब हुई है। भले ratio वही रहे, अगर महसूस होने वाली software quality गिर गई है, तो ख़ासकर project maintainer के लिए उसे बदतर ही माना जाएगा। मैं इस analysis को पूरी तरह नज़रअंदाज़ करने की बात नहीं कर रहा, लेकिन ऐसे सवालों का जवाब सिर्फ़ quantitative analysis से पूरी तरह देना मुश्किल है

    • फिर भी मुझे यह fair लगता है। अब तक मैंने किसी को code analyze करके यह कहते नहीं देखा कि किस severity के कितने regressions आए। लोग बस कहते हैं, “LLM की वजह से bugs बढ़ गए”
      इस analysis को चाहो तो ख़ुद verify कर सकते हो, और यह कहता है कि “LLM होने पर भी bug count काफ़ी average है।” उस दावे का इसने सीधे जवाब दिया है। अगर किसी को ज़्यादा nuanced analysis चाहिए, तो वह ख़ुद करके नतीजे share कर सकता है
    • जो दावा बिना सबूत के किया गया हो, उसे बिना सबूत के ख़ारिज भी किया जा सकता है। इस analysis में मूल दावे की तुलना में ज़्यादा evidence और ज़्यादा rigor है। मेरे लिए यह काफ़ी है। अगर कोई सच में मूल दावे को बेहतर evidence से support करे, तो अच्छा होगा, मैं देखना चाहूँगा। तब तक मैं इस मुद्दे की चिंता नहीं करूँगा
    • proof का burden दावा करने वाले पर नहीं होता क्या?

  • मैं 20 साल से ज़्यादा समय से coding कर रहा हूँ, coding से प्यार करता हूँ, और शायद आगे भी करता रहूँगा। कुछ महीने पहले तक मैं AI skeptic था, लेकिन Claude और Codex ने मेरे development के तरीके और speed को ऐसे बदल दिया है जिसकी मैंने कल्पना भी नहीं की थी
    नतीजतन मैं ज़्यादा code बना रहा हूँ और ज़्यादा bugs भी ढूँढ रहा हूँ। इसलिए जब HN comments में AI से बनी चीज़ों के लिए इतनी extreme नफ़रत देखता हूँ तो काफ़ी हैरानी होती है। सिर्फ़ इसलिए कि AI ने मदद की या सब कुछ generate किया, कोई project अचानक vibe coding नहीं बन जाता, और न ही यह शब्द LLM users के लिए किसी insult की तरह इस्तेमाल होना चाहिए। 90s के मध्य के बाद जब overseas outsourcing बढ़ी थी, तब “Indian developers” के लिए जो तिरस्कारपूर्ण भाषा इस्तेमाल होती थी, उसकी बहुत याद आती है। अब 2020s के मध्य में वैसी ही बातें AI के लिए कही जा रही हैं। समझ नहीं आता। इतना तय है कि विरोधियों से बेपरवाह होकर भी AI-generated code आगे और बढ़ेगा

    • मैं भी 3 साल पहले तक AI को लेकर कुछ ऐसा ही skeptic था। जब GPT-4 state of the art था, तब मुझे लगता था कि context size limits की वजह से यह जल्दी plateau कर जाएगा। वह दौर याद है जब 32K context इस्तेमाल करने के लिए बेहिसाब पैसे देने पड़ते थे
      पिछले साल पहली बार मैंने AI agent को किसी non-trivial bug को संतोषजनक ढंग से debug और fix करते देखा। तब भी यह साफ़ था कि बड़े कामों में यह issue tracker को पूरा का पूरा सौंप देने के स्तर पर नहीं है। अभी पिछले कुछ महीनों से मैं Codex के साथ एक non-trivial project पर काम कर रहा हूँ। library constraints की वजह से prototype C++ में बनाया, शुरुआती version Haskell में लिखा, और हाल में mobile memory usage कम करने के लिए उसे Rust में port किया। यह flawless tool नहीं है, लेकिन पिछले 1 साल में progress की speed चौंकाने वाली रही है। skepticism अच्छी बात है, लेकिन healthy skepticism को ठोस evidence के सामने पीछे हटना चाहिए
    • tools से जुड़े किसी भी विषय में, कुछ लोग tool को ही पसंद करते हैं और कुछ लोग उस tool से कोई दूसरी चीज़ करना पसंद करते हैं। programming में मैं दूसरे तरह का था। programming मेरे लिए उस problem solving, system-level thinking, और software के ज़रिए शानदार solutions देने का tool है, जिसे मैं सच में पसंद करता हूँ
      इसलिए AI अगर boring हिस्सों में मदद करता है तो मुझे वाकई बहुत मज़ा आता है, और non-programmer colleagues को अपनी vibe coded ideas को हक़ीक़त बनते देखकर उत्साहित होते देखना भी बहुत दिलचस्प है। software industry में काम करने वाले anti-AI stance वाले लोगों का नज़रिया मैं सच में जानना चाहता हूँ। क्या इसकी वजह नौकरी का आसन्न अंत है, या कोई तकनीकी बदलाव?
    • अगर 90s के मध्य में outsourcing बढ़ने पर “Indian developers” के लिए तिरस्कारपूर्ण शब्द इस्तेमाल होने लगे थे, तो उसकी वजह क्या थी?
    • मैं outsourced code हमेशा deal करता हूँ, और बिना किसी अपवाद के वह tire fire जैसा होता है। अभी भी मैंने एक codebase को एक हफ़्ते तक साफ़ किया, जिसमें किसी developer ने local work environment सेट करना नहीं सीखा था और authentication checks को bypass करने वाला flag default on के साथ commit कर दिया था
      AI vibe coding में भी वही “shortcuts” वाली समस्या report हो रही है, और मैंने ख़ुद frontier models को reasoning level 11 तक बढ़ाकर इस्तेमाल किया, फिर भी AI-generated लगभग हर code को दोबारा लिखना पड़ा। फिर भी PR review, security vulnerability analysis, typo ढूँढने, reverse engineering जैसी दूसरी गतिविधियों में AI बहुत उपयोगी है। शायद मुझे subscription को अगले tier पर ले जाना पड़ेगा, लेकिन साथ ही AI-generated code अब भी इस्तेमाल लायक नहीं है। अगर एक ही व्यक्ति के भीतर “इतना उपयोगी कि ज़्यादा पैसे देने पड़ें” और “output code quality बेकार है” दोनों बातें एक साथ सच हो सकती हैं, तो पूरे user base में अलग-अलग राय होना स्वाभाविक है
    • LLM context retrieval और template output में अच्छे हैं। लेकिन जो चीज़ मिलती है वह अक्सर सबसे कम साझा हरफ़नमौला जवाब होती है, ऐसा output जिस पर copyright protection नहीं है, और copyright leakage से जुड़े संभावित legal risks भी हैं
      अभी का समय homomorphic plagiarism के Napster golden age जैसा है

  • समझ नहीं आता यह सब क्या है। असल में मायने सिर्फ़ इस बात के हैं कि codebase में AI द्वारा लिखे code को अनुमति मिलने के बाद bugs बढ़े या नहीं। जवाब सबको पता है। फिर भी यह देखना हमेशा दिलचस्प होता है कि “data” का इस्तेमाल किसी ज़रूरी निष्कर्ष जैसा दिखने वाला निष्कर्ष बनाने में कैसे किया जा सकता है
 
GN⁺ 2026-06-06
Lobste.rs की राय

  • आगे चलकर vibe coding से आगे बढ़ने वाले FOSS प्रोजेक्ट्स को इस्तेमाल करते रहना है या नहीं, यह हर कोई खुद तय कर सकता है। लेकिन मेंटेनर के vibe coding tools पर जाने के बाद कम्युनिटी ने जो गुस्सा दिखाया, वह काफ़ी चौंकाने वाला था, और लेख में दिया गया अनुभवजन्य डेटा कम-से-कम उस प्रैक्टिस बदलाव के असर को बेहतर संदर्भ देता है
    मेंटेनर द्वारा यह coding तरीका अपनाने के बाद भरोसा बना रहेगा या और टूटेगा, यह समय के साथ ही पता चलेगा

    • सोचता हूँ कि इस बदलाव पर गुस्सा करने वालों में से वास्तव में कितनों ने rsync में सार्थक योगदान दिया था या पैसे दिए थे

  • यह विश्लेषण बिल्कुल वही था जिसकी मुझे उम्मीद थी, बल्कि उससे भी ज़्यादा। खासकर “सभी metrics, methodology, और data sources मैंने खुद चुने, अपनी पत्नी से सलाह करके, जो Penn State University में statistics में master's हैं” वाला हिस्सा अच्छा लगा, और वास्तविक statistics expert को शामिल करना और इसे पढ़ने में आसान लेख बनाना शानदार था
    इसमें “हर 10 commits पर bugs” वाला एकल metric इस्तेमाल किया गया, लेकिन लगता है कि SI prefix का इस्तेमाल करके इसे प्रति commit decibugs कहना का मौका चूक गया

    • सहमत। यह मेरी पोस्ट नहीं है, लेकिन अच्छा लगा कि किसी ने गरमाई हुई पक्ष-विपक्ष बहस से आगे बढ़कर code quality पर पड़े असर को data के साथ दिखाया

  • open source प्रोजेक्ट्स की सफलता perception पर बहुत ज़्यादा निर्भर करती है, इसलिए लोग GitHub stars भी पैसे देकर खरीदते हैं। दुर्भाग्य से इस बार perception की समस्या नियंत्रण से बाहर जाकर एक talking point बन गई है, और कोई भी data इसे बदलने में मुश्किल से काम आएगा
    आगे चलकर “rsync मेंटेनर ने LLM इस्तेमाल किया और वह टूट गया” जैसी बात AI skeptics द्वारा “data centers रोज़ 5 लाख gallons साफ पानी बर्बाद करते हैं”, “METR research ने कहा कि LLM productivity घटाते हैं” जैसे talking points के साथ उठाई जाएगी
    मैं यह कहने की कोशिश नहीं कर रहा कि मैं AI skeptic हूँ या नहीं, बल्कि यह कि इस विषय पर बहसें आम तौर पर ऐसे ही चलती हैं

    • वह “talking point” क्यों है, क्या वह बस तथ्य नहीं है?
    • पता नहीं लेखक data के ज़रिए किसी को मनाने की कोशिश कर रहा है या नहीं। मुझे यह लेख rsync के tool adoption के इर्द-गिर्द हुई तीखी बहस में data context जोड़ने जैसा लगा
      लेकिन यह कहना सही है कि लेख में बाकी non-quantitative factors पूरी तरह गायब हैं, और शायद ऐसा जानबूझकर किया गया क्योंकि evangelists और skeptics दोनों तरफ़ का शोर पहले से ही काफ़ी है

  • rsync के इतिहास की सबसे खराब release, Claude के आने से पहले की थी, और हर 10 commits पर 39.39 bugs थे — यह बहुत महत्वपूर्ण और अनुमानित निष्कर्ष है
    अगर users और developers के बीच testing, quality assurance जैसी processes software की correctness सुनिश्चित नहीं कर पातीं, तो LLM हो या न हो, bugs release हो ही जाएंगे। LLM इस process में नुकसान भी पहुँचा सकता है और मदद भी कर सकता है

    • सहमत। cURL की हाल की पोस्ट शायद इसका उल्टा उदाहरण दिखाती है
      कई सालों से स्थापित मजबूत software engineering practices की वजह से, ऐसे AI tools से bugs ढूँढने की उपयोगिता कुल मिलाकर कम हो गई है
    • rsync के भविष्य को लेकर मेरी कुछ चिंताएँ हैं। सबसे बड़ा मुद्दा यह है कि rsync असल में कई सालों से लगभग पूरा हो चुका प्रोजेक्ट था, लेकिन AI का इस्तेमाल करते हुए मौजूदा test code को हटाया गया, उसे Python test suite से बदला गया, और काफी समय तक पुराने tests साथ चलाकर correctness verify नहीं की गई
      मेरे हिसाब से यह गैर-जिम्मेदाराना है। खासकर इसलिए कि rsync का मुख्य उद्देश्य कीमती data को transfer करना है, और उस data की integrity बिल्कुल अहम है

  • “AI-विरोधी users की तरह यह आखिरकार हिंसक fantasies तक escalated हो गया” जैसी भाषा से बचना चाहिए। इससे लेखक न सिर्फ़ उन कुछ लोगों को सामान्यीकृत करता है जिनसे वह असहमत है, बल्कि उन पाठकों को भी दूर कर देता है जो मूल रूप से उससे सहमत नहीं हैं, जिससे वे लोग ही लेख नहीं पढ़ते जिन्हें शायद सबसे ज़्यादा पढ़ना चाहिए
    अलग बात है कि पिछले versions की तुलना में इसमें bugs ज़्यादा हैं या कम, इससे मुझे ज़्यादा फर्क नहीं पड़ता। मेरे लिए अहम यह है कि इसे ऐसे तरीके से develop किया जा रहा है जो software development के उस तरीके से मेल नहीं खाता जिसे मैं सही मानता हूँ। अगर efficiency के अलावा भी समस्याएँ हो सकती हैं, इसकी बुनियादी समझ ही नहीं है, तो इस रुख को उचित बताकर किसी को मनाने की उम्मीद नहीं है
    अच्छी बात यह है कि अगर चाहूँ नहीं, तो rsync का यह version इस्तेमाल न करूँ, और LLM इस्तेमाल होने से पहले वाले forked विकल्प को चुनूँगा

    • इस लेख में बहुत गुस्सा भरा हुआ था, इसलिए मैं इसे ज़्यादा देर तक पढ़ नहीं पाया और छोड़ दिया। अगर यह ज़्यादा निष्पक्ष बनने की कोशिश करता, या कम-से-कम ऐसा दिखता, तो बेहतर होता
      यह भी मददगार नहीं था कि इसमें एक पुराना meme दोहराया गया, जिसे बहुत पहले खारिज किया जा चुका है — यानी कि पहला bug report वही issue था जिस पर लोग टूट पड़े थे। असल पहला bug report अलग था

  • अभी की पोस्ट ईमानदारी से मुझे बेहतर लगती है। लेकिन “यह मेट्रिक commit complexity, security sensitivity, और bug severity को control नहीं कर पाता। यह एक कुंद tool है जो एक-line typo fix और CVE patch में फ़र्क नहीं कर पाता” वाला हिस्सा, LLM बुरा है वाली मेरी स्थिति से देखें तो, असल आलोचना को मिस करता है
    मेरी और दूसरों की आलोचना यह है कि AI ऐसे commits की बाढ़ ला देता है जो बड़े होते हैं, समझने में आसान नहीं होते, और complexity बढ़ाते हैं। LLM समर्थक भी कुछ ऐसा ही कहते हैं, फिर दशकों से परखी हुई “PR पढ़ो” प्रथा से गोलपोस्ट खिसकाकर “LLM को सब कुछ test कर पाना चाहिए” पर ले जाते हैं। लेकिन code complexity कि तकनीकी debt है, यह समस्या गायब नहीं होती
    इस मामले में bug severity बहुत ऊँची है। backup workflow सचमुच टूट गया था। rsync backup के लिए बहुत इस्तेमाल होता है, और लोग इसे इतना “battle-tested” मानते आए हैं कि patch update से backup scripts टूट सकती हैं, ऐसा वे सोचते भी नहीं
    यह कहा जा सकता है कि LLM का buggy software बनाना बस एक accident था, या maintainer को LLM workflow बदलना चाहिए और test coverage बढ़ानी चाहिए। maintainer ने वास्तव में यही कहा भी। लेकिन गुस्से का केंद्र यह है कि इस tool ने उस भरोसे को तोड़ा
    सच में, आजकल LLM programmers की एक नई किस्म है जो कहती है कि वे “code पढ़ते ही नहीं”। वजह यह है कि पढ़ने में बहुत समय लगता है और यह आम programmers के code से ज़्यादा जटिल होता है। Code पढ़ना मतलब दूसरे व्यक्ति के mental model को सीखना, लेकिन LLM tools एक consistent mental model दे ही नहीं पाते
    अलग बात, site accessibility भी देखनी चाहिए। मेरी नज़र काफ़ी अच्छी है और मैं अभी late 20s में हूँ, फिर भी cream/yellow background पर हल्का gray text पढ़ना सच में तकलीफ़देह है

    • उद्धृत हिस्सा मुझे उलझा रहा है। पोस्ट में इस्तेमाल किया गया मेट्रिक तो हर 10 commits पर bugs की संख्या को severity weight देने जैसा लग रहा है; क्या लेखक खुद से विरोधाभास कर रहा है? या मैं ग़लत पढ़ रहा हूँ?
    • जिन लोगों का workflow टूटा, उनके लिए यह सीखने का अच्छा मौका है कि open source software और GPL license क्या हैं, और वे किस तरह की guarantees देते हैं
      मुझे नहीं लगता कि लोगों ने खुद वह bug ढूँढ लिया होगा। मेरा अनुमान है कि rsync users में 90% से ज़्यादा अभी भी वह पुराना version चला रहे होंगे जिसमें यह bug नहीं है। मैं भी उन्हीं में से एक हूँ 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      अगर इसने ध्यान खींचा है, तो इतना समझने के लिए Steven Pinker होने की ज़रूरत नहीं कि अभी community का काफ़ी हिस्सा भ्रम में है। यह स्वीकार करना आसान नहीं कि LLM इंसानों से बेहतर programming कर सकते हैं
      जिन लोगों ने अपनी identity और self-esteem को programming skill या profession पर टिकाया था, वे अब दोहरे संकट का सामना कर रहे हैं: भविष्य की livelihood/market value को लेकर अनिश्चितता, और identity crisis
      डर, uncertainty, और doubt से निपटना मुश्किल होता है, और LLM कंपनियाँ share price बढ़ाने के लिए इन प्रभावों को बढ़ाने में पूरी कोशिश कर रही हैं। अगर October के बाद market में तेज़ correction आता है, तो शायद यह amplification mechanism भी कमज़ोर पड़े
      दुनिया भर के programmers में बहुत छोटा हिस्सा, यानी जो code को art form की तरह देखते हैं, शायद LLM का उपयोग training और skill improvement के लिए करेंगे

  • यह पोस्ट regression का ज़िक्र करने वाले comments बहुत quote करती है, लेकिन analysis खुद regression नहीं बल्कि सिर्फ bug reports को measure करता है। यह bugs को उस release से नहीं जोड़ती जिसमें वे introduce हुए, बल्कि उस release से जोड़ती है जिसमें वे report हुए, और release severity को commit count से नापती है, जबकि release duration या distribution adoption जैसे साफ़ factors को छोड़ देती है
    मुझे समझ नहीं आता कि यह कैसे तर्कसंगत है

  • निजी तौर पर मैं LLM इस्तेमाल करने वाले projects से बचता हूँ। कोई बहुत ठोस कारण नहीं है; बस यह मुझे बहुत अप्रिय लगता है, कुछ वैसे ही जैसे कोई “kek” या “fren” जैसे शब्द इस्तेमाल करे तो मैं उसे बिना किसी खास वजह के आगे interaction न करने का संकेत मान लेता हूँ
    अभी LLM उपयोग को नापसंद करने के लिए जो explanations दिए जाते हैं, वे मुझे उलटी दिशा में जोड़ी गई rationalization जैसे लगते हैं। Ethics, quality जैसी मौजूदा चिंताएँ सही हैं, लेकिन अगर वे समस्याएँ हल भी हो जाएँ, तो भी मेरे जैसे AI-विरोधी झुकाव वाले लोग अचानक सहज हो जाएँगे, ऐसा नहीं लगता
    इसलिए जिन projects में “AGENTS.md”, Claude co-authored commits वगैरह हों, उनसे मैं किसी ठोस वजह के बिना बचता हूँ। बस यह मुझे अप्रिय लगता है, मेरी पसंद के खिलाफ़ है, और bugs हों या न हों, उससे फ़र्क नहीं पड़ता। शायद और लोग भी ऐसा ही महसूस करते हों

  • लेखक से कहूँ तो, पहली बात, fantasy तो भाषा है। व्यवहार में आप यह कह रहे हैं कि वह बात भाषा तक ही रुकी, या कम से कम आप यह दावा नहीं कर रहे कि उसका कोई nonverbal escalation हुआ
    दूसरी बात, अगर ऐसा दावा करना है तो किसी नज़दीकी statistics expert से पूछना चाहिए कि इसे कैसे support किया जा सकता है। सिर्फ़ यह कि कुछ लोगों ने ऐसी posts कीं, इससे यह दावा सार्थक रूप से support नहीं होता कि वह “typical” है
    मेरी अपनी anecdotal observation, जिसे मैं statistics से support नहीं कर रहा, यह है कि “AI-विरोधी” users आम तौर पर LLM के उन जगहों में घुस आने पर, जहाँ वह मददगार नहीं है, हिंसक होने से ज़्यादा दुखी होते हैं

    • कभी-कभी मैं बहुत लंबे और विस्तार से लिखे गए ऐसे posts देखता हूँ जो LLM विरोधियों के एक हिस्से, आम तौर पर उन लोगों का जो LLM पर भावनात्मक या सामाजिक प्रतिक्रिया देते हैं, खंडन करने की कोशिश करते हैं। ऐसे posts को साफ़-साफ़ समझाना मुश्किल है, लेकिन वे बहुत bad-faith लगते हैं, और जैसे कमज़ोर पर वार किया जा रहा हो
      वे इतने विस्तार में जाते हैं कि भावनात्मक दृष्टिकोण से उनका जवाब देना मुश्किल हो जाता है, और आख़िर में बात कुछ ऐसी लगती है: “समस्या LLM नहीं है; सही इस्तेमाल हो तो यह amplification tool है। AI-विरोधी लोग बस नहीं समझते, और पीछे छूट जाने से डरते हैं”
      मैं rsync maintainers के काम को किसी बहस में घटाकर नहीं दिखाना चाहता, इसलिए मुझे नहीं पता कि मैं इसका कोई प्रभावी counterargument कैसे बनाऊँ
      यहाँ की statistics open source maintenance के नज़रिए से दिलचस्प हो सकती हैं, लेकिन निष्कर्ष अजीब तरह से एक तरफ़ झुका हुआ लगता है, और इससे यह एहसास भी रहता है कि GitHub-style open source वह रूप नहीं है जिसमें मैं योगदान देना चाहता हूँ
      फिर भी, rsync repository में maintainer पर लोगों का झुंड बनाकर टूट पड़ना बिल्कुल अच्छा नहीं था
    • सार्वजनिक हिंसक fantasy को अस्वीकार्य कहना सही है। यह ऐसी चीज़ नहीं है जिसे हम सभ्यता के रूप में लक्ष्य बनाना चाहें। लेकिन लेखक ने उसे “typical” कहा, यह सामान्यीकरण मुझे खटकता है
      anecdotal observation के मामले में, यह comic सही बात कहती है। मुझे ठोस और measurable दावे देखना पसंद है, partly इसलिए कि मुझे numbers पसंद हैं, और partly इसलिए कि online discussions को आख़िरी panel वाली आदर्श दुनिया के थोड़ा और क़रीब लाया जा सके

  • विश्लेषण के लिए धन्यवाद, लेकिन methodology को लेकर भरोसा नहीं बन रहा। मैं ऐसे metrics के बारे में जानना चाहूँगा जैसे हर commit में core code — यानी test या documentation नहीं, बल्कि actual code — की बदली गई lines की संख्या से गुणा किया गया difference unit bug count, और यह विश्लेषण कि release के बाद किसी तय bug count तक पहुँचने में कितना समय लगता है
    हालांकि, इस बार की release को दूसरी releases की तुलना में कहीं ज़्यादा attention मिला, इसलिए bugs ज़्यादा report हुए होने की संभावना भी काफ़ी है। इस वजह से कोई बहुत convincing metric बनाना मुश्किल लगता है। “release के कुछ हफ्तों बाद के हिसाब से क्या यह typical है?” जैसे सवाल भी शायद बहुत उपयोगी न हों