Dependencies में LLM-जनरेटेड कोड पर रोक

• git-annex को LLM-जनरेटेड कोड वाली dependencies के बिना build हो सके, यह सुनिश्चित करने के लिए पिछले एक महीने में लगभग 100 घंटे लगाकर जांचा गया
• यह काम दिखाता है कि व्यक्तिगत code से ज्यादा पूरे dependency tree को लगातार track करने की वास्तविकता है, जिससे maintenance का बोझ काफी बढ़ जाता है
• जांच के दौरान बड़े पैमाने के LLM-जनरेटेड बदलावों को बिना explanation वापस लेना, 26,000 LOC codebase में 10,000 lines का बदलाव, और 1,489 lines वाला असंगत commit message जैसे मामले मिले
• dependencies की quality information के बारे में अतिरिक्त जानकारी मिलना सकारात्मक है, लेकिन Software Freedom Conservancy या FSF जैसे संगठन-स्तरीय response को लेकर संदेह बना हुआ है
• LLM से config जोड़ना या formatting बदलाव करना आसान हो सकता है, लेकिन ऐसे commits collaboration trust और project participation पर सीधे costs डाल सकते हैं

---

git-annex dependency जांच

• git-annex को LLM-जनरेटेड code वाली dependencies के बिना build हो सके, यह जांचने में करीब एक महीने तक लगभग 100 घंटे लगाए गए
• अभी तक लक्ष्य हासिल हुआ दिखता है
• संबंधित page git-annex no LLM code है
• समस्या का core किसी program के पूरे dependency tree की लगातार review करने की जिम्मेदारी में है

जांच में सामने आए मामले और असर

• मिले हुए मामले सिर्फ पसंद-नापसंद का मुद्दा नहीं, बल्कि maintenance और trust की समस्या बन जाते हैं
  • बड़े पैमाने के LLM-जनरेटेड बदलाव अगले release में बिना किसी explanation के revert कर दिए गए
  • 26,000 LOC codebase में 10,000 lines का बदलाव जोड़ा गया, और commit message 1,489 lines की असंगत सामग्री था
  • किसी दूसरे project से code copy करने के लिए LLM prompt था, और लगता है कि किस्मत से copyright infringement से बच गया
• इस काम से dependencies की quality के बारे में अतिरिक्त जानकारी मिली, और यह जानकारी आगे के choices को प्रभावित कर सकती है
• Software Freedom Conservancy ने LLM-based generative AI recommendations में इस मुद्दे को टाल दिया लगता है, और FSF इससे बेहतर करेगा या नहीं, यह भी अनिश्चित है
• ऐसे बदलावों के बीच संबंधित community participation पर फिर से विचार किया जा रहा है, लेकिन काम और user support जारी हैं
• LLM को Add fourmolu config and restyled, neat, format a module जैसे prompts देकर output commit करना आसान लग सकता है, लेकिन उस action के व्यापक असर पर विचार करना चाहिए

[GN⁺]

Lobste.rs की राय

