Zig एआई प्रतिबंध: LLM उत्पादकता से अधिक समीक्षक का भरोसा

एक पुल रिक्वेस्ट कभी सिर्फ पुल रिक्वेस्ट नहीं होती। यह मेंटेनर्स को भेजा गया एक छोटा-सा बिल होता है, जिसका भुगतान ध्यान, संदर्भ, और रात के खाने के बाद के उन शापित छोटे घंटों में किया जाता है जब ओपन सोर्स सच में होता है। Zig ने ऐसे बिलों की एक श्रेणी पर चमकदार लाल “नहीं” की मुहर लगा दी है: बड़े भाषा मॉडल की मदद से किए गए योगदान बाहर हैं। यह Zig प्रोजेक्ट को AI और ML बिल्डर्स के लिए एक उपयोगी केस स्टडी बनाता है, क्योंकि बहस असल में इस बारे में नहीं है कि कोड असिस्टेंट कोड बना सकते हैं या नहीं। जाहिर है, वे बना सकते हैं। इंटर्न भी बना सकते हैं, Stack Overflow की पुरातत्व खुदाई भी, और एयरपोर्ट कॉफी के सहारे जागता हुआ नींद से वंचित स्टाफ इंजीनियर भी। सवाल यह है कि नतीजे की जाँच की कीमत कौन चुकाता है।

साइमन विलिसन और बिज़नेस इनसाइडर के अनुसार, प्रतिबंध कोड से भी व्यापक है साइमन

विलिसन Zig को बड़े ओपन सोर्स प्रोजेक्ट्स में सबसे सख्त anti-LLM नीतियों में से एक वाला बताते हैं, और प्रोजेक्ट की भाषा सीधे उद्धृत करते हैं: "No LLMs for issues." वे यह भी उद्धृत करते हैं, "No LLMs for pull requests." विलिसन के उद्धरण के अनुसार, वही नीति भाषा बग ट्रैकर टिप्पणियों को भी कवर करती है, जिसमें अनुवाद भी शामिल है, जबकि योगदानकर्ताओं को अपनी मातृभाषा में पोस्ट करने और ज़रूरत पड़ने पर दूसरों को अनुवाद टूल इस्तेमाल करने देने के लिए प्रोत्साहित करती है। बिज़नेस इनसाइडर रिपोर्ट करता है कि Zig योगदानकर्ताओं को कोड लिखने, डिबग करने या विचार-मंथन के लिए AI इस्तेमाल करने से रोकता है, और उसके शीर्षक में Zig अध्यक्ष एंड्रयू केली का यह कथन उद्धृत है कि AI कोडिंग योगदान "invariably garbage" हैं। मसालेदार उद्धरण क्लिक खींचता है, क्योंकि ज़ाहिर है ऐसा ही होता है, लेकिन तंत्र मसाले से ज़्यादा महत्वपूर्ण है। Zig provenance यानी उत्पत्ति को reviewability यानी समीक्षा-योग्यता का हिस्सा मान रहा है: अगर मेंटेनर्स को भरोसा नहीं है कि कोई artifact कैसे बनाया गया, तो वे उसे सुलझाने में अपना दुर्लभ समीक्षा समय खर्च न करने का चुनाव कर सकते हैं। Let’s Data Science जोड़ता है कि नियम कोड, संपादन, अनुवाद, विचार-मंथन, बग ढूँढने, और यहाँ तक कि प्रोजेक्ट स्पेसेज़ में LLM उपयोग का उल्लेख करने तक को कवर करता है। AI Weekly भी कहता है कि प्रतिबंध LLM से छुए गए artifacts को कवर करता है, जिनमें issues, comments, और pull requests शामिल हैं। दूसरे शब्दों में, Zig सिर्फ यह नहीं कह रहा कि कृपया चैटबॉट कोड compiler में पेस्ट न करें। यह कह रहा है कि प्रोजेक्ट का संचार चैनल खुद एक source quality requirement रखता है, जो governance है, बस compiler वाली hoodie पहने हुए।

Loris Cro और Let’s Data Science के अनुसार, reviewer bandwidth ही दुर्लभ संसाधन

Loris Cro, Zig Software Foundation के अनुभव से लिखते हुए, ओपन सोर्स योगदानों को उपहार टोकरी के बजाय एक लेन-देन के रूप में देखते हैं। वे तर्क देते हैं कि pull requests खुद अतिरिक्त श्रम और friction बन सकती हैं, और यह आम है कि कोई maintainer किसी बदलाव को सीधे लागू करने में submitted patch की समीक्षा करने से कम मेहनत लगाए। यही वह हिस्सा है जिसे कई AI coding debates शालीनता से किनारे कर देती हैं, जैसे Roomba किसी मोज़े से बचता है। Let’s Data Science रिपोर्ट करता है कि जब नीति स्पष्ट की गई, तब Zig के पास लगभग 200 open pull requests और एक छोटा core reviewer group था। यह संदर्भ प्रतिबंध को aesthetic purity कम और queue management ज़्यादा बनाता है। अगर किसी project के पास पहले से trusted reviewer supply से अधिक review demand है, तो generated submissions इंसानों के लिए synthetic load testing जैसा व्यवहार कर सकती हैं, बस फर्क यह है कि किसी ने capacity plan दाखिल नहीं किया। AI Weekly कहता है कि Kelley ने नीति को resource triage के रूप में पेश किया, AI submissions की negative review value का हवाला देते हुए। यही phrase यहाँ load-bearing beam है। Generated patch contributor के लिए local रूप से सस्ती और maintainers के लिए global रूप से महंगी हो सकती है, जो मूल रूप से tragedy of the commons है, लेकिन autocomplete और ज्यादा YAML के साथ।

AI Weekly और Simon Willison के अनुसार, Bun upstream जोखिम दिखाता है

AI Weekly रिपोर्ट करता है कि Anthropic के स्वामित्व वाले Bun ने, जो AI-assisted workflows पर निर्भर करता है, upstream changes न करा पाने के बाद Zig को fork किया। Simon Willison भी नोट करते हैं कि Bun Zig का अपना fork चलाता है और कहते हैं कि Bun को दिसंबर 2025 में Anthropic ने acquire किया था। ओपन सोर्स foundations पर commercial products बनाने वाली teams के लिए, यही governance lesson है जिसमें सचमुच दाँत हैं। सामान्य enterprise fantasy यह होती है कि upstream एक दोस्ताना conveyor belt है: improvements contribute करो, उन्हें merge करा लो, divergence घटाओ, और conference hallway में सब high-five करें। Zig की नीति एक अलग failure mode दिखाती है। अगर आपका engineering workflow AI assistance पर निर्भर करता है और कोई upstream project LLM-authored contributions को reject करता है, तो आपको fork बनाए रखना पड़ सकता है, काम को manually rewrite करना पड़ सकता है, या contributions तैयार करने का तरीका बदलना पड़ सकता है। इसका मतलब यह नहीं कि Zig किसी cosmic sense में anti-productivity है। इसका मतलब है कि Zig contributor throughput के बजाय maintainer trust के लिए optimize कर रहा है। ये दोनों वास्तविक values हैं, और यह दिखावा करना कि इनमें कभी conflict नहीं होता, आपको geological formation जैसी backlog तक पहुँचा देता है।

Research Information के अनुसार, यह Zig से बड़ा मामला है

Research Information रिपोर्ट करता है कि arXiv ने authors को चेतावनी दी कि unchecked large language model output के स्पष्ट evidence वाले काम के लिए उन्हें एक साल का submission ban मिल सकता है। यह compiler pull requests वाला वही domain नहीं है, लेकिन pattern ज़ोर से तुक मिलाता है। Institutions vibes-based AI etiquette से explicit responsibility rules की ओर बढ़ रहे हैं। AI builders के लिए practical takeaway घबराना या पूर्णिमा की रात ritual chatbot banishment करना नहीं है। यह है contribution workflows को ऐसा design करना कि review सस्ती हो: जहाँ अनुमति हो वहाँ tool use disclose करें, patches छोटे रखें, tests दें, intent समझाएँ, और हर line की ownership लेने को तैयार रहें, जैसे कोई stochastic parrot उसे अस्तित्व में फुसफुसाकर न लाया हो। अगर कोई project LLM assistance पर प्रतिबंध लगाता है, तो उस boundary का सम्मान करें या कहीं और contribute करें। अगली देखने वाली बात यह है कि क्या और open source projects Zig की bright line को copy करते हैं या disclosure और verification के आसपास softer rules चुनते हैं। किसी भी तरह, AI coding tools demo stage छोड़कर governance spreadsheet में प्रवेश कर रहे हैं। पता चला कि generated code का सबसे कठिन हिस्सा अब भी वे इंसान हैं जिन्हें उस पर विश्वास करना होता है।