Zig प्रोजेक्ट की anti-AI contribution policy के पीछे का तर्क
(simonwillison.net)- Zig issues, Pull Requests, bug tracker comments और translations में LLM के उपयोग पर सख्त रोक लगाता है
- अंग्रेज़ी का उपयोग केवल recommendation है, अनिवार्य नहीं; contributor अपनी मातृभाषा में लिख सकते हैं और दूसरे लोग अपनी पसंद के translation tools से उसे समझ सकते हैं
- Bun ने अपने Zig fork में LLVM backend के लिए parallel semantic analysis और multiple codegen units जोड़कर Bun compilation में 4x performance improvement हासिल किया, लेकिन LLM-लिखित contributions पर रोक के कारण फिलहाल इसे upstream करने की योजना नहीं है
- Zig का review model अधूरे PR को खारिज करने के बजाय नए contributors को merge करने योग्य काम तक पहुँचने में मदद करता है, और individual contribution से ज़्यादा contributor growth को महत्व देता है
- ज़्यादातर LLM द्वारा लिखे गए PR review time को reliable नए contributors बढ़ाने में उपयोगी नहीं रहने देते, और maintainer के पास वही समस्या सीधे LLM चलाकर हल करने का विकल्प भी होता है
Policy और Bun fork का टकराव
- Zig ने Code of Conduct में issues, Pull Requests, bug tracker comments और translations में LLM के उपयोग पर रोक साफ़ तौर पर लिखी है
- अंग्रेज़ी का उपयोग recommendation है, और contributor अपनी मातृभाषा में लिख सकते हैं
- दूसरे लोग अपनी पसंद के translation tools से उसे समझ सकते हैं
- Zig में लिखे गए प्रमुख प्रोजेक्ट्स में Bun JavaScript runtime शामिल है, और Bun का 2025 के दिसंबर में Anthropic द्वारा अधिग्रहण हुआ
- Bun अपना अलग Zig fork चलाता है, और LLVM backend में “parallel semantic analysis and multiple codegen units” जोड़कर Bun compilation में 4x performance improvement हासिल की
- संबंधित code oven-sh/zig compare link पर सार्वजनिक है
- Bun की फिलहाल इसे upstream करने की योजना नहीं है क्योंकि Zig LLM-लिखित contributions पर सख्ती से रोक लगाता है
- Zig core contributor के अनुसार यह patch LLM मुद्दे से अलग भी स्वीकार किया जाना मुश्किल है
- parallel semantic analysis लंबे समय से planned feature है, लेकिन इसका असर खुद Zig language पर पड़ता है
Contributor Poker और contributor-केंद्रित review
- Contributor Poker and Zig's AI Ban में contributor poker Zig की सख्त रोक को समझने के लिए एक अहम रूपक है
- सफल open source projects उस चरण में पहुँचते हैं जहाँ उन्हें संभाली जा सकने वाली मात्रा से अधिक PR मिलते हैं
- ROI को अधिकतम करने के लिए Zig अधूरे PR को ठुकराने के बजाय नए contributors को उनके काम को mergeable बनाने में मदद करना चुनता है
- इस approach को सिर्फ “सही काम” नहीं बल्कि “स्मार्ट काम” भी माना जाता है
- Zig individual contributions से ज़्यादा contributors को महत्व देता है
- PR review और acceptance का प्राथमिक लक्ष्य नया code जोड़ना नहीं, बल्कि ऐसे लोगों को मदद देना है जो समय के साथ reliable और productive contributors बन सकते हैं
- हर contributor, Zig core team के लिए investment का विषय बनता है
- LLM support इस structure को तोड़ देता है
- भले ही LLM एक perfect PR लिखने में मदद करे, Zig team का review पर लगाया गया समय नए, आत्मविश्वासी और reliable contributors बढ़ाने में योगदान नहीं देता
- “contributor poker” यह रूपक है कि खेल cards नहीं बल्कि लोगों को देखकर खेला जाता है
- इसका मतलब पहले PR की सामग्री से अधिक contributor पर दांव लगाना है
- अगर PR का अधिकांश हिस्सा LLM ने लिखा हो, तो project maintainer के पास उस PR को review और discuss करने के बजाय सीधे LLM चलाकर वही समस्या हल करने का विकल्प होता है
2 टिप्पणियां
समस्या यह है कि bottleneck इंसान हैं। लगातार आने वाले बेकार PRs को रोकते-रोकते review करना पड़े, तो Zig development ही नहीं हो पाएगा, इसलिए पहले से ही एक प्राथमिक फ़िल्टर वाली policy रखी गई है।
Hacker News की राय
https://kristoff.it/blog/contributor-poker-and-ai/ के अनुसार, LLM-आधारित योगदान ज़्यादातर नकारात्मक रहे
बेकार drive-by PR ने hallucinated code के साथ बैकग्राउंड शोर बढ़ाया, वे compile भी नहीं होते थे या CI पास नहीं करते थे, और कभी-कभी पहली बार योगदान देने वाला व्यक्ति 10,000-line PR तक भेज देता था
कुछ PR ऊपर-ऊपर से ठीक लगते थे और यह भी साफ़ लिखा होता था कि LLM का इस्तेमाल नहीं हुआ, लेकिन आगे की चर्चा में तुरंत पता चल जाता था कि लेखक ने चुपके से LLM का सहारा लिया था और बार-बार ग़लतियों से भरे जवाब दे रहा था
hooks को clone पर अनिवार्य रूप से install कराने का कोई साफ़ तरीका नहीं है, लेकिन GHA Workflows या दूसरे forge में उसका समकक्ष फीचर हो सकता है
किसी भी ऐसे प्रोजेक्ट के लिए जिसकी कुछ स्केल और लोकप्रियता हो, यह बुनियादी आवश्यकता होनी चाहिए
“AI योगदान नहीं कर सकता” वाली समस्या का बड़ा हिस्सा बेहतर automatic checks और guardrails से कुछ हद तक कम किया जा सकता है
AI ने इस नए तरह के spam को संभव बनाया है, बस इतना छोड़ दें तो इसका मूल AI नहीं है
AI न भी हो, अगर लोग सस्ते offshore developers की फ़ौज रखकर मध्यम गुणवत्ता वाले drive-by PR बड़ी संख्या में बनवाएँ, तो असर वही होगा
AI से अच्छा code भी बन सकता है, लेकिन बाकी tools की तरह इसका इस्तेमाल भी सावधानी से होना चाहिए
यह किसी ऐसे व्यक्ति का सोच-समझकर किया गया योगदान नहीं है जो प्रोजेक्ट और लक्ष्य को समझता हो; यह spam है
AI policy के आसपास का शोर शायद इस वजह से बढ़ा कि Bun के developers ने कहा कि वे उस policy के कारण performance PR upstream नहीं कर पा रहे
लेकिन असली वजह शायद यह है कि PR का code खुद अच्छी स्थिति में नहीं है और वह unhealthy complexity ला रहा है https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
उद्धृत व्याख्या के अनुसार parallel semantic analysis Zig compiler की बहुत पुरानी स्पष्ट योजना रही है और self-hosted Zig compiler के design पर उसका बड़ा असर रहा है, लेकिन इसे सही तरह लागू करने के लिए सिर्फ compiler implementation ही नहीं बल्कि Zig language में भी बदलाव चाहिए
क्योंकि वह बेहतर नतीजों के लिए Zig के अपने roadmap से टकराता है और पूरे language को लगातार बेहतर बनाने की दिशा में रुकावट बनता है
policy तो साफ़ तौर पर सभी LLM code को मना करती है, इसलिए वही स्वाभाविक रूप से “असली वजह” है
Zig का रुख़ कुछ हद तक ZeroMQ के रास्ते पर चलता दिखता है https://zguide.zeromq.org/docs/chapter6
यानी “प्रोजेक्ट की collective ownership को enforce करके contributors की economic incentive बढ़ाना और hostile actors द्वारा hijack के जोखिम को कम करना”
एक स्वस्थ contributor community सिर्फ code performance, feature count या lines of code से ज़्यादा महत्वपूर्ण है
आज का zeromq “community” काफ़ी विरल है; अभी भी कुछ अच्छे लोग सक्रिय हैं, लेकिन human-level processes और communication channels न तो अच्छी तरह defined हैं और न ही पर्याप्त रूप से चलाए जा रहे हैं
libzmq और ज़्यादातर bindings स्थिर हैं, इसलिए मानवीय गतिविधि और interaction की यह कमी कुछ हद तक स्वीकार्य या उचित लग सकती है, लेकिन Hintjens की शानदार vision ही zeromq को यहाँ तक लाई थी, और उनके बाद प्रोजेक्ट कुछ भटका हुआ लगता है
community-centric vision की विडंबना यह है कि community बनाने और बनाए रखने के लिए शायद करिश्माई और सक्रिय leadership चाहिए होती है, और यह software development से ज़्यादा मानव स्वभाव के बारे में बताता है
Zig पर लौटें तो, Zig के पास PR की कमी नहीं है, इसलिए वह no-LLM contributions को पहले से छाँट सकता है
उनके लिए यह अच्छा विकल्प है, और “contributor poker” का विचार भी समझ में आता है
लेकिन अगर नए contributors की आमद कम हो जाए, तो खेल बदल जाएगा, और उस समय अगर Zig टीम नए contributors चाहती है तो उसे अपना जाल फैलाना पड़ सकता है
हालाँकि ऐसा समय आने तक LLM-assisted contributions खोलना शायद recovery के लिए बहुत देर हो चुकी होगी
AI-generated OSS contributions के बारे में मुझे यह बात उत्सुक करती है
अगर AI सच में developer productivity इतना बढ़ाता है, तो कोई OSS maintainer अपने और LLM के बीच किसी अनजान contributor को क्यों रखना चाहेगा?
maintainer खुद Claude Code से पूछ सकता है
एक सहकर्मी के शब्दों में, “हमें AI model से बात करने के लिए किसी middleman की ज़रूरत नहीं, और coding bottleneck भी नहीं है”
AI से शुरुआती ख़राब version बनवाए, prompts को refine करे, manual fixes करे, दूसरे हिस्से ठीक करवाए, संबंधित features खोजकर जुड़वाए, benchmark चलाए, छोटे features हटाए या दो मिलते-जुलते implementations में से एक चुने
फिर इधर-उधर और manual edits करे, expanded automated tests चलाए ताकि अजीब setups में छिपे bugs मिलें, और AI व manual work से उन्हें ठीक करे
20 घंटे बाद final version शायद सिर्फ 50 lines का हो, लेकिन हर line पाँच बार तक rewrite हुई हो
maintainer को तब सिर्फ final version लगभग 1 घंटे review करना पड़े
यह उस स्थिति से पूरी तरह अलग है जहाँ कोई 5 मिनट AI से patch लिखवाकर, बिना पढ़े, 1000 lines का non-compiling code maintainer को भेज दे
“यह तो इतना आसान है कि मैं भी कर सकता था”
सही है, लेकिन आपने किया नहीं
लेकिन यह ऐसा tool नहीं है जिसे इंसान की तरह सिर्फ high-level निर्देश देकर छोड़ दिया जाए
जो लोग दावा करते हैं कि AI सिर्फ high-level निर्देशों पर काम कर लेता है, शायद वे ऐसे “सोच-विचार रहित” projects पर काम कर रहे हैं जहाँ details में उतरने वाले developer को बहुत गहराई से सोचना नहीं पड़ता
उम्मीद है आपका मतलब यह भी नहीं कि LLM का अकेला फ़ायदा सिर्फ वह code लिख देना है जिसे खुद टाइप करना उबाऊ हो
“Zig, contributions से ज़्यादा contributors को महत्व देता है। PR को review और accept करने का मुख्य उद्देश्य नया code लेना नहीं, बल्कि लोगों को समय के साथ भरोसेमंद और productive contributor बनने में मदद करना है। LLM assistance इसे पूरी तरह तोड़ देती है। भले ही LLM किसी को perfect PR जमा करने में मदद करे, तब भी।” यह अब तक का सबसे अच्छा तर्क लगा
मैं Zig के फ़ैसले का पूरी तरह समर्थन करता हूँ और community व असली project—दोनों के लिए उसकी long-term vision की कद्र करता हूँ
सच कहूँ तो मुझे नहीं लगता कि LLM collaborative work के लिए इतने अच्छे से फिट बैठते हैं
आगे क्या बदलता है, यह देखेंगे, लेकिन AI-generated PR लेने पर अक्सर आख़िर में काम मुझे ही दोबारा करना पड़ता है, और विडंबना यह है कि फिर मैं उसे दोबारा करने के लिए LLM ही इस्तेमाल करता हूँ, जिससे भीतर एक अजीब टकराव महसूस होता है
फिर भी कम-से-कम अगले 5 साल तक Zig की policy मुझे एक अच्छा विचार लगती है
मुझे लगता है यह उनके कहे जा सकने वाले सबसे कम आक्रामक बयानों में से एक है, और अपने प्रोजेक्ट के बारे में उनके फ़ैसले के रूप में इसका सम्मान करता हूँ
फिर भी लगता है कि वे अपने project को अनावश्यक रूप से बाँध रहे हैं
LLM एक tool है, और यह सोचने, research करने और coding करने में मदद कर सकता है
इसका overuse हो सकता है, लेकिन जहाँ यह मददगार हो वहाँ इसे अपनाना चाहिए
Bun के PR को दूसरे कारणों से reject करना बिल्कुल ठीक है, लेकिन हर LLM-written PR को सीधा ban कर देना अनावश्यक रूप से restrictive है
बस काम की quality पर ध्यान दें
अगर maintainer वही काम खुद LLM से करा ले, तो संभव है कि वह बेहतर design और ज़्यादा सावधानी वाले approach के साथ हो
maintainer का समय सिर्फ low-effort PR review में नहीं, development में भी लगना चाहिए
LLM code की बाढ़ ने संतुलन maintainer के ख़िलाफ़ कर दिया है, इसलिए वे बस इसे ban करना चाहते हैं—यह पूरी तरह समझ में आता है
कुछ समय तक LLM और coding agents इस्तेमाल करने के बाद मेरा समग्र impression यह है कि यह power tool या crane की तरह है, decision-making tool की तरह नहीं
जिन लोगों की conceptual understanding और deep engineering understanding मज़बूत है, उनकी productivity संगठन में विस्फोटक रूप से बढ़ जाती है
उल्टा, जिनकी समझ कम है, या जो नए/junior हैं, वे बस कुछ चल गया तो काम पूरा मानकर नरक जैसा code बना रहे हैं
LLM संगठन के भीतर intellectual gap बनाता है, और जितना ज़्यादा इसका उपयोग होता है, यह gap उतना चौड़ा होता जाता है
आगे चलकर generated code की वजह से संगठन के अपने output पर भरोसा करना भी मुश्किल हो सकता है
AI आम तौर पर skillset को amplify करता है—अच्छे और बुरे, दोनों तरीकों से
हाल का एक शानदार उपयोग मामला authentication daemon के concept को लिखना था
Codex से बातचीत करते हुए सुझाव चुने, सामान्य web search से cross-check किया, final draft तय किया, फिर सहकर्मियों के साथ चर्चा की
integrated web search के साथ इस तरह की interactive planning बेहद उपयोगी है, और पहले से लिखे code का AI से review कराना भी मुझे शुद्ध लाभ जैसा लगता है
लेकिन AI की मुख्य caveat यही है कि आख़िरकार आपको tool से ज़्यादा smart होना पड़ेगा
अगर Codex tech stack X सुझाता है, तो आपको जाँचकर पूरी तरह समझना होगा कि वह वास्तव में अच्छा क्यों है और दूसरे समाधानों से उसकी तुलना करनी होगी
बहुत से लोग यह step छोड़ देते हैं, इसलिए ढेर सारी समस्याएँ पैदा होती हैं, और वह घातक है
बातचीत ख़त्म होने तक आपको AI से ज़्यादा समझदार हो जाना चाहिए, और AI ने जो कहा उसे पूरी तरह समझकर उसकी आलोचना कर सकना चाहिए
architecture तय हो जाने के बाद LLM implementation काफ़ी अच्छी तरह कर लेता है
आम तौर पर AI से शानदार और अच्छी तरह tested code बनवाना संभव है, और वही समय अकेले लगाने की तुलना में कहीं बेहतर परिणाम भी मिल सकते हैं
लेकिन AI द्वारा बनाई हर चीज़ की समझ के साथ लगातार कदम मिलाकर चलना अपने-आप में एक चुनौती है
“अगर PR ज़्यादातर LLM ने लिखा है, तो maintainer उस PR को review और discuss करने में समय लगाने के बजाय अपना LLM चालू करके वही समस्या खुद क्यों न हल करे?” यह तर्क open source itself पर भी लागू होता है
जब robot सीधे लिख सकता है, तो किसी और का project इस्तेमाल ही क्यों करें?
ख़ासकर अगर वह open source project खुद vibe coded हो, तब तो और भी
AI और टेक्नोलॉजी कुल मिलाकर personalization को सस्ता और आसान बना रहे हैं
पहले हमें ऐसे mass-produced products लेने पड़ते थे जो सबको बस कुछ हद तक ठीक लगें, लेकिन अब उम्मीद है कि कुछ ऐसा मिल सकता है जो सिर्फ मेरे लिए बेहतरीन हो
साथ ही, जगह-जगह लोग LLM से open source projects को फिर से बना रहे हैं, जिससे श्रम अर्थव्यवस्था भी प्रभावित हो रही है
LLM ऐसी चीज़ें कुछ ही मिनटों में उगल सकता है
मुझे सबसे ज़्यादा चाहिए usage history
मैं ऐसा software इस्तेमाल करना चाहता हूँ जिसे मुझसे पहले दूसरे लोग इस्तेमाल कर चुके हों, और जहाँ bugs व sharp edges उनके इस्तेमाल से पहले ही घिसकर मुलायम हो चुके हों
लोग कहते थे कि अगर घर पर model डाउनलोड करके print कर सकते हैं और अनंत customization कर सकते हैं, तो कोई चीज़ खरीदेगा ही क्यों
सभ्यता का मकसद ही यह है कि हम अपनी ज़िंदगी की ज़्यादातर समस्याएँ किसी और के जिम्मे छोड़ सकें और खुद किसी एक चीज़ में माहिर बन सकें
अगर आप dentist हैं या muffler shop चलाते हैं, तो आपके दिन का समय सीमित है, और शायद आप vibecoding सीखने और किसी अजीब, मेहनत-खोर अधीनस्थ की निगरानी करने से बेहतर SaaS vendor को पैसे देना पसंद करेंगे
अपवाद होते हैं, लेकिन वे अपवाद ही होते हैं
अगर vendor समझदार और सक्षम product बनाता है, तो लोग खुशी से पैसे देंगे
open source पर भी यही लागू होता है
मान लें LLM शुरू से एक नया operating system भरोसेमंद तरीके से बना भी सकता है, तो क्या मैं सच में वह चाहूँगा?
मैं OS maintain नहीं करना चाहता, न ही उस व्यक्ति को manage करना चाहता हूँ जो OS maintain करे, और न ही मुझे लगता है कि मेरे पास शुरू से OS के लिए कोई coherent vision है
एक सीमा के बाद complexity इतनी बढ़ जाती है कि यह उम्मीद करना कठिन है कि कोई robot मेरे मन को काफ़ी पढ़ सके और “सिर्फ मेरे लिए शानदार” high-quality result दे सके
Zig project साफ़ तौर पर ऐसी क्षमता की सीमा से बहुत परे है
कुछ लोग इसकी लागत नहीं उठा सकते, और जिनके पास access है उन्हें भी Claude outages या समय के साथ overall performance गिरने जैसी समस्याएँ अक्सर या लगातार झेलनी पड़ती हैं
कुछ महीने पहले जब मैंने Claude का इस्तेमाल शुरू किया था, तो एक हफ़्ते के भीतर कई projects में आसानी से progress हुई थी, लेकिन आजकल ज़्यादातर समय सिर्फ spinner दिखता है और code quality भी काफ़ी गिरती लगती है, इसलिए लगभग कुछ हो ही नहीं पाता
मेरे पास लगभग 100 stars वाले कुछ repos हैं, बहुत बड़े नहीं, लेकिन पिछले साल तक कभी-कभार PR आते थे; इस साल अब तक लगभग कुछ नहीं
मेरा अनुमान है कि LLM mainstream projects से चिपके रहना पसंद करते हैं
बहुत से developers अब LLM पर बहुत अधिक निर्भर हैं, इसलिए एक bias बन रहा है जो मेरी दी हुई ज़्यादातर चीज़ों को नज़रअंदाज़ करता है
LLM के साथ wheel reinvention बढ़ने की वजह भी यही है कि नई चीज़ बनाने की लागत कम हो गई है
इसलिए GitHub पर किसी obscure चीज़—जैसे मेरी—का इस्तेमाल करने की बजाय ज़रूरत की चीज़ बस generate कर लेना आसान हो गया है
dependency चुनने में भी मैं यही पैटर्न देख रहा हूँ
जब तक बहुत मजबूत वजह न हो, लोग LLM द्वारा सुझाई गई चीज़ें ही चुन लेते हैं
मैं कुछ हद तक सहमत हूँ, लेकिन पूरी तरह नहीं
contributors को विकसित करना सही प्राथमिकता है
लेकिन मैं AI को एक assistive technology की तरह देखता हूँ
कुछ-कुछ screen reader या magnifying glass जैसा, हालाँकि फ़र्क़ भी काफ़ी हैं
इसे robot exoskeleton की तरह भी समझा जा सकता है
इसका इस्तेमाल बुरे और मूर्खतापूर्ण कामों में होगा, लेकिन यह उन लोगों की मदद भी करेगा जो पहले कुछ अच्छा कर ही नहीं सकते थे, या जो इससे ज़्यादा सक्षम बनेंगे
कुछ लोगों के लिए AI वह coding संभव बनाएगा जो वे पहले नहीं कर सकते थे, कई लोगों के लिए यह AI को काम करते देखकर coding सीखने का साधन होगा, और दूसरों के लिए यह उन्हें बहुत तेज़ या बेहतर coder बनाएगा
कुछ लोगों में कुछ skills कमज़ोर हो सकती हैं, लेकिन दूसरी skills मज़बूत भी हो सकती हैं
exoskeleton के साथ भी, अगर कोई ठीक-ठाक product बाज़ार में आए, तो यही समस्याएँ होंगी, लेकिन कुल मिलाकर वह एक enabling tool होगा
मुझे समझ नहीं आता कि assistive technology इस्तेमाल करने वाले contributor को विकसित करना, उसका इस्तेमाल न करने वाले contributor को विकसित करने से क्यों ज़्यादा बुरा होगा
हाँ, यह शायद ज़्यादा कठिन ज़रूर हो सकता है
LLM उतने स्मार्ट नहीं हैं जितना LLM vendors दावा करते हैं
अगर सचमुच होते, तो वे पूरी तरह autonomous होते और हम यह चर्चा ही नहीं कर रहे होते
जो लोग LLM-generated code को अंधाधुंध submit कर देते हैं या उसके इस्तेमाल का खुलासा नहीं करते, उन्हें सच में यह बंद कर देना चाहिए
बाकी समस्या फिर भी यही है कि यह अभी भी एक tool है
किसी भी random developer से कह दीजिए कि “one-shot PR में Zig को तेज़ बना दो”, तो भी अच्छा नतीजा नहीं आएगा
पहले OSS projects में एक तरह का self-selection होता था, क्योंकि working code बनाना आना ज़रूरी था; और उस स्तर तक पहुँचते-पहुँचते लोग सालों की सीख से आम तौर पर सही काम करते थे और features या आवश्यकता के बारे में उनका अपना reasoning भी होता था
आज LLM भले ही perfect हो और अच्छी reasoning करता हो, फिर भी आख़िरकार वह prompter के निर्देश ही पालन करता है
यानी वह self-selection अब ख़त्म हो गया है
Zig developers के लिए यह पहचानना भी मुश्किल होगा कि कौन-सा code वास्तव में LLM ने बनाया और कौन-सा इंसान ने
संभव है कि कुछ LLM-generated code पहले से अंदर आ भी चुका हो, लेकिन कम-से-कम ऐसे human submitter को अभी भी code को काफ़ी अच्छी तरह संभालना आना चाहिए
आख़िर में यह कहाँ जाएगा—“सिर्फ trusted badge of honor वाले humans ही commit कर सकते हैं” तक, या फिर “LLM इतना reasoning करने लगे कि खुद कहे: नहीं, दफ़ा हो। यह feature/plan/idea बेकार है, मैं इसे नहीं बनाऊँगा”—यह देखना दिलचस्प होगा
अगर ऐसा करने पर उन्हें सच में कड़ा नुकसान पहुँचाने का कोई तरीका नहीं है, तो फिर क्या चीज़ उन्हें रोकेगी?