• आज पता चला कि git-annex Haskell में लिखा गया है—काफी बढ़िया

  आज घर लौटते समय मेट्रो में मेरे बगल वाला व्यक्ति YouTube Shorts पूरी आवाज़ पर देख रहा था, और शांत, खचाखच भरी ट्रेन में वह शोर प्रदूषण जैसा लगकर चिढ़ा रहा था
  उससे भी ज़्यादा चिढ़ाने वाली बात यह थी कि वह जो वीडियो देख रहा था, वह पूरी तरह AI से बना घटिया वीडियो था

  इस लेख में dependencies के लेखकों द्वारा LLM से ऐसे बदलाव बनवाने वाली बात, जिन्हें समझना मुश्किल हो, मेरे मन को लगी
  LLM के दुरुपयोग में सबसे निराशाजनक हिस्सा यह है कि यह लोगों के आपसी interaction को बिगाड़ देता है
  पहले किसी कंपनी में ढीले-ढाले ढंग से सोचे गए प्रस्ताव की समीक्षा भी करते थे तो मुख्य idea साफ दिखता था, इसलिए उसे पकड़ना और उस पर comment करना आसान था; लेकिन अब कोई भी अधकच्चे बदलाव को LLM में डालकर ऐसा output बना सकता है जो ऊपर से अच्छी तरह बना हुआ लगे, पर review करने पर छेदों से भरा निकले
  इसी तरह ऊपर से अच्छा दिखने वाला खराब code भी बनाया जा सकता है

  यह कोई नई शिकायत नहीं है, लेकिन अब धीरे-धीरे चुभने लगी है
  ऐसा लगता है कि काम और जीवन को आनंददायक और भरपूर बनाने वाले मानवीय जुड़ाव का एक अहम हिस्सा हम खोते जा रहे हैं

  • अच्छा है कि सहकर्मी ईमानदारी से बता देता है, “यह 🤖 ने किया है”, ताकि पहले से पता रहे कि किस स्तर की review की उम्मीद करनी है
    आम तौर पर यह codebase को और सीखने के लिए अपनाई गई प्रक्रिया का documentation होता है, इसलिए भरोसा किया जा सकता है कि सहकर्मी ने LLM output पढ़ा है और वह यह confirm कराना चाहता है कि उसने सही तरह से सीखा है

  • मेरे हिसाब से LLM ने quality की relative price बदल दी है
    घर के उदाहरण से समझें तो, पहले टपकती छत और खराब foundation वाला बेहद खराब McMansion 1000X का था, और छिपी हुई परेशानियों से मुक्त अच्छा घर 2000X का

    अब LLM technology की मदद से कुशल व्यक्ति कुछ mechanical और आसानी से verify होने वाले काम outsource करके अच्छे घर की कीमत सैद्धांतिक तौर पर 1500X तक घटा सकता है
    लेकिन खराब McMansion 100X तक गिर गया है

    इसलिए कम-quality वाले McMansion, quality वाले काम को बदसूरत तरीके से बाहर धकेल सकते हैं
    अच्छे घर को 2000X से 1500X पर लाने वाले कारीगरों को परेशान करने का मेरा इरादा नहीं है, लेकिन अगर 100X वाले घटिया घर बाजार से बेहतर चीज़ों को बाहर कर दें और lemons market बना दें, तो ग्राहक पूरे software को लेकर कहीं ज़्यादा शक करने लग सकते हैं
    lemons market इसलिए बदसूरत होता है क्योंकि खरीदार के पास quality और कचरे में फर्क करने का तरीका नहीं होता
    software में इसका सबसे मशहूर उदाहरण 1983 का video game crash है, जब बेहद घटिया games की लहर से बहुत से ग्राहक जल गए और खरीदना बंद कर दिया

• मुझे यह रुख काफी reasonable लगता है
  निजी तौर पर मुझे लगता है कि समय के साथ इसमें से ज्यादातर कोशिश व्यर्थ हो जाएगी, और मेरे software इस्तेमाल में यह बहुत चिंता की बात नहीं है, लेकिन subjective नज़रिये से यह पूरी तरह valid और रोचक है, और मुझे अच्छा लगता है कि यह व्यक्ति ऐसा कर रहा है

  जैसे AI optimists बातें बढ़ा-चढ़ाकर कहते हैं, वैसे ही anti-AI पक्ष भी नकारात्मक पहलुओं को जरूरत से ज्यादा dramatic बनाने की प्रवृत्ति रखता है
  यह लेख खुद काफी हद तक अपवाद है, लेकिन अगर आखिरी paragraph की जल्दबाज़ generalization हटा दी जाती, तो इसका overall intent और message कहीं ज्यादा मजबूत हो जाता

  फिर भी मुझे ऐसे लेख पढ़कर भावनाओं के बीच दिलचस्प हिस्से ढूंढना पसंद है
  अगर हर project के लिए last known 100% non-LLM code का database हो, तो दिलचस्प होगा
  influential slop का database भी मजेदार होगा; यहां “influential” का मतलब positive और negative दोनों है, और “slop” का मतलब unreviewed output होना अहम है

  मोटे तौर पर 2023 की शुरुआत का GitHub archive उठाकर भी धोखा दिया जा सकता है, लेकिन किसी खास समय के snapshot के बजाय हर project का last commit snapshot हो तो और दिलचस्प होगा
  इस dataset से कई दिलचस्प नतीजे निकल सकते हैं, और यह उन लोगों के लिए भी मददगार होगा जो इस लेख की तरह सिर्फ non-LLM software से ecosystem बनाना चाहते हैं

  जैसा आप शायद पहले ही अंदाज़ा लगा चुके होंगे, मैं LLM user हूं
  फिर भी मुझे लगता है कि मैं reasonable पक्ष में हूं
  जिज्ञासा हो तो मेरी website के लेख पढ़ सकते हैं, लेकिन मैं वादा करता हूं कि blog post का मुख्य text 100% इंसान ने लिखा है
  मुझे लगता है कि विरोधी राय पढ़ना सीखने और बढ़ने के सबसे अच्छे तरीकों में से एक है, इसलिए मुझे ऐसी कोशिशों में शामिल होना पसंद है

  • हर project के last non-LLM version को track करने के करीब का एक project मौजूद है
    इसे जोरदार anti-AI रुझान वाले लोग चलाते हैं: https://codeberg.org/ethical-foss/open-slopware
    कुछ projects में “last untainted version or commit ID” है, लेकिन यह सभी projects को cover नहीं करता

• मैंने यह लेख इसलिए submit किया क्योंकि मुझे अच्छा लगा कि लेखक ने dependencies में LLM इस्तेमाल का संकेत देने वाले specific commits खुद खोजे और अपनी findings को summarize करने वाला page बनाया

  निजी तौर पर मुझे यकीन नहीं था कि इसमें vibecoding tag लगाना चाहिए या नहीं, क्योंकि यह लेख vibe coding से ज्यादा community और practices के बारे में है

• इसमें एक पंक्ति है: “मुझे पता है कि इस point पर शायद मैं चढ़ती लहर को रोकने की कोशिश कर रहा हूं”

  जिस compiler पर project depend करता है, अगर वही प्रभावित हो जाए तो आप जीत नहीं सकते
  मैं भी damage control कर रहा हूं, लेकिन आखिर में ऐसा पल आता है जब alternatives पर अड़े रहना और भी खराब हो जाता है, इसलिए झुकना ही पड़ता है

• मुश्किल समस्या है
  कितनी भी अच्छी analysis कर लें, LLM code से बचना मुश्किल होने की संभावना है
  उदाहरण के लिए code autocomplete से आया code पकड़ा नहीं जा सकेगा

• मेरे हिसाब से trust उस समय नहीं टूटा जब इन libraries ने LLM इस्तेमाल करना शुरू किया, बल्कि तब टूटा जब उन्होंने बहुत बड़े changes accept और integrate किए और उनके साथ पढ़ने में मुश्किल, बेकार commit messages लगाए

  यह LLM इस्तेमाल से अलग software engineering failure है

  वैसे, मुझे Joey Hess और उनका software पसंद है, और मैं इस पक्ष में हूं कि code contribution का मूल्यांकन इस आधार पर होना चाहिए कि result कितना अच्छा है, चाहे वह किसी भी tool से बनाया गया हो

• समझाने का तरीका थोड़ा disappointing है
  persistent commit मुझे LLM द्वारा लिखा हुआ नहीं लगता
  मैं चाहूंगा कि लोग “Co-authored-by” लगे हर commit को LLM-generated न कहें

  पहला yesod link CI change है, इसलिए मुझे नहीं लगता कि उसे dependency code कहा जा सकता है
  “1489-line commit message वाला LLM-generated commit” सुनकर लगा था कि commit खुद पागलपन भरा होगा, लेकिन असल में यह reasonable squash merge है, बस diff बहुत बड़ा है

  cabal commit में कहा गया है कि LLM ने सिर्फ tests generate किए, और यह भी सवाल है कि क्या उसे मेरे depend करने वाले code के रूप में देखना चाहिए
  git commit भी बस CI है

  मुझे इसमें शक नहीं कि इन dependencies में से कुछ LLM इस्तेमाल करती हैं, लेकिन पेश किए गए evidence को पर्याप्त मजबूत कहना मुश्किल है
  दूसरी तरफ, इसमें उम्मीद से कहीं ज्यादा मेहनत लगी है, और यह अच्छा है कि कुछ ऐसा है जिसे किसी dependency का इस्तेमाल न करने के specific reason के तौर पर point किया जा सके