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

मूल लेख ↗ Hacker News चर्चा ↗

rsync / Claude समस्या का दायरा

  • कई टिप्पणीकारों का कहना है कि rsync में कमिट्स में भारी उछाल और तेज़ सुरक्षा कड़ीकरण देखा गया, जो (अक्सर AI-जनित) सुरक्षा रिपोर्टों की बाढ़ से प्रेरित था।
  • कुछ उपयोगकर्ताओं को गंभीर रिग्रेशन मिले (जैसे, इन्क्रिमेंटल बैकअप टूटना, उच्च CPU उपयोग) और उन्होंने rsync को पुराने संस्करणों पर पिन कर दिया।
  • अन्य लोग बताते हैं कि LLM-पूर्व रिलीज़ में भी रिग्रेशन और गंभीर बग हुए थे, और rsync लंबे समय से एक जटिल, कठिन-से-परीक्षण C कोडबेस रहा है।

बग्स का सांख्यिकीय विश्लेषण

  • लिंक किया गया लेख कई रिलीज़ों में “हर 10 कमिट पर बग्स” का विश्लेषण करता है, जिसे बाद में LLM-आधारित गंभीरता स्कोर तक बढ़ाया गया।
  • मुख्य दावा: Claude-से संबद्ध दो रिलीज़ ऐतिहासिक भिन्नता की सीमा में ही हैं और असामान्य रूप से बग्गी नहीं दिखतीं, यहाँ तक कि गंभीरता के हिसाब से भार देने पर भी।
  • आलोचकों का तर्क है:
    • “Claude रिलीज़” के लिए डेटासेट सिर्फ़ दो बिंदुओं का है; अध्ययन की शक्ति कम है।
    • बग्स/कमिट गंभीरता को छिपाता है और कमिट वॉल्यूम में बड़े उछाल को ढक देता है।
    • गैर-महत्वपूर्ण p-values का मतलब “अंतर का कोई प्रमाण नहीं” है, “कोई अंतर नहीं” का प्रमाण नहीं।
  • समर्थक जवाब देते हैं कि यह फिर भी मूल “Claude ने rsync तोड़ दिया” आरोपों के पीछे मौजूद कठोरता से अधिक है, जो अधिकतर किस्सों पर आधारित थे।

कोड गुणवत्ता और ठोस रिग्रेशन

  • चर्चा में एक उदाहरण: एक बदलाव जिसने प्रभावी रूप से कई allocations को calloc में बदल दिया, और बाद में मेमोरी/CPU रिग्रेशन के कारण वापस ले लिया गया। मेंटेनर कहते हैं कि निर्णय उनका था, Claude का नहीं, हालांकि एक AI co-author टैग दिखाई देता है।
  • कुछ लोग इसे और ऐसे ही बदलावों को “AI slop” और अत्यधिक churn का संकेत मानते हैं; अन्य इसे भारी रिपोर्ट-लोड के तहत जल्दबाज़ी में किए गए सुरक्षा कार्य का परिणाम मानते हैं, चाहे जो भी उपकरण इस्तेमाल हुए हों।

विकास में LLMs और attribution

  • कई डेवलपर कहते हैं कि LLMs उत्पादकता को काफी बढ़ाते हैं, खासकर boilerplate, tests, और refactoring के लिए, लेकिन वे ऐसा कोड बनाते हैं जिसे एक जूनियर के काम की तरह review करना चाहिए।
  • समीक्षक शिकायत करते हैं कि AI-जनित PRs बड़े, शोरगुल वाले, और समझने में कठिन होते हैं, जिससे review बोझ बढ़ता है।
  • commit attribution पर तीखी बहस:
    • एक पक्ष जोखिम, review शैली, और copyright provenance के लिए स्पष्ट LLM markers चाहता है।
    • अन्य लोग तर्क देते हैं कि human committer ही ज़िम्मेदार है, उपकरणों की परवाह किए बिना; बिना बताए LLM उपयोग अपने-आप में “fraud” नहीं है।

AI-लिखित गद्य और समुदाय के व्यवहार पर प्रतिक्रिया

  • लेख की शुरुआती LLM-लिखित prose ने तीखी प्रतिक्रिया भड़काई; कई लोगों ने इसे “AI slop” कहा और कहा कि इसी से उनका भरोसा कम हुआ।
  • लेखक ने बाद में prose को हाथ से फिर से लिखा; कुछ लोगों को तब यह बहुत अधिक पठनीय लगा, जबकि अन्य मूल चयन और दिखने वाले AI tooling के कारण संशय में रहे।
  • कई टिप्पणियों में outrage की विषाक्तता, मेंटेनरों पर व्यक्तिगत हमलों, और OSS उपयोगकर्ताओं में बढ़ती entitlement पर अफ़सोस जताया गया।