मुझे इतने बड़े PR भेजना बंद करो; एक भड़ास
बड़े, AI-जनित pull requests मानव code reviewers को overwhelm कर रहे हैं और मौजूदा development workflows की सीमाएँ उजागर कर रहे हैं। टिप्पणीकार बहस करते हैं कि क्या सख़्त PR size limits लागू की जाएँ, automated और AI-assisted review पर अधिक निर्भर हुआ जाए, या feature planning को ऐसे नए सिरे से सोचा जाए कि बदलाव छोटे, narrative chunks में आएँ जिन्हें समझना और test करना आसान हो। tooling की इस चर्चा के नीचे accountability, software quality, और large language models को कितनी ज़िम्मेदारी सुरक्षित रूप से दी जा सकती है, इस पर एक गहरी चिंता छिपी है.
AI-जनित बड़े PRs और समीक्षा की बाधा
- कई मेंटेनर्स 1,000–4,000 लाइन वाले PRs से थकान की रिपोर्ट करते हैं, जिन्हें एजेंट “one‑shotted” कर देते हैं; इंसानी समीक्षा बाधा बन जाती है।
- कुछ लोग कहते हैं कि अगर कोई PR इंसानों के लिए समीक्षा करने लायक ही बहुत बड़ा है, तो टीमें अनुमोदन छोड़कर सिर्फ़ CI पर निर्भर होने के लिए ललचा सकती हैं, जिसे दूसरे खतरनाक मानते हैं।
- चिंता यह भी है कि अगर कोई भी कोड को पूरी तरह समीक्षा नहीं कर सकता, तो अब कोई भी सिस्टम को सचमुच समझता नहीं है, जिससे कंपनी का “moat” कमज़ोर पड़ता है।
सीमाएँ, टूलिंग, और वर्कफ़्लो रणनीतियाँ
- सुझाए गए उपाय: CI checks या git hooks जो N लाइनों से बड़े PRs को विनम्र संदेश के साथ अस्वीकार कर दें; दूसरे कहते हैं कि इससे सिर्फ़ समझ से परे काम और खंडित हो जाता है।
- GitHub के stacked PRs, “chaptered” PR review tools, और browser extensions को बड़े बदलावों को अधिक पचने योग्य बनाने के तरीकों के रूप में उद्धृत किया गया है।
- कुछ लोग atomic commits लागू करने या branches को split करने वाले custom “skills” या workflows का वर्णन करते हैं; दूसरों को लगता है कि भारी prompting के बिना LLMs अच्छे git hygiene में हठपूर्वक खराब हैं।
छोटे बनाम बड़े PR की दर्शनशैली
- एक पक्ष छोटे, narrative PRs पर ज़ोर देता है: पहले foundations लाओ, फिर glue, फिर feature; बड़े dumps या एक साथ कई बड़े PRs को अस्वीकार किया जाता है।
- दूसरा पक्ष तर्क देता है कि कुछ features “half‑pregnant” नहीं हो सकते; उन्हें split करना अतिरिक्त, निरर्थक काम है, खासकर जब सब कुछ एक साथ ship होना ही हो।
- विरोधी पक्ष: अधिकांश बड़े features को feature flags या preparatory refactors से staged किया जा सकता है; “अगर इच्छा है, तो रास्ता है।”
टेस्ट और कोड गुणवत्ता की भूमिका
- कई टिप्पणीकार ज़ोर देते हैं कि LLM‑लिखित tests खोखले हो सकते हैं या गलत व्यवहार को spec के रूप में encode कर सकते हैं; tests अक्सर इंसानों द्वारा लिखे जाने चाहिए या कम से कम सावधानी से review किए जाने चाहिए।
- साफ़ commit history और छोटे, focused changes को अच्छी review की core चीज़ें बताया गया है, वैकल्पिक polish नहीं।
समीक्षा और जवाबदेही में इंसान बनाम AI
- कुछ लोग AI reviews को ही scalable रास्ता मानते हैं; आलोचक पूछते हैं कि AI का audit कौन करेगा और चेतावनी देते हैं कि “slop begets slop।”
- एक विपरीत दृष्टिकोण: human reviewers को घटाएँ या हटाएँ और “prompter” की व्यक्तिगत जवाबदेही बढ़ाएँ।
- अन्य लोग मानते हैं कि वास्तविक human review महत्वपूर्ण है, खासकर regulated या safety‑critical contexts में।
संगठनात्मक और OSS गतिशीलताएँ
- OSS में, मेंटेनर्स बड़े/AI PRs को बस बंद कर सकते हैं और अक्सर anonymous AI contributions को पूरी तरह रोकना उचित मानते हैं।
- कंपनियों में, compliance, deadlines, नेतृत्व के रवैये, और reviewer–author power dynamics “बस मना कर दो” को बहुत कठिन बना देते हैं।