कोड समीक्षा में (स्वचालित) पहचान से कहीं अधिक कुछ है
AI‑generated code और automated reviewers के उभार के बीच, engineer फिर से यह सोच रहे हैं कि code review का असल उद्देश्य क्या है। कई लोग कहते हैं कि bots और linters syntax issues, basic bugs, और style violations पकड़ सकते हैं, लेकिन architecture, business fit, long-term maintainability, और team के भीतर knowledge sharing जैसी उच्च-स्तरीय चिंताओं में वे कमजोर हैं। दूसरी ओर, कुछ का तर्क है कि AI‑accelerated output के साथ human review का scale होना मुश्किल है और इसे मजबूत automated testing, design reviews, तथा system understanding बाँटने की नई प्रक्रियाओं से पूरक या प्रतिस्थापित करना होगा.
कोड समीक्षा का उद्देश्य और मूल्य
- इसे बग ढूँढ़ने से कहीं अधिक माना जाता है: ज्ञान का हस्तांतरण, साझा सिस्टम-समझ, आर्किटेक्चर की रक्षा, टेस्ट और डिप्लॉयमेंट योजनाओं का सत्यापन, और यहाँ तक कि कानूनी/संगठनात्मक “due diligence” भी।
- कुछ लोगों का तर्क है कि PRs वह अंतिम, महत्वपूर्ण गेट हैं जहाँ आर्किटेक्चरल गलतियाँ, गलतफहमियाँ, और टेक्निकल डेट अभी भी रोकी जा सकती हैं।
- अन्य लोग कहते हैं कि अगर बड़ी समस्याएँ नियमित रूप से PR के समय पकड़ी जा रही हैं, तो पहले के चरण (डिज़ाइन, standups, pairing, requirements review) विफल हो रहे हैं।
स्टाइल संबंधी नुक्ताचीनी बनाम ऑटोमेशन
- शिकायतें कि वरिष्ठ reviewer अक्सर सिर्फ फ़ॉर्मैटिंग और विराम-चिह्नों पर टिप्पणी करते हैं।
- स्वचालित linters/formatters और एक बार का style-guide निर्णय, ताकि bikeshedding खत्म हो सके, के लिए मज़बूत समर्थन।
- स्टाइल पर अंतहीन चर्चा से बचने के लिए bottom-up consensus बनाम top‑down enforcement पर बहस।
कोड समीक्षा में इंसान बनाम AI
- कई लोग मानते हैं कि LLMs स्थानीय चिंताओं पर ठीक काम करते हैं: syntax, सरल बग, performance hints, tests, और style।
- व्यापक रूप से मानी गई कमजोरियाँ:
- आर्किटेक्चरल fit और मौजूदा patterns का पुनः उपयोग।
- “मेटा” मुद्दे जैसे maintainability, project conventions, और repo organization।
- business logic, acceptance criteria, और “क्या हमें यह feature सच में चाहिए?”
- overengineering और बड़े, review न किए जा सकने वाले AI‑generated blobs को पहचानना और कम करना।
- कुछ लोग AI review tools को “अब पर्याप्त अच्छे” बताते हैं, जो अधिकांश human review की जगह ले सकते हैं; अन्य लोगों को लोकप्रिय tools सतही, noisy, और अविश्वसनीय लगते हैं।
टीमों और प्रक्रिया पर AI का प्रभाव
- चिंता कि AI का भारी उपयोग developers की गहरी समझ को कम करता है, जिससे cost/benefit estimation और सुरक्षित बदलाव करना कठिन हो जाता है।
- एक संगठन ने एक “crisis” का वर्णन किया जहाँ किसी को code बदलना सुरक्षित महसूस नहीं हो रहा था; उन्होंने सख्त human code review, WIP limits, और दो‑human signoff को अनिवार्य रूप से फिर लागू किया।
- निराशा कि human feedback अक्सर बस agents में वापस फीड कर दिया जाता है, जिससे लगता है कि tools को प्रशिक्षित किया जा रहा है, लोगों को नहीं।
कोड समीक्षा का भविष्य
- कुछ लोग भविष्यवाणी करते हैं कि non‑critical code के लिए human review अधिकतर गायब हो जाएगा; human ध्यान design reviews और governance पर स्थानांतरित होगा।
- अन्य लोग तर्क देते हैं कि AI‑generated code को AI गति से gate करने के लिए human review पर निर्भर रहना असंभव है; इसके बजाय AI‑driven testing, meta‑checks, और यहाँ तक कि full subsystem regeneration की माँग करते हैं।
- विपरीत दृष्टिकोण: मौजूदा AI output अक्सर गड़बड़, duplicate, और architecture को नुकसान पहुँचाने वाला होता है; human review को छोड़ना लापरवाह tech‑debt accumulation माना जाता है।