Ladybird के विकास तरीके में बदलाव

 (ladybird.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Ladybird अपने पहले alpha release और वास्तविक उपयोगकर्ताओं के लिए ब्राउज़र लॉन्च की तैयारी के साथ public pull request स्वीकार करना बंद कर रहा है, और अब code changes केवल project maintainers ही शामिल करेंगे
  • AI tools की वजह से ऐसे काम को, जो गंभीर योगदान जैसा दिखे, पहले से ज़्यादा तेज़ और सस्ता बनाना संभव हो गया है; इससे यह पुराना trust model कमजोर हुआ है कि बड़ा patch अपने-आप सद्भावना या काफ़ी मेहनत का संकेत होता है
  • ब्राउज़र पूरे इंटरनेट से आने वाले अविश्वसनीय input को user machine पर चलाते हैं, इसलिए एक भी अच्छी तरह छिपाई गई vulnerability हमलावर के लिए काफ़ी हो सकती है
  • अभी खुले हुए सभी public PR बंद किए जाएंगे, और issues, comments, email, या forks के ज़रिए अलग patch submission process या shadow contribution system नहीं बनाया जाएगा
  • Ladybird open source बना रहेगा, और बाहरी भागीदारी code submission की जगह स्पष्ट bug reports, reductions, website testing, standards और design discussion, security reports, तथा technical feedback के रूप में की जाएगी

विकास प्रक्रिया में बदलाव के मुख्य बिंदु

  • Ladybird अब public pull request स्वीकार नहीं करेगा और codebase में बदलाव केवल project maintainers द्वारा ही लाए जाएंगे
  • पहले alpha release की तैयारी के इस चरण में अधिक सख्त development process, अधिक स्पष्ट security model, और ब्राउज़र में जाने वाले code की ज़िम्मेदारी लेने वाला छोटा समूह आवश्यक हो गया है
  • पहले बड़े patches को काफ़ी मेहनत और सद्भावना का एक उचित अप्रत्यक्ष संकेत माना जाता था, लेकिन AI tools के कारण यह मान्यता अब वैसी नहीं रही
  • ब्राउज़र इंटरनेट से आने वाले अविश्वसनीय input को user machine पर चलाते हैं, और एक अच्छी तरह छिपी vulnerability ही हमलावर के लिए पर्याप्त हो सकती है
  • open source में maintainers का trust हासिल कर उसका दुरुपयोग करने की धैर्यवान और संसाधन-संपन्न मुहिम पहले भी रही है; अब फर्क यह है that AI tools ने गंभीर योगदान जैसा दिखने वाला काम अधिक तेज़ और सस्ता बना दिया है
  • Ladybird में आने वाला हर बदलाव architecture के अनुरूप होना चाहिए, भविष्य के refactoring को सह सके, ब्राउज़र के बाकी हिस्सों के साथ सही तरह interact करे, और maintainers उसे समझ सकें
  • यह मुख्य बात नहीं है कि code हाथ से लिखा गया था या नहीं; मुख्य बात यह है कि ब्राउज़र में शामिल होने के बाद उसकी ज़िम्मेदारी कौन लेता है

संक्रमण के कदम और आगे भी संभव भागीदारी

  • अभी खुले सभी public pull request बंद किए जाएंगे; मौजूदा queue बनाए रखने का मतलब व्यवहार में public contribution path को खुला रखना होगा, इसलिए बदलाव अभी किया जा रहा है
  • आगे से pull request केवल project maintainers के लिए उपलब्ध होंगे
  • issues, comments, email, या forks के माध्यम से अलग patch submission process नहीं बनाया जाएगा, और fork या patch dump को upstream Ladybird की review queue नहीं माना जाएगा
  • license conditions के अनुसार external code मौजूद हो सकता है
  • Ladybird open source बना रहेगा, और source code open source license के अनुसार सार्वजनिक रूप से उपलब्ध रहेगा
  • बाहरी भागीदारी स्पष्ट bug reports, reductions, website testing, standards discussion, design discussion, security reports, और technical feedback के ज़रिए project की प्रगति में मदद करेगी
  • वास्तविक उपयोगकर्ताओं के लिए ब्राउज़र जारी करने की तैयारी के इस चरण में development process को भी उसी ज़िम्मेदारी के अनुरूप होना चाहिए

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

2 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • हाल में मैं Godot जैसे बड़े open source प्रोजेक्ट्स के बहुत से PR देख रहा हूँ, और code व description दोनों पूरी तरह AI से बने PR काफ़ी बढ़ गए हैं
    प्रोजेक्ट policy के हिसाब से यह मना है, इसलिए आम तौर पर submitter को हल्की चेतावनी मिलती है, लेकिन बहुत से लोग इसे सहजता से मान लेते हैं, जबकि कुछ maintainers के प्रति आभारी न होने पर गुस्सा होते हैं
    ऐसा लगता है कि AI पर पूरी तरह निर्भर लोग भी अभी तक यह बात भीतर से नहीं समझ पाए हैं कि code के ढेर पैदा कर देना अपने आप में कोई मूलभूत मूल्य नहीं रखता
    उन्होंने अपनी मेहनत बहुत कम कर दी है, फिर भी बड़े PR देने पर AI से पहले जैसी प्रतिक्रिया या धन्यवाद की उम्मीद करते हैं

    • AI से पहले की प्रतिक्रिया भी ज़रूरी नहीं कि पूरी तरह उचित थी। बहुत बड़ी मात्रा में हाथ से लिखे गए code commit, जिन्हें maintain करना मुश्किल हो सकता है, अपने आप में कोई सकारात्मक योगदान नहीं होते, और कोई ठीक-ठाक engineer या सामान्य व्यक्ति मेहनत की मात्रा चाहे जो हो, धन्यवाद की उम्मीद नहीं करेगा
      उस संदर्भ में, इस उद्योग में पहले से बहुत ज़्यादा मौजूद बदतमीज़ लोगों के AI के बाद अपना व्यवहार बदल लेने की मुझे उम्मीद नहीं है
      वैसे, मेरे workplace में non-technical staff ने मेरे managed internal repository पर AI-generated PR भेजने शुरू किए हैं, और उनकी quality शानदार है, वे review feedback भी अच्छी तरह लेते हैं और जल्दी लागू करते हैं। समस्या non-technical होने की नहीं, बल्कि रवैये की है
    • कुछ vibe coding करने वालों में एक तरह का हक़दारी का भाव साफ़ दिखता है। शायद यही सही शब्द नहीं, लेकिन यह output से चिपके रहने और यह स्वीकार न कर पाने जैसा है कि ज़्यादातर काम उनका अपना नहीं था
      यह सिर्फ़ contribution के तरीके में नहीं, उनकी रोज़मर्रा की भाषा में भी दिखता है। जैसे “मैंने X बनाया”, अपनी “curation” के असर को बहुत बड़ा बताने की ज़िद, LLM के योगदान की बात करने में असहजता, “मैं बनाने पर ध्यान देता हूँ और बाकी लोग details में समय बर्बाद करते हैं” वाला रवैया, और संभावित खामियों का सामना करने से इनकार
      यह उन senior developers से चौंकाने लायक रूप से अलग है, जो हमेशा शक करते रहते हैं कि उनका बनाया हुआ नतीजा खामियों से भरा और जल्दबाज़ी में किया हुआ हो सकता है। यह impostor syndrome के उलट जैसा लगता है
    • अगर किसी प्रोजेक्ट ने AI-generated PR स्वीकार न करने का नियम बनाया है, तो उस प्रोजेक्ट में कभी भी AI-generated PR नहीं भेजना चाहिए। यह spam है। AI से जुड़े नियम अगर और सूक्ष्म तरीके से तय किए गए हों, तब भी उनका सम्मान होना चाहिए
      इस तरह के PR भेजने वालों की गलती 100% है। अगर किसी का इतिहास प्रोजेक्ट के नियम तोड़ने में बेझिझक और यहाँ तक कि अहंकारी रहा है, तो उस व्यक्ति की profile देखने वाले संभावित employer या भविष्य के collaborator के लिए यह बहुत बड़ा red flag होना चाहिए
      समझ नहीं आता कि कोई अपनी reputation जानबूझकर क्यों खराब करेगा। बुरे व्यवहार का रिकॉर्ड छोड़ने से profile पर कोई activity न होना कहीं बेहतर है
    • यह हैरानी की बात क्यों होनी चाहिए कि जो लोग बिना मेहनत नतीजे चाहते हैं, वे बिना सोचे-समझे यह भी महसूस करते हैं कि वे धन्यवाद के हक़दार हैं
    • ऐसे मामलों में लगता है LLM उस “contributor” से यह कह रहा होगा कि वह कितना smart है और प्रोजेक्ट कितना बड़ा नुक़सान उठा रहा है
      उदाहरण के लिए, “यह प्रोजेक्ट की सीमाओं की रक्षा करने या code quality सुनिश्चित करने के लिए नहीं है। यह तो बस traditionalists द्वारा बनाया गया gatekeeping mechanism है, जो AI की efficiency पर सचमुच mastery रखने वाले आपके जैसे भविष्य-दृष्टि वाले creator से ख़तरा महसूस करते हैं” जैसी बात हो सकती है

  • “बड़े patch का मतलब बड़ी मेहनत हुआ करता था, और वह मेहनत सद्भावना का एक उचित प्रतिनिधि संकेतक थी। अब यह धारणा लागू नहीं होती।”
    मुझे लगता है यही पंक्ति लेख का सार है, और ज़्यादातर प्रोजेक्ट्स पर लागू होती है

    • इसे सामान्य रूप से कहें तो, हम तेज़ी से यह खोज रहे हैं कि AI, चाहे prose हो या code या कुछ और, लेखक और पाठक के बीच के सामाजिक अनुबंध को तोड़ देता है
    • सहमत। मुझे लगता है Ladybird यहाँ जो कर रहा है, वह आगे चलकर open source का सामान्य सामाजिक मॉडल बन सकता है
      फिर भी, यह परखने का कोई तंत्र चाहिए कि कोई व्यक्ति लंबे समय तक पर्याप्त समर्पण दिखाकर maintainer बन सकता है या नहीं। source contribution अब उस संकेत के रूप में भरोसेमंद नहीं रही, और आगे कौन-सा संकेत इस्तेमाल होगा, यह मुझे नहीं पता। यह काफ़ी कठिन समस्या होगी
      लेकिन अगर AI सचमुच programmer productivity को तेज़ी से बढ़ा दे, तो सफल open source projects को शायद maintainers की बड़ी टीम की ज़रूरत ही न पड़े
    • सही है। बहुत अच्छी तरह लिखा गया है और सटीक भी है। मैंने PR spam को इस नज़रिए से कभी नहीं सोचा था, लेकिन वास्तव में यह काफ़ी प्रभावी तर्क है

  • एक तरफ़, अगर आप bazaar में पले-बढ़े हों, तो cathedral की ओर जाना “open source की मौत” जैसा लग सकता है। जबकि वास्तव में यह शायद सिर्फ़ काम करने के एक पुराने तरीके की ओर वापसी हो
    दूसरी तरफ़, अगर बाहरी code contribution नहीं लिए जाएँगे, तो security posture निश्चित रूप से बेहतर होगी, लेकिन यह पता लगाना और कठिन हो जाएगा कि किसे पुरोहित वर्ग में आमंत्रित किया जाए

    • open source development आधुनिक social network की विशेषताओं के अनुसार लगातार अधिक सतही होता गया है। contribution के वास्तविक मूल्य या प्रोजेक्ट के मूल्य से ज़्यादा, contribution record, active commit history, और stars जैसी pixelated reputation के सबूत ज़्यादा महत्वपूर्ण हो गए हैं
      GitHub के उभरने से पहले open source projects मज़बूत बाड़ों वाले बगीचों जैसे थे। वे छोटे clubs जैसे थे जहाँ कमरे में घुसते ही लोग आपको गौर से देखते थे। GitHub ने संपर्क को commodity बना दिया और contribution से पहले लगने वाली मेहनत या रुचि की बाधा को कम कर दिया
      अब वह दौर ख़त्म हो चुका है, और किसी भी चीज़ में योगदान देने से पहले पहले भरोसा बनाना होगा
      यह open source की मौत नहीं है, बल्कि उस global village की मौत है जहाँ हर कोई आज़ादी से घूम सकता था और आसानी से interact कर सकता था। यह छोटे, सामाजिक और trust-based समुदायों का पुनर्जागरण है, और काश यह रुझान पूरे internet में फैल जाए
    • मैं अब भी इस बात का आदी नहीं हो पाया हूँ कि coders की एक पूरी पीढ़ी ऐसी है जिसने वह दुनिया कभी देखी ही नहीं जहाँ “सब कुछ” open source था और bazaar शैली में develop होता था
      क्या आज के लोग उस रूपक या Raymond की किताब को जानते भी हैं? यह ऐसी दुनिया है जहाँ Microsoft एक बड़ा open source provider है और उस platform को चलाता है जो धरती पर अधिकांश open source programming को संभव बनाता है। ज़रा 90 के दशक के आख़िर से आए किसी time traveler को यह समझाकर देखिए
      और जैसा sibling comment ने संकेत किया, Linux kernel जैसा आदर्श “bazaar” भी आज GitHub के असीमित अराजक मॉडल की तुलना में काफ़ी cathedral जैसा दिखता है
    • इस घोषणा का असली मतलब यह है कि AI की वजह से बाहरी contribution, पुरोहित वर्ग में किसे बुलाना है यह पहचानने के संकेत के रूप में, लगभग पहले ही बेकार हो चुकी है
    • SQLite और उससे जुड़े प्रोजेक्ट्स (Fossil आदि) को देखें तो cathedral शैली में भी बहुत अच्छे open source projects सफलतापूर्वक चल सकते हैं
      इसलिए मुझे Ladybird का फ़ैसला समस्या नहीं लगता। बल्कि यह software development के मानवीय पहलू को मज़बूत करने और AI free-riders पर ब्रेक लगाने वाला फ़ैसला लगता है
    • कोई व्यक्ति प्रोजेक्ट को fork करे और अपने patch उस fork में डाले, तो कैसा रहेगा। अगर वह fork सफल हो जाए और वास्तविक users उसे सक्रिय रूप से इस्तेमाल करें, तो upstream ज़रूरी patch चुनकर वापस ले सकता है। fork maintainer को भी अंततः मान्यता मिल जाएगी
      आदर्श तो नहीं है, लेकिन reputation बनाने में समय लगना स्वाभाविक ही है

  • इसे देखकर लगता है कि काश AI बिल्कुल होता ही नहीं
    यह बहुत निराशाजनक है कि open source projects नए maintainers ढूंढने और उन्हें mentor करने की क्षमता खो रहे हैं

    • उन्होंने अपने प्रोजेक्ट के बड़े बदलाव को LLM से फिर से लिखवाया
    • यह सच में AI से कितना जुड़ा है, पता नहीं। open source और maintainer की समस्याएँ बहुत लंबे समय से रही हैं

  • “किसी भी माध्यम से patch submit करने की कोई प्रक्रिया नहीं होगी” और “बाहरी भागीदारी अब भी महत्वपूर्ण है: स्पष्ट bug reports”
    तो bug ढूंढ और ठीक कर सकते हो, लेकिन उसे ठीक कैसे किया, यह ठीक-ठीक बता नहीं सकते?
    उसके बजाय टीम को फिर से खुद पता लगाना होगा। जो काम कोई और पहले ही बार-बार कर चुका है, उसे फिर से करना टीम के लिए सच में बड़ा मज़ेदार होगा
    एक user और developer के तौर पर, मैं ऐसी परियोजना पर समय क्यों लगाऊँ जो ऐसे software पर दीवार खड़ी करती है जो मेरी ज़िंदगी बेहतर बना सकता है? Firefox या Chromium का इस्तेमाल करना कहीं आसान लगता है, जहाँ मेरी fixes वास्तव में स्वीकार की जा सकती हैं
    पहले जब एक नए Chromium version की वजह से मेरे product में crash हो रहा था, तब मैं V8 के लिए एक fix propose कर सका था, और वह अगले Chromium release में शामिल हो गया, जिससे product फिर से चलने लगा — यह बहुत उपयोगी था(https://github.com/v8/v8/commit/4f8a70adca01c)
    अगर ऐसा channel नहीं होता, तो हो सकता है Chromium developers के पास समय की कमी के कारण root cause पता करने और उसे ठीक करने का मौका ही न होता
    “PR अब submitter के बारे में पहले जितनी जानकारी नहीं देते” — लेकिन PR भेजने वाले के बारे में किसी को जानने की ज़रूरत ही नहीं होनी चाहिए
    मैं चाहता हूँ कि Firefox या Chromium में जाने वाला code submitter की “मेहनत” या “अच्छी नीयत” पर नहीं, बल्कि review में verified code की correctness के आधार पर तय हो
    code change की review करना, उसे खुद सोच निकालने की तुलना में साफ़ तौर पर आसान है। अगर ऐसा नहीं है, तो फिर सीधे खुद code लिख देना ही काफ़ी है
    project के नज़रिए से वे कभी भी किसी अनचाहे PR को ignore या close कर सकते हैं। लेकिन external contributions की review करने, या उन्हें अपनी rewrite के input के रूप में इस्तेमाल करने के विकल्प को ही बंद कर देना समझदारी नहीं लगता

    • समस्या की सही जगह पहचान लेना, code से कहीं ज़्यादा मूल्यवान है। अगर तुमने fix code लिखा है, तो तुम bug का analysis पहले ही कर चुके हो। असली value fix code में नहीं, analysis में है
      उस बारीक analysis को share करना ही contribution को अधिकतम करने का तरीका है। code ज़्यादा से ज़्यादा एक वैकल्पिक bonus जैसा है
    • PR code review कोई बिना मेहनत का काम नहीं है। अगर किसी project पर 3 लोग काम कर रहे हों और हज़ारों लोग bug-fix PR भेज दें, तो वे fixes कितनी भी उपयोगी हों, वे 3 लोग सिर्फ PR की संख्या से ही पूरी तरह दब जाएँगे
      तुम्हारी bug fix में value हो सकती है, लेकिन हो सकता है वह value उसे review करके merge करने की cost से ज़्यादा न हो
      “code change की review करना, उसे खुद बनाने से साफ़ तौर पर आसान है” — इतना कहना पर्याप्त रूप से complex projects में पूरी तरह ग़लत है। fix एक line की हो सकती है, लेकिन उसका असर बहुत दूर तक जा सकता है
      एक user और developer के तौर पर अगर तुम ऐसे rules वाले project पर समय नहीं लगाना चाहते, तो मत लगाओ। तुम project पर कुछ बकाया नहीं हो, और project भी तुम पर कुछ बकाया नहीं है। बात इतनी ही simple है
      Firefox और Chromium बहुत बड़ी teams के साथ चलाए जाते हैं, Linux kernel की तो बात ही अलग है। शायद उनके पास तुम्हारे contribution को स्वीकार करने की क्षमता हो
    • “submitter के बारे में जानने की ज़रूरत नहीं, review में सिर्फ code की correctness देखनी चाहिए, और code change की review करना उसे खुद बनाने से आसान है” — तुम इसे तथ्य की तरह कह रहे हो, लेकिन यह open source maintainers के वास्तविक अनुभव के बिल्कुल उलट है
      सिर्फ मेरे अनुभव और मूल लेख के उदाहरण ही नहीं, बल्कि ऐसे ही लेख साझा करने वाले अनगिनत maintainers के अनुभव भी यही कहते हैं
      क्या तुम ऐसे open source projects के links साझा कर सकते हो जिन्हें तुमने वर्षों तक maintain किया हो और जहाँ contributions review किए हों, ताकि इस मुद्दे पर तुम्हारी विशेषज्ञता का आधार समझ में आए?
    • तुम अब भी यह बता सकते हो कि तुमने कैसे किया। बस code या patch के रूप में नहीं
      maintainer समाधान के approach को समझ सके, इसके लिए उसे natural language explanation में लिख दो
    • “यह मेरे लिए बहुत उपयोगी था” — यही असली बात है। तुम चाहते हो कि दूसरे लोग तुम्हारी ज़रूरतें पूरी करने के लिए बदलें
      उनकी priorities और needs अलग हैं। इस मामले में उन्होंने आकलन किया और तय किया कि यह उपयोगी नहीं है। यानी cost, benefit से ज़्यादा थी

  • कम से कम एक महत्वपूर्ण मायने में यह दिलचस्प है कि Chromium/Gecko/WebKit अब Ladybird से ज़्यादा “open” browser engines जैसे लगते हैं
    Servo को बीच का मामला कहा जा सकता है, क्योंकि वह AI का इस्तेमाल न करने पर बाहरी contributions स्वीकार करता है
    यह समझ में आता है कि कम funding वाली team labor cost बचाने के लिए contributions बंद कर दे। लेकिन यह भी लगता है कि लोग Google/Mozilla/Apple द्वारा openness संभव बनाने के लिए लगाए जाने वाले आर्थिक संसाधनों को पर्याप्त मान्यता नहीं देते
    अपनी personal bias और अनुभव साफ़ कर दूँ: अब मैं retired हूँ, लेकिन पहले Google में Chrome पर काम करता था। मैंने कई सहकर्मियों को external contributors को बढ़ते हुए देखा, और मैंने खुद भी अनौपचारिक रूप से या internship जैसे programs के ज़रिए कुछ ऐसा किया था

    • वे कंपनियाँ यह goodwill में नहीं करतीं। वे अपने business value की रक्षा के लिए control सुनिश्चित करना चाहती हैं। अगर economics खत्म हो जाए, तो वे कल ही यह बंद कर देंगी
      मुझे नहीं लगता कि monopoly बनाने के लिए हमें उन्हें हमेशा धन्यवाद देते रहना चाहिए
    • Chrome, Google का loss leader है

  • यह समझा जा सकता है कि वे ऐसा फ़ैसला क्यों ले रहे हैं। अगर ज़्यादातर pull request AI से लिखे गए code हैं, तो maintainer भी सीधे Claude Code में prompt डाल सकता है
    चाहे open source हो या नहीं, मुझे लगता है कि software engineering का पूरा खेल ही पूरी तरह बदल गया है। code का कोई टुकड़ा अब 2 साल पहले जैसा अर्थ नहीं रखता या वैसा संकेत नहीं देता

    • मुझे लगता है कि यही मूल बात है
      कुछ साल पहले अगर मैं कोई जटिल PR भेजता था जो compile हो जाता था और test pass कर लेता था, तो इसका मतलब होता था कि मैंने उसमें उतना समय और cognitive investment लगाया है। अगर मैंने codebase, feature या bug को समझा नहीं होता, तो शायद ऐसा investment नहीं किया होता
      अब उस समझ को हासिल करने की लागत ज़्यादातर पहले जैसी ही है, लेकिन AI ने ऐसा code बनाने की लागत बहुत कम कर दी है जो compile हो जाए और test pass कर ले
      अच्छे इरादे वाले community members खुशी-खुशी सस्ती चीज़, यानी Claude Code tokens, contribute करते हैं, लेकिन अब वह इतनी सस्ती हो गई है कि यह इस बात का अच्छा संकेतक नहीं रह गई कि उन्होंने महंगी चीज़, यानी मानवीय समझ, contribute की है
    • मैं अक्सर “AI-generated code की कोई value नहीं” जैसी बात देखता हूँ। यह सही है कि शून्य value वाला code बनाना आसान हो गया है, लेकिन मैं इस बात से सहमत नहीं हूँ कि AI-generated हर code की value शून्य है
      मैं OpenCode के साथ side project पर काम कर रहा हूँ, और prompt लिखने, सही files सेट करने, और जिस product व roadmap को बनाना है उसे समझाने में काफ़ी समय लगाता हूँ
      फिर मैं बदलावों के बाद बहुत-सी automated checks चला सकूँ, इसके लिए एक कसा हुआ verification loop बनाता हूँ, और generated feature जिन edge cases को बिगाड़ सकता है उन्हें हाथ से काफ़ी test करने के बाद दोहराता हूँ। यह अलग तरह का काम है, लेकिन हाथ से coding करने की तुलना में मैं ज़्यादा तेज़ी से आगे बढ़ पाता हूँ। मुख्य घटक verification loop है
      पिछले कुछ महीनों के अनुभव से, AI के साथ coding करना भी एक skill है, और कोशिश करते-करते नई techniques सीखते हैं और बेहतर होते जाते हैं। इसका मतलब यह भी है कि अगर ठीक से किया जाए तो valuable results बनाए जा सकते हैं
      इसलिए पहले वाक्य से मुझे असहमति है, लेकिन दूसरे वाक्य से मैं पूरी तरह सहमत हूँ। हमने जिस चीज़ को खोया है, वह है गहराई से सोचे गए नतीजों और बिना सोचे generate किए गए नतीजों में आसानी से फ़र्क करने की क्षमता। यहाँ सस्ती verification पर ध्यान देना बहुत मददगार होगा
    • अब code काम का मुख्य effort नहीं रहा। जब हर कोई implementation generate कर सकता है, तब किसी code change के पीछे के क्या, क्यों, और कैसे को पहले से कहीं ज़्यादा गंभीरता से लेना तर्कसंगत है
      मुझे लगता है कि हर project इसी दिशा में जाएगा। साथ मिलकर plan को refine करना ज़्यादा समझदारी की बात लगती है
    • जैसा कहा गया, बेहतर होगा कि सीधे prompt ही भेज दिया जाए

  • जब AI पहली बार आया था, तो मुझे डर था कि कहीं एक दिन मेरी नौकरी न चली जाए। मैं भाग्यशाली रहा, लेकिन बहुत से लोगों ने सच में नौकरी खोई, और वह बहुत तकलीफ़देह था
    जब automation की वजह से कोई कुछ खोता है, तो आर्थिक तर्क से परे भी मन चाहता है कि इंसानों का पक्ष लिया जाए, या कम-से-कम समाज उन लोगों के प्रति निष्पक्ष बना रहे जिन पर सबसे ज़्यादा असर पड़ता है
    अब मैं देख रहा हूँ कि communities प्रभावित हो रही हैं। PR को ख़त्म कर देने से सिर्फ़ code contribution ही नहीं, बल्कि ideas, code पर ज़्यादा नज़रें, और ऐसे अदृश्य contributions भी बुरी तरह हिल जाते हैं। यह मुझे कहीं ज़्यादा बुरा लगता है
    मैं conflicted, confused और डरा हुआ हूँ। फिर भी Claude, DeepSeek, तरह-तरह की technologies, जटिल harnesses और MCP वगैरह इस्तेमाल कर रहा हूँ। लेकिन अभी यह सब एक transition जैसा लगता है। बस समझ नहीं आता कि किस चीज़ की ओर transition है
    बहुत से सवालों के जवाब तब तक नहीं मिल सकते जब तक हम जीवन को कोई अर्थ न दें। मानवीय स्पर्श? क्या अब बहुत देर हो चुकी है? और, मुझे एक गाना पसंद आया था, फिर पता चला कि वह Suno था। यह जानने के बाद मैंने like हटा दिया। मुझे ख़ुद पर बहुत बार बेवकूफ़ी महसूस होती है
    बिखरी हुई बातों के लिए माफ़ी। मुझे Ladybird पसंद है, और मेरे laptop पर उसका sticker भी लगा है। उम्मीद है यह अच्छा करे

    • “यह सब एक transition जैसा लगता है। आखिर किस चीज़ की ओर transition?” इस बात से मैं सहमत हूँ
      ऐसा लगता है जैसे हम किसी tornado के बीच में खड़े हों। फिर भी screen बंद करके, desk पर बैठकर, शांति से first principles को याद करते हुए धीरे-धीरे सोचना मदद करता है
      Obama की बात उधार लें तो, “reality catches up eventually”
      बातें बहुत हैं, लेकिन iOS हर साल 10 साल के बराबर features और fixes नहीं दे रहा। सचमुच कोई भी ऐसा नहीं कर पा रहा, बल्कि लोग उल्टा existing features के टूटने की शिकायत कर रहे हैं। इसलिए यह सच नहीं हो सकता कि हम 10x productivity तक पहुँच गए हैं, और यह तथ्य आख़िरकार हमारे सामने आ ही जाएगा
      हमें इंसानों की तरह सोचना चाहिए। यह भी याद रखना चाहिए कि बहुत से लोग इसमें भावनात्मक रूप से invested हैं। juniors चाहते हैं कि यह उनके लिए उस market में चमकने का मौका बने जिसने उन्हें ठुकरा दिया। CEOs ने AI पर दांव लगाया है और पीछे नहीं हटना चाहते। seniors यह संकेत देना चाहते हैं कि वे बेकार नहीं हुए हैं। AI companies इस discourse को दूषित करेंगी। लेकिन यह धुआँ आख़िरकार छँट जाएगा
    • इस तरह के “contributions” थोड़ी मात्रा में थे, लेकिन ज़्यादातर वे वास्तव में कही गई बातों से अलग निकले
      आम तौर पर वे अनचाही राय, hostile takeover की कोशिशें, value extraction, सामान्य drama, और बस code बनाने के काम पर चढ़ने वाले कुल operational burden में बदल गए
      यह हमेशा ऐसा नहीं था, लेकिन GitHub-style मुक्त open source development model और हर friction को हटाने की प्रवृत्ति ने साफ़ तौर पर एक नया default बना दिया
      वह model शुरू से ही unsustainable था, लेकिन burnout की रफ़्तार इतनी कम थी कि थके हुए लोगों की जगह और लोगों को लाकर उसे चलाया जा सकता था
      AI ने burnout की रफ़्तार को replacement की रफ़्तार से ऊपर पहुँचा दिया है। इसलिए बहुत संभव है कि और projects यह रुख़, या इससे मिलता-जुलता रुख़, अपनाएँ
    • किसी चीज़ को लेकर परस्पर-विरोधी भावनाएँ रखना बिल्कुल सामान्य है, और इसका मतलब तुरंत कोई समस्या होना नहीं है। यह बहुत मानवीय बात है, और मैं भी कुछ ऐसा ही महसूस करता हूँ
      मैं creator भी हूँ और programmer भी, और कुछ communities में जो हो रहा है वह देखना मुझे पसंद नहीं, फिर भी development के लिए agents का इस्तेमाल करता हूँ। जैसे Google और Stack Overflow के पहली बार आने पर उनसे बचना मुश्किल था, वैसे ही LLMs के साथ भी शायद एक साफ़ पहले और बाद का क्षण है
      मेरे पास जोड़ने के लिए कोई ख़ास उपयोगी बात नहीं है, लेकिन इतना कहना चाहता हूँ कि इस तरह के conflict को महसूस करने वाले आप अकेले नहीं हैं। नई चीज़ें अक्सर ऐसी ही होती हैं। कुछ क्षेत्रों में वे बहुत बड़ा फ़ायदा देती हैं, लेकिन दूसरी जगहों पर मानवीयता को जैसे उधेड़ देती हैं; कुछ लोग उनसे दिखावा और कचरा बनाते हैं, जबकि कुछ लोग नई क्षमता पाकर उससे बेहतर चीज़ें बनाते हैं। दुर्भाग्य से, शायद कोई सार्वभौमिक सत्य नहीं है
    • आप कभी भी रुक सकते हैं। दुखद वास्तविकता यह है कि जब नुकसान किसी और को हो रहा होता है, तो बहुत से लोग ज़्यादा परवाह नहीं करते, लेकिन अगर अब यह उन चीज़ों को नष्ट कर रहा है जिन्हें आप निजी तौर पर मूल्यवान मानते हैं, तो फिर आप इसे नैतिक या आर्थिक रूप से समर्थन देना क्यों जारी रखें?
    • यह बात भी मन को शांत नहीं करती कि proprietary LLMs का इस्तेमाल और समर्थन करना आख़िरकार सिर्फ़ OpenAI/Anthropic/Google आदि को और अमीर बनाता है। मैं उस इस्तेमाल को उचित नहीं ठहरा सकता

  • यह पढ़कर एक अजीब-सा असर रह गया। वजह यह है कि लेखक अक्सर 1,000 लाइनों से बड़े, गैर-तुच्छ PR बनाता है, और कभी-कभी एक ही दिन में कई PR बनाकर बिना review के उसी दिन merge भी कर देता है
    LLM पहलू को अलग रखकर भी बात ऐसी ही है। उनमें से कितने प्रतिशत में मदद ली गई, यह नहीं पता, लेकिन मान लें 0% भी हो, तब भी यह ऐसी development speed नहीं है जिसमें मैं सहज महसूस करूँ

    • यह यहाँ कही गई बात से पूरी तरह मेल खाता है
      “मुद्दा यह नहीं है कि कोड हाथ से टाइप किया गया था या नहीं। महत्वपूर्ण बात यह है कि कोड browser में जाने के बाद उसकी ज़िम्मेदारी कौन लेता है। Ladybird अब वास्तविक users के लिए browser बनता जा रहा है। जो व्यक्ति किसी बदलाव को शामिल करता है, वही यह तय कर रहा होता है कि वह बदलाव project का हिस्सा है, और उसी को उसके परिणामों के लिए जवाबदेह होना चाहिए.”
    • इस तरह काम करने वाले कुछ open source project maintainers पर से मेरा भरोसा उठ गया है
      एक open source platform है जिसे हमारी कंपनी कई वर्षों से इस्तेमाल कर रही है, और हम उसका paid Enterprise version उपयोग करते हैं। उस platform में एक काफ़ी विचित्र security flaw आ गया, और जाँचने पर साफ़ दिखा कि AI ने project पर क़ब्ज़ा कर लिया था
      यह स्पष्ट रूप से लिखा हो या न हो, सिर्फ commit log देखकर ही इसकी मात्रा और आवृत्ति से बात साफ़ हो जाती है। बहुत निराशा हुई
    • उसका Github page [1] भी कुछ हद तक यही दिखाता है। commit 83%, PR 14%, review 2%, issue 1% हैं। यह साफ़ तौर पर नियंत्रण से बाहर है
      [1] https://github.com/awesomekling

  • LLM Ladybird के इस फ़ैसले की एक वजह हो सकता है, लेकिन यह एकमात्र संभव वजह नहीं है। उदाहरण के लिए SQLite लगभग शुरुआत से ही काफ़ी हद तक इसी तरह विकसित किया जाता रहा है
    लगता है हर किसी का अपना तरीका होता है

    • अगर मुझे सही याद है, तो Lua भी कुछ ऐसा ही है। यह open source है, लेकिन open development नहीं है
      यह MIT license के तहत है और maintainers bug reports के लिए हमेशा आभारी रहते हैं, लेकिन project का सारा code सिर्फ 3 लोगों ने लिखा है
    • मुझे समझ नहीं आता कि इसमें इतनी बड़ी बात क्या है। कुछ बेहतरीन software बहुत छोटे लेकिन समर्पित समूहों द्वारा बनाए और maintain किए जाते हैं
      अपने समय और project की रक्षा के लिए यह पूरी तरह तर्कसंगत कदम है
 
GN⁺ 4 시간 전
Lobste.rs की राय

  • आजकल clang में contribution review करना बहुत ही दयनीय काम हो गया है। बेहिसाब घटिया PR आते रहते हैं, लोग अब उसके साफ़-साफ़ निशान बेहतर छिपाने लगे हैं, लेकिन ज़्यादातर मामलों में फिर भी पहचान में आ जाता है, और उसे छाँटने में समय लगता है
    कुछ लोग AI इस्तेमाल करने की बात मानते हैं और यह भी लिखते हैं कि कैसे इस्तेमाल किया, लेकिन तब भी यह दोबारा परखना पड़ता है कि वह सच कह रहे हैं या इस्तेमाल को कम बताकर खराब PR पास करवाने की कोशिश कर रहे हैं
    अब तक मैंने ऐसे बहुत सारे PR देखे हैं, लेकिन vibe coding PR में से एक भी सचमुच अच्छा नहीं लगा। कुछ बस “ठीक-ठाक” स्तर के होते हैं और लेखक खुद काम शुरू भी कर देता है, लेकिन ज़्यादातर गायब हो जाते हैं, और बाकी में तो clang के अंदरूनी ज्ञान के बिना भी यह साफ़ दिखता है कि बुनियादी coding concepts तक पूरी तरह गलत हैं
    और भी बुरा तब होता है जब fuzzer→bug→LLM→PR pipeline को automate करने वाली script हो, जो असली bug को गंभीर रूप से गलत समझती है, टूटी हुई तरह से उसे “fix” करती है, और खराब tests जोड़ देती है या मूल failing case तक शामिल नहीं करती
    नतीजा यह होता है कि नए contributors पर समय लगाकर उनकी क्षमता बढ़ाने की इच्छा भी कम हो जाती है। जब कोई अनजान नाम crash fix PR भेजता है, तो पहले यही शक होता है कि यह समय की बर्बादी है या सच में कोई ऐसा contributor है जो आगे चलकर काम आएगा
    जो लोग बस project पर कचरा फेंकते हैं, उन्हें न contribution में दिलचस्पी होती है न सीखने में, और ज़्यादातर तो बस resume में “clang में contribution” जैसी कोई लाइन जोड़ना चाहते हैं

    • D वेबसाइट पर merged PRs से अपने-आप बनने वाली contributors list है, और एक बार कोई beginner chat में आकर पूछने लगा कि वह list कैसे update होती है, फिर उसने एक मामूली PR भेजा और उसे merge करने के लिए जोर डालने लगा
      उसके बाद भी वह आता रहा और पूछता रहा, “list update क्यों नहीं हुई? मेरा नाम अभी तक क्यों नहीं आया?” और वेबसाइट update होने के बाद वह गायब हो गया
      लेकिन सच कहूँ तो मैं भी कम उम्र में कुछ ऐसा ही मूर्ख था। कभी मैंने एक मशहूर open source व्यक्ति की वेबसाइट का mirror बना लिया था क्योंकि कहा गया था कि उसे mirror किया जा सकता है, और फिर उसे list में जोड़ने के लिए mail भी भेजा था, और 1337 hax0r बनने के चक्कर में nmap development mailing list subscribe की थी, हालांकि मैंने कभी कोई patch नहीं भेजा था

  • समस्या की परिभाषा सबके लिए स्पष्ट है। दशकों से open source projects ने code contribution के ज़रिए यह सीखा है कि किस पर भरोसा किया जाए, और लोग काम करते थे, बदलावों की ज़िम्मेदारी लेते थे और बने रहते थे, इसलिए भरोसा काम से ही पैदा होता था
    लेकिन मुझे यह समाधान Zig project के LLM contributions ban की तुलना में और भी सख्त तथा बदतर version लगता है
    जैसे-जैसे AI tools economics को तेज़ी से बदल रहे हैं, अब PR पहले जितना submitter के बारे में नहीं बताता। पहले बड़े patch का मतलब बड़ा effort होता था और वह good faith का proxy signal था, लेकिन अब वह धारणा लागू नहीं होती
    चिंता की बात यह है कि open source अपने आप में कठिन business है और उसे अपने कीमती फायदों का पूरा उपयोग करना चाहिए, जबकि contributors असल में लगभग मुफ़्त में बहुत बड़ा value लेकर आते हैं (contributor poker), और hiring pipeline के रूप में भी बहुत महत्वपूर्ण हैं। ऐसे में यह सब पूरी तरह ठुकरा देना पागलपन जैसा लगता है
    कोई यह दलील दे सकता है कि LLM उस खाली जगह को भर सकते हैं, लेकिन पहली बात, केवल untrusted contributors के PR में LLM उपयोग पर रोक लगाई जा सकती थी; और दूसरी बात, सबसे अच्छे LLM भी cost करते हैं, token prices बढ़ रही हैं, code को वैसे भी review करना पड़ता है, और अंततः वे codebase के किसी हिस्से की ज़िम्मेदारी लेने वाले trusted core contributor नहीं बन सकते
    PR से आने वाली code inflow को हटा देने पर समय के साथ कुछ ही contributors पूरे code के मालिक बन जाएंगे, और project के लिए license rugpull करना आसान हो जाएगा। अगर copyright ownership अच्छी तरह distributed हो, तो ऐसा करना ज़्यादा मुश्किल होता है
    कुल मिलाकर यह अच्छा नहीं है। यह open source को बेवजह और भी समस्याग्रस्त business model बना रहा है, core contributors की hiring को और कठिन बना रहा है, और code ownership को कुछ लोगों में केंद्रित कर रहा है। यह साफ़ तौर पर disaster की recipe लगती है, इसलिए शक होता है कि यह सिर्फ़ गलती है या Ladybird के sponsors में से कुछ कोई अजीब game खेल रहे हैं

    • निष्पक्ष रूप से देखें तो open source का मतलब ज़रूरी नहीं कि public contributions या community governance भी हो। SQLite ऐसा project है जो third-party contributions बिल्कुल नहीं लेता, और वह काफ़ी अच्छा करता हुआ दिखता है
    • sponsors list देखने पर browser में rugpull से फ़ायदा उठाने वाला कोई group साफ़ नहीं दिखता। कुछ लोग दूसरे तरीकों से problematic लग सकते हैं, लेकिन ऐसा motive नज़र नहीं आता
      असल में इस बदलाव के पीछे क्या है, यह जानने की उत्सुकता है। जो project हर महीने status report की शुरुआत में तरह-तरह के नए contributors की संख्या पर गर्व करता था, उसका अचानक यूँ दिशा बदल लेना बहुत तेज़ मोड़ है। अभी दी गई व्याख्या कम-से-कम अधूरी लगती है
    • मैं SUSE जैसी commercial distribution company में open source के आसपास का काम करता हूँ, और मेरा काम browser, compiler, database को सीधे इस्तेमाल करने से ज़्यादा उनके downstream versions को maintain करना है। मेरी नज़र और सीमाएँ वहीं से आती हैं
      Zig और Ladybird दोनों उस future से आगे बढ़ने का रास्ता खोज रहे हैं जिसे हम नहीं चाहते थे। कई साल तक हमें कुछ पता नहीं था और सच कहूँ तो मुझे नहीं लगा था कि ऐसा future आएगा। अब “सही काम” क्या है, यह बिल्कुल स्पष्ट नहीं है
      Zig से मेरा सवाल यह है कि LLM PR और इंसान द्वारा सीधे बनाए गए PR में फ़र्क कर पाना संभव नहीं है। low-effort garbage को छाना जा सकता है, लेकिन “AI ban” लागू करने के लिए किसी तरह का Turing test पास करना होगा, और मैं तथा Claude Pro license मिलकर उसे आसानी से पास कर सकते हैं
      “AI ban” असल में यह करता है कि अगर कोई LLM code भेजकर उसे manual work बताए और पकड़ा जाए, तो आप उस व्यक्ति और उसकी reputation पर हमला कर सकें। क्या सच में आप अपना समय इसी पर लगाना चाहते हैं? जैसे Karl Jobst जैसा कोई पात्र पैदा हो जाए जो hand-coded होने का नाटक करते हुए LLM इस्तेमाल करने वालों को पकड़ता फिरे
      यह LLM PR को रोक नहीं सकता, बस game को “पकड़ सकते हो तो पकड़ लो” में बदल देता है। Ladybird में Andreas को rugpull के क़रीब फैसला लेते देख पहले मेरी रीढ़ में सिहरन दौड़ी, फिर लगा कि उसमें हिम्मत तो है। LLM assistance और trust सच में बहुत बड़े मुद्दे हैं, इसलिए मैं Zig और Ladybird दोनों को लीक से हटकर सोचते देखना चाहता हूँ
    • Ladybird organization के bylaws (https://ladybird.org/assets/documents/…) देखकर यह जानकर निराशा हुई कि Christopher Wanstrath co-BDFL हैं। पहले मुझे लगा था कि उन्होंने बस 10 लाख डॉलर दान दिए और organization बनाने में मदद की
      हक़ीक़त में वह Designator हैं, और मेरी समझ के अनुसार जब तक वे इस्तीफ़ा न दें या अक्षम न हो जाएँ, यह पद उन्हें जीवनभर के लिए सुरक्षित है। Designator majority vote से फ़ैसले करते हैं, लेकिन जब सिर्फ़ 2 लोग हों तो दोनों की सहमति ज़रूरी होती है, और वही Directors को नियुक्त या हटाते हैं तथा bylaws में बदलाव के लिए भी उनकी सहमति चाहिए
      यानी non-profit organization पर उनके पास व्यावहारिक रूप से unchecked veto power है। Andreas के पास भी वही है, लेकिन Andreas वह व्यक्ति हैं जिन्होंने काम का बड़ा हिस्सा बनाया, project में सक्रिय हैं, और अरबपति नहीं हैं। Wanstrath अरबपति हैं, अपनी संपत्ति का बहुत छोटा हिस्सा दान करने वाले हैं, operation में शामिल नहीं हैं, फिर भी उनके पास वही शक्ति है
      अगर मुझसे कोई अहम कानूनी कारण छूट नहीं रहा, तो यह open source project के लिए अच्छी governance structure नहीं लगती

  • मुझे चिंता है कि जिन projects ने हाल में contributions बंद किए हैं, वे लंबी अवधि में कैसे चलेंगे। किसी समय trusted core people में से कुछ लोग चले जाएँगे, और अगर लंबे समय से परखे हुए contributors नहीं होंगे, तो स्पष्ट successors भी नहीं मिलेंगे
    डिफ़ॉल्ट रास्ता burnout और abandoned project की ओर जा सकता है, इसलिए उम्मीद है कि वे इसे पार करने का कोई तरीका खोजेंगे

    • उम्मीद है कि LLM craze स्थिर होगा या ठंडा पड़ेगा, या दूसरे projects “contribution” की बाढ़ को sustainable तरीके से संभालने का रास्ता निकालेंगे। इसलिए मुझे लगता है कि यह अस्थायी होगा। लेख की tone भी यह संकेत देती है कि stable release के बाद भी इसे हमेशा ऐसे ही बनाए रखने का इरादा नहीं है

  • मैं इसे किसी भी तरह की leadership नहीं मानता। यह सही दिशा में उठाया गया कदम नहीं है, न ही साथ मिलकर जीने का कोई विचार
    मैं मानता हूँ कि दबाव असली है, लेकिन प्रतिक्रिया ऊर्जा और उम्मीद से भरी होने के बजाय cynical और defeatist लगती है, जो निराशाजनक है

    • जानना चाहूँगा कि आपको यह सही दिशा क्यों नहीं लगती

  • “इस बदलाव के हिस्से के रूप में हम अभी खुले हुए सभी public pull request बंद कर देंगे” वाला हिस्सा चौंकाने वाला है
    कुछ साल पहले एक project ने यह कहकर मेरा PR बंद कर दिया था कि उसके पास PR review करने के resources नहीं हैं, और यह काफ़ी चोट पहुँचाने वाला था तथा उस PR पर मेहनत करने वाले contributor के साथ न्यायसंगत नहीं लगा

    • बुरा लगना स्वाभाविक है, लेकिन अगर maintainer ने वास्तव में वह PR लिखने के लिए नहीं कहा था, तो उसे अन्यायपूर्ण कहना मुश्किल है
    • बिना माँगे किए गए काम की review की उम्मीद करना अपने आप में उचित नहीं है

  • दिए गए कारण समझ में आते हैं, लेकिन यह फ़ैसला चिंताजनक लगता है। यह ज़रूरी नहीं कि यह निश्चित रूप से बुरा ही हो, और अगर यह अस्थायी हो तथा बाद में कोई दूसरा समझौता-बिंदु मिल जाए तो ठीक भी हो सकता है, फिर भी चिंता बनी रहती है
    यह पहला चेतावनी संकेत भी नहीं है। LLM-सहायित Rust पुनर्लेखन को लेकर भी ऐसा ही लगा था। Bun के विपरीत, यह अपेक्षाकृत सावधानी से किया गया था—review किए जा सकने वाले आकार के components, स्पष्ट input-output, और existing components के साथ parallel execution के ज़रिए mismatch पकड़ने का तरीका। फिर भी, browser engine में मैं यह तरीका नहीं देखना चाहूँगा
    उम्मीद है Ladybird सफल हो। मैं चाहता हूँ कि कोई नया browser engine इस oligopoly को चुनौती दे। लेकिन अगर Ladybird रास्ते से भटक जाए, तो यह भी सुकून की बात है कि कई सालों तक ठहरा हुआ Servo अब अच्छी प्रगति कर रहा है

    • मैं Servo का समर्थन करता हूँ। Ladybird को कौन चला रहा है, और उसके विचार क्या हैं, यह याद करूँ तो, भले ही वह सफल हो जाए, मैं नहीं चाहूँगा कि मेरे machine के सबसे महत्वपूर्ण applications में से एक के पीछे ऐसे लोग हों। कम-से-कम अभी ऐसी policy मौजूद है

  • Rust implementation में AI कचरा कोड का इस्तेमाल, और DHH का समर्थन करने वाला पक्ष—यानी श्वेत वर्चस्ववाद और anti-LGBT पक्ष की ओर झुकाव—और ऊपर से काफ़ी आक्रामक रवैया। नहीं लगता यह project बहुत दूर तक जाएगा

  • अगर बाहर से contributor बनने के लिए कोई entry path नहीं है, तो लगता है बहुत कुछ छूट जाएगा। चाहे इसके लिए बस आते-जाते PR फेंक देने से ज़्यादा गंभीर commitment की ज़रूरत क्यों न हो
    ऐसा करने से, जब वे developers जोड़ना चाहेंगे, तो codebase को जानने वाले लोगों का talent pool बड़ा होगा, और core team जिन ज़रूरतों को priority नहीं देती, उन्हें बाहरी organizations पूरा कर सकती हैं। इससे adoption में भी मदद मिलेगी और काम का बोझ भी घटेगा

  • इस पोस्ट पर vibecoding टैग लगाना सही नहीं लगता। vibecoding के पीड़ितों को उस व्यवहार का प्रचार करने वालों के साथ एक ही tag में रखना बुनियादी तौर पर अजीब है

    • सिर्फ़ इस पोस्ट को देखें तो संदर्भ गायब है, लेकिन हाल की दूसरी पोस्टें और पृष्ठभूमि पढ़ें तो PR बंद करने की वजह vibecoding PRs का फैलना भी है, और साथ ही वे ख़ुद भी मुख्य रूप से vibecoding की ओर शिफ्ट कर रहे हैं। हाल की C++ से Rust vibecoding porting भी देखने लायक है