- 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"
अभी कोई टिप्पणी नहीं है.