AI कोड रिव्यू: क्या लेखक ही रिव्यूअर बन सकता है?

 (greptile.com)
5 पॉइंट द्वारा GN⁺ 2025-05-09 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • AI द्वारा लिखे गए कोड का AI द्वारा रिव्यू किया जाना उचित है या नहीं, यह एक दिलचस्प सवाल है
  • Devin AI जैसे बॉट सबसे ज़्यादा PR लिख रहे हैं, और ऐसे मामलों की संख्या भी बढ़ रही है जहाँ रिव्यू भी AI कर रहा है
  • यह तर्क भी मौजूद है कि LLM stateless होते हैं, और रिव्यू व लेखन के समय उनकी आंतरिक संरचना अलग होती है, इसलिए भूमिकाओं को अलग माना जा सकता है
  • AI से जनरेट हुआ कोड इंसानों से अलग तरह के बग पैदा करता है, और AI उन बग्स को ढूंढने में अधिक प्रभावी है
  • नतीजतन, AI रिव्यू मानव रिव्यू की तुलना में वास्तविक त्रुटि पहचान में अधिक फायदेमंद हो सकता है, लेकिन मानवीय architectural judgment और style guide अब भी महत्वपूर्ण हैं

क्या AI अपने ही कोड का रिव्यू कर सकता है?

  • अधिकांश कंपनियाँ लेखक ≠ रिव्यूअर के सिद्धांत का पालन करती हैं
  • लेकिन AI, LLM-आधारित होने के कारण, stateless है और हर request पर नया निर्णय लेता है
  • यानी, एक ही engine इस्तेमाल होने पर भी लेखन और रिव्यू को दो अलग “cars” की तरह देखा जा सकता है

Scaffolding: AI रिव्यू की संरचना

  • रिव्यू के लिए AI निम्नलिखित विशिष्ट workflow पूरा करता है:
    • code diff का विश्लेषण
    • bug detection
    • comment लिखना और severity तय करना
    • codebase documentation और संबंधित files का संदर्भ लेना
  • दूसरी ओर, code generation AI पूरी तरह अलग context में काम करता है, इसलिए रिव्यू और generation कार्यात्मक रूप से अलग हैं

इंसान भी असल में "एक ही engine" हैं

  • PR लेखक और रिव्यूअर अलग हो सकते हैं, लेकिन दोनों एक ही मानवीय बुद्धि से आते हैं
  • एक ही कंपनी में, एक जैसी training पाने वाले लोग मिलता-जुलता ज्ञान और अनुभव साझा करते हैं
  • आखिरकार, AI और इंसान दोनों ही “same engine, different case” के अर्थ में समान हैं

AI कोड को और अधिक सटीक रिव्यू की ज़रूरत है

  • AI कोड की गुणवत्ता थोड़ी कम होती है

    • AI तेज़ है, लेकिन prompt की सीमाओं के कारण requirements का संप्रेषण सटीक नहीं होता
    • अच्छे developer भी AI कोड को अपने लिखे कोड जितनी बारीकी से रिव्यू नहीं करते
    • नतीजतन कुल गुणवत्ता नीचे की ओर समान हो जाती है, और मध्यम स्तर पर आकर ठहरती है

  • AI बग्स इंसानों के लिए ढूंढना मुश्किल है

    • AI जो बग बनाता है, वे अक्सर उस प्रकार के होते हैं जो इंसान आम तौर पर नहीं बनाते
    • उदाहरण: अनपेक्षित line modifications, conditionals में सूक्ष्म त्रुटियाँ आदि
    • Greptile के internal tests के अनुसार:
      • AI (Sonnet) ने “Hard” bugs के 209 मामलों में से 32 खोजे
      • मानव developers ने औसतन सिर्फ 5~7 ही खोजे

निष्कर्ष

  • AI द्वारा अपने ही कोड का रिव्यू किया जाना तकनीकी रूप से संभव और सार्थक है
  • AI bug detection में इंसानों से बेहतर है, और रिव्यू में वास्तव में उपयोगी है
  • लेकिन मानवीय intent की व्याख्या, design judgment, और code style का आकलन अब भी महत्वपूर्ण है
  • लेखक ≠ रिव्यूअर जैसे पारंपरिक मानदंड को AI के लिए नई तरह से समझने की ज़रूरत है

संबंधित पढ़ाई

3 टिप्पणियां

 
aer0700 2025-05-10

लगता है अलग-अलग LLM models बदल-बदलकर review करना भी दिलचस्प होगा। जैसे A model से लिखा code, B, C, D models से review करवाना।
 
bungker 2025-05-10

अरे, हमारी कंपनी में हम ऐसा करते हैं। Cursor (Claude) से लिखा गया code जब PR के रूप में भेजते हैं, तो उसका review ChatGPT से कराते हैं। फिर कहते हैं, अब आपस में लड़ो। o4-mini के बाद से लोगों की तरफ़ से काफ़ी वाहवाही आ रही है। Cursor में model बदलकर request करने वाले तरीके से इसे सीधे वहीं भी आज़माया जा सकता है।
 
GN⁺ 2025-05-09
Hacker News राय

  • मैं इस हिस्से पर ज़ोर देना चाहता हूँ: इंजीनियर AI द्वारा जनरेट किए गए कोड को उतनी बारीकी से रिव्यू नहीं करते जितना अपने लिखे कोड को करते हैं। वजह यह है कि LLM कोड को टाइपिंग स्पीड से कहीं तेज़ी से बना देता है। इसलिए जब आप खुद कोड लिखते हैं, तो स्वाभाविक रूप से उसे रिव्यू भी करते चलते हैं, लेकिन AI जनरेट करे तो वह प्रक्रिया छूट जाती है। दिलचस्प बात यह है कि औसत इंजीनियर के लिए AI कभी-कभी कोड क्वालिटी बढ़ा भी देता है। जितना ज़्यादा AI का इस्तेमाल होगा, अच्छे और कमज़ोर इंजीनियरों के बनाए कोड का स्तर उतना ही एक-दूसरे के करीब आ सकता है। कोड रिव्यू, डिज़ाइन और लेखन—हर चरण में सोचने का तरीका अलग होता है, और यह हमेशा दिलचस्प लगता है

    • हर व्यक्ति की इंटरैक्शन शैली अलग होती है, इसलिए सबके लिए अलग तरीका बेहतर बैठता है। मुझे कोड लिखने से ज़्यादा उसे रिव्यू करना आसान लगता है। खुद लिखते समय कोडबेस के अलावा बहुत सारा कॉन्टेक्स्ट भी साथ में सोचना पड़ता है, लेकिन रिव्यू करते समय उस कॉन्टेक्स्ट को सिर्फ कोडबेस पर केंद्रित कर सकता हूँ, इसलिए पैटर्न मैचिंग तेज़ हो जाती है। दुर्भाग्य से LLM का स्तर अभी जूनियर इंजीनियर जैसा है, इसलिए PR रिव्यू में ज़्यादा मेहनत और ऊर्जा लगती है

    • अच्छा इंजीनियर होना हमेशा अच्छे कोडर होने के बराबर नहीं होता

  • अगर कोड रिव्यू और कोड लिखने के लिए AI में अलग-अलग bots और prompts इस्तेमाल किए जाएँ, तो बहुत ज़्यादा errors पकड़े जा सकते हैं। एक ही टूल को कई बार चलाने पर भी कभी-कभी नई समस्याएँ मिल जाती हैं। इंसान हो या AI, कोई भी एक बार में परफेक्ट कोड नहीं बनाता। AI टूल अब इतने आगे बढ़ गए हैं कि अपना कोड खुद टेस्ट कर लेते हैं और pre-review भी कर लेते हैं, लेकिन मेरा मानना है कि PR को इंसान और AI दोनों से रिव्यू करवाना कभी नुकसानदेह नहीं होता। मेरे अपने बनाए टूल Kamara ने भी कई बार उसी कोड में समस्याएँ पकड़ी हैं जिसे उसने खुद लिखा था। greptile वाले उदाहरण की तरह कभी-कभी वह पूरी तरह गलत code location पर सुझाव भी दे देता था, लेकिन इसे धीरे-धीरे नियंत्रित किया जा रहा है। अभी कोई टूल 100% परफेक्ट नहीं है, और AI के सब कुछ takeover करने में अभी थोड़ा समय लगेगा

  • जब OpenHands (पहले इसका नाम OpenDevin था) शुरू किया गया था, तब AI द्वारा बनाए गए PR AI अकाउंट के नाम से आते थे। इससे दो गंभीर समस्याएँ हुईं: 1) AI को चलाने वाला व्यक्ति बिना कोड रिव्यू के सीधे merge कर सकता था, जिससे बिना जाँचा गया कोड deploy हो सकता था, 2) PR का कोई स्पष्ट जिम्मेदार व्यक्ति नहीं होता था, इसलिए वह merge न हो या बाद में समस्या आए तो जिम्मेदारी किसकी है, यह अस्पष्ट रहता था। इसलिए रणनीति बदली गई और हर PR का owner इंसान को बनाया गया, जबकि commit पर ही AI का नाम रहने दिया गया। PR खुद पूरी तरह इंसान की जिम्मेदारी है

    • अगर किसी ने समस्या वाला कोड merge किया है, तो अंततः approver और merge करने वाला ही जिम्मेदार होगा, यह तो स्पष्ट है

  • यह बात दिलचस्प लगी कि LLM bugs अच्छी तरह खोज लेते हैं। मैं जानना चाहूँगा कि high real-world bug detection rate पाने के लिए कितने false positives आए। मेरे अनुभव में LLM अक्सर bug न होने पर भी कह देते हैं कि bug है

    • इससे मैं पूरी तरह सहमत हूँ। जब मैं ChatGPT से कुछ पूछता हूँ और उसका सुझाव पसंद नहीं आता, तो अगर मैं कह दूँ "मुझे उस हिस्से पर भरोसा नहीं है?" तो वह तुरंत जवाब बदल देता है। हो सकता है कि उसकी पहली बात सही रही हो, लेकिन अगर यूज़र आश्वस्त न लगे तो वह आसानी से डगमगा जाता है। इसलिए टूल को सही तरह validate करना आसान नहीं है

    • इस मामले में हर file में सिर्फ एक bug था और bot को कहा गया था कि वह ठीक एक ही bug ढूँढे। ये सब false positive के मामले थे, और उसने वहाँ भी bug गढ़ लिया जहाँ कोई समस्या थी ही नहीं

    • बाज़ार में मौजूद अलग-अलग AI code review tools के बीच असली फर्क signal/noise ratio की tuning में है। कुछ tools कहीं ज़्यादा accurate हैं और उनमें false positives कम हैं

  • एक programmer की सबसे महत्वपूर्ण जिम्मेदारी यह है कि वह ऐसा working code बनाए जिस पर उसे खुद भरोसा हो। LLM का इस्तेमाल किया या नहीं, यह उतना महत्वपूर्ण नहीं है। महत्वपूर्ण यह है कि PR उठाते समय उसका रवैया यह हो: "मुझे भरोसा है कि यह बदलाव समस्या हल करता है, और मैं इस पर अपनी प्रतिष्ठा दाँव पर लगा सकता हूँ।" इसलिए PR में चाहे इंसान हो या AI, हमेशा एक दूसरे reviewer की ज़रूरत होती है

    • मेरी राय में प्रतिष्ठा ही मुख्य चीज़ है। यह सिर्फ coding पर नहीं, natural language writing पर भी लागू होता है। अब हम ऐसे दौर में हैं जहाँ जिम्मेदारी लेखक की नहीं बल्कि उसे प्रकाशित करने वाले व्यक्ति, यानी publisher की होगी। चाहे 5% chatbot शामिल हो या 95%, अगर उस सामग्री से समस्या होती है तो दोष मुझे मिलना चाहिए जिसने उसे प्रकाशित किया। "यह chatbot ने किया था" कोई मान्य बहाना नहीं है

    • यह सिर्फ Devin जैसे fully automated engineer के उदाहरण की बात थी, जो सामान्य इंजीनियर की स्थिति से थोड़ी अलग है

    • आजकल बहुत से इंजीनियर AI द्वारा बनाया गया घटिया कोड लापरवाही से फेंक देते हैं और उम्मीद करते हैं कि दूसरे सहकर्मी उसमें समस्या पकड़ लेंगे। पहले ऐसा कम होता था क्योंकि कोड जनरेशन खुद ही कठिन था

    • इस बात से मैं गहराई से सहमत हूँ कि आपकी जिम्मेदारी भरोसेमंद कोड बनाना है। लेकिन AI से पहले भी अच्छे कोड के मानक हमेशा नहीं निभाए जाते थे। हमने coding को सिर्फ एक साधन या कमाई का ज़रिया मानना शुरू कर दिया है। मूल रूप से इसमें 'समस्याएँ हल करने और दुनिया बदलने का आनंद' था। लेकिन अब ध्यान 'जल्दी पैसा कमाने या अपने लिए घेरे बनाने' पर ज़्यादा है। महत्वपूर्ण यह नहीं कि कोड सुंदर है या नहीं, बल्कि यह है कि उसने समस्या को सुरुचिपूर्ण ढंग से हल किया या नहीं। AI इस संस्कृति को और खराब कर सकता है, लेकिन आखिरकार सब कुछ इस पर निर्भर करता है कि उसका उपयोग कैसे किया जाता है

    • एक सवाल है। अगर PR सभी समस्याएँ हल कर देता है और उसमें सिर्फ मामूली bugs हों, तो क्या उसे समय की बर्बादी कहा जाएगा? मैं इसका कोई उदाहरण जानना चाहूँगा

  • कोड रिव्यू इंजीनियरिंग का सबसे धीमा चरण है। मैं AI के बिना भी कोड जल्दी लिख सकता हूँ, लेकिन कोड रिव्यू तेज़ नहीं होता। इसलिए मैं रिव्यू से पहले AI से pre-review करवा लेता हूँ, ताकि सहकर्मियों का समय बचे और bugs पहले ही पकड़ लिए जाएँ, जिससे deploy तक पहुँचने का समय कई दिनों तक कम हो जाता है। AI ने साफ़ bugs से लेकर छिपी हुई गलतियों तक पकड़ी हैं, और कभी-कभी सच में deep bugs भी खोज निकाले हैं। मैं git cli और xclip जैसी चीज़ों से diff कॉपी करके उसे o3 जैसे logic model में पेस्ट कर रिव्यू लेने वाला workflow इस्तेमाल करता हूँ

    • अगर आप ऐसा कर रहे हैं, तो उम्मीद है कि आपने OpenAI के साथ enterprise contract ज़रूर किया होगा

  • AI का एक बड़ा फायदा यह है कि वह इंसानों की तुलना में बहुत तेजी से बड़ी संख्या में unit tests लिख सकता है। और जो समस्याएँ वह खुद खोजता है, उन्हें खुद ठीक भी कर सकता है। आदर्श workflow सिर्फ code review तक सीमित नहीं होगा, बल्कि AI खुद tests चलाए, और यह भी जाँचे कि सब कुछ किसी तय spec को पूरा कर रहा है। बहुत ज़्यादा tests बाद में refactoring को कठिन बना सकते हैं—जैसे implementation details पर निर्भर tests—और जब वे परेशान करें तो AI द्वारा लिखे गए tests को अलग से फेंका भी जा सकता है

    • मुझे यह बहुत अच्छा लगता है कि मैं ज़रूरत पड़ने पर unit tests फिर से generate कर सकता हूँ। रिव्यू उठाते समय diff का आकार छोटा देखकर बड़ी संतुष्टि मिलती है, और tests लिखने में जाने वाला उबाऊ समय बचाकर मैं ज़्यादा काम कर पाता हूँ

    • अभी भी programming में कुछ उबाऊ काम बचे हुए हैं, लेकिन आदर्श रूप से AI को ऐसी inefficiency कम करनी चाहिए ताकि इंसान रचनात्मक कामों पर ध्यान दे सकें। हालांकि व्यवहार में AI धीरे-धीरे ज़्यादा high-level creative कामों तक भी पहुँच रहा है

    • सच तो यह है कि AI के बिना भी property-based testing frameworks का उपयोग करके बहुत सारे input values के साथ automated tests बनाए जा सकते हैं

  • कोड रिव्यू करते समय मेरा एक नियम है: अगर मुझे भरोसा नहीं कि मैं बाद में इसे खुद maintain कर पाऊँगा, तो मैं approve नहीं करता। अगर LLM को कोड लिखने और रिव्यू दोनों में इस्तेमाल किया जाए, तो कहा जा सकता है कि tools पर भी यही जिम्मेदारी का सिद्धांत लागू होना चाहिए। लेकिन सच कहूँ तो मैं खुद ऐसे माहौल में लंबे समय तक टिके रहने को लेकर आश्वस्त नहीं हूँ

  • क्या किसी ने ऐसा pipeline आज़माया है जिसमें एक LLM requirements से Gherkin scripts बनाए, दूसरा LLM उन scripts से code generate करे, और फिर Cucumber से result verify किया जाए? किसी भी स्थिति में Gherkin scripts और code दोनों का review तो करना ही पड़ेगा, लेकिन मैं जानना चाहता हूँ कि किस तरह के code इस तरीके से बनाए नहीं जा सकते। मैं AI को एक developer की तरह देख रहा हूँ, और जैसे इंसानी developers की कुछ कमजोरियाँ होती हैं, वैसे ही इसकी भी कुछ सीमाएँ ज़रूर होंगी

  • आखिरकार PR उठाने वाले लेखक को अपने code के impact और परिणामों की जिम्मेदारी लेनी ही होगी। AI coding के आम होने और junior engineers की संख्या बढ़ने के साथ यह जिम्मेदारी और महत्वपूर्ण हो गई है। AI का review के first pass के रूप में काम करना तर्कसंगत है, लेकिन human reviewer की भी ज़रूरत है ताकि वह बाहर के नज़रिए से codebase की समझ बढ़ाए और higher-level समस्याएँ पकड़ सके। निष्कर्षतः आदर्श संरचना यह है कि AI first-pass review करे, फिर कोई दूसरा engineer context या collaboration के दृष्टिकोण से code review करे, और अंततः लेखक सभी परिणामों की जिम्मेदारी ले