Pull Request मर चुका है, Pull Request अमर रहे

• AI के कोड लिखने के दौर में Pull Request (PR) review तरीक़े को बुनियादी रूप से बदलना होगा, और मौजूदा review process AI coding workflow के लिए उपयुक्त नहीं है
• जब reviewer पूछता है, "ऐसा क्यों किया?", तो developer AI से फिर से पूछकर जवाब copy-paste कर देता है, जिससे इंसान सिर्फ़ middleman बनकर रह जाता है और inefficiency पैदा होती है
• AI के decision log को code के साथ source control में शामिल किया जाना चाहिए, ताकि reviewer सीधे context देख सके
• ऐसा workflow, जिसमें reviewer comments सीधे AI प्राप्त करे और patch व response अपने-आप generate करे, GitHub/GitLab webhook और MCP server के संयोजन से पहले से संभव है
• design documents और architecture diagrams को भी Markdown या Mermaid जैसे LLM-parsable format में source control में शामिल करना चाहिए, क्योंकि "Context is king"

---

AI युग में code review की समस्याएँ

• PR review के दौरान सवाल पूछने पर अक्सर ऐसा जवाब मिलता है जो AI-generated लगता है, क्योंकि वास्तव में code AI ने ही लिखा होता है
• "यह library क्यों चुनी गई?" जैसे सवाल का जवाब human developer नहीं दे पाता, और AI से दोबारा पूछकर उसका जवाब copy करके भेजता है
• AI से पहले हम developer (code writer) से सीधे पूछते थे, उसके manager से नहीं; इसलिए middleman को हटाना चाहिए
• code के हर लेखक को review में शामिल होना चाहिए, और review सवालों के जवाब में कोई अलग AI agent बाद में कारणों का reverse inference करे, यह पूरी तरह ग़लत तरीका है

decision log की ज़रूरत

• जब हम इंसान से "क्यों?" पूछते हैं, तो हम PR में शामिल न होने वाली आंतरिक सोच प्रक्रिया के बारे में पूछ रहे होते हैं
• AI का chain-of-thought externally auditable हो सकता है, और AI के साथ interaction record भी auditable होता है, इसलिए इस context को review और source control में शामिल करना चाहिए
• PR बनाते समय generated हर token को commit करना ज़रूरी नहीं; Random Labs के episodes concept से प्रेरित होकर केवल सफल tool calls और conclusions की transcript शामिल की जा सकती है
  • यह agent swarm environment में भी scalable है, और PR से पहले के चरण में decision logs को जोड़कर अंतिम formatting की जा सकती है

inline comments की सीमाएँ

• source files में बदलाव होने पर, सिर्फ़ comments बदलने से भी build pipeline को फिर से चलाना पड़ता है (linting, compile, test)
• decision transcript का आकार सामान्य inline comments में अनुमत सीमा से काफ़ी बड़ा होता है
• मौजूदा comments यह बताते हैं कि code अभी कैसे काम करता है, लेकिन उस निर्णय तक पहुँचने की प्रक्रिया नहीं बताते

AI-integrated review workflow

• reviewer के comment करते ही developer का AI उसे सीधे प्राप्त कर patch और response अपने-आप generate कर सके, ऐसा होना चाहिए
  • GitHub/GitLab webhook और MCP server के संयोजन से यह अभी भी लागू किया जा सकता है
  • Devin AI या Claude Code via GitLab Duo जैसी शैली में
• इसे इस तरह configure किया जा सकता है कि developer पहले AI को अनुमति दे, या AI ख़ुद निर्णय लेकर तुरंत कार्रवाई करे
• human developer भी अब भी अपने स्तर पर comments और changes कर सकता है
• review comments के कई घंटे या कई दिनों बाद लागू होने, या कभी लागू ही न होने की समस्या को काफ़ी हद तक कम किया जा सकता है

reviewer के लिए tool requirements

• reviewer को भी PR को वैसे ही AI से सीधे सवाल पूछते हुए review कर पाना चाहिए जैसे वह codebase explore करता है
• इस उद्देश्य के लिए decision logs का code के साथ check-in होना बेहद महत्वपूर्ण है
• मौजूदा PR interface को वैसा ही रखते हुए, उसके बगल में Codex या Claude से बात करने वाली एक window IDE development environment की तरह integrated होनी चाहिए
  • अभी ऐसा कोई साफ़-सुथरा tool नहीं है, इसलिए अच्छा होगा अगर कोई इसे बनाए
• diff में अनजान libraries, अपरिचित language, या best practices पर AI से private Q&A करने के बाद reviewer तय कर सके कि code review comment ज़रूरी है या नहीं
• अगर comment ज़रूरी है, तो यह इस बात का संकेत है कि decision log में कोई gap है, इसलिए PR approve करने से पहले log update किया जाना चाहिए

design documents और context का महत्व

• AI-integrated review में reviewer के लिए सीधे patch suggest करना भी बहुत आसान हो जाता है
• design documents, decision records, और architecture diagrams को Markdown या Mermaid जैसे LLM-parsable format में source control में जोड़ना चाहिए
• "Context is king"

[tomskang]

मुझे लगता है कि PR के मरने की वजह PR खुद से ज़्यादा Vibe coder लोगों की ढीली-ढाली communication है।

किस flow से implement किया, और कौन-कौन से दूसरे तरीके थे और उन्हें क्यों नहीं चुना, package.lock को क्यों बदलना पड़ा—क्या ये सब बातें पहले से बताई जानी चाहिए थीं, नहीं?
PR Description में लिख देना काफ़ी था, लेकिन बेवजह लोगों से पूछवाने वाले coders के खत्म होने को ही ज़्यादा बेहतर मानूँगा।

[cafedead]

मैं सहमत हूँ। पहले PR में यह एहसास होता था कि मैंने जो बनाया है उसकी ज़िम्मेदारी मेरी है,
लेकिन Vibe coder का PR कुछ ऐसा लगता है, "मुझे यह भी नहीं पता कि मैंने क्या बनाया है, फिर भी किसी तरह एक नतीजा तो है, इसलिए तुम इसका मूल्यांकन करके इसमें समस्याएँ ढूँढो।"

[shakespeares]

सहमत हूँ।
पहले बात कर लेनी चाहिए, लेकिन बाद में ज़िम्मेदारी न लेने वाले रूप में यह आगे बढ़ रहा है।

[moregeek]

सहमत हूँ। यह इतना परेशान करने वाला है कि झुंझलाहट होने लगती है।

[shlee1503]

सहमत हूँ।

[bus710]

एक PR में 500 फाइलें बदल जाती हैं, लेकिन सबमिट करने वाला इस बात से बहुत नाराज़ है कि 30 मिनट के अंदर रिव्यू नहीं हुआ। विवरण में भी बस पाँच-छह लाइनें लिखकर काम खत्म, तो क्या बस इसी पर भरोसा करके approve कर दूँ...?

टेस्ट सब कर लिए न?
हाँ
ठीक है, अच्छा काम करो

[moregeek]

क्या-क्या बार-बार मरा हुआ बता रहे हैं

[kandk]

ऐसा करते-करते सब मर जाएँगे!

[redmi]

ज़रा-सी बात पर "मर गया" वाले शीर्षक के लेख बहुत ज़्यादा हो गए हैं
तो लगता है कि यह काफ़ी थकाने वाला हो गया है

मुझे भी लगता है कि अब इन्हें मारना बंद कर देना चाहिए

[xguru]

"मर गया; ज़िंदाबाद"

इस तरह के लेख वाकई बहुत ज़्यादा हो गए हैं। लेकिन यह मानना पड़ेगा कि AI सब कुछ बदल रहा है।