0github - कोड रिव्यू के लिए हीटमैप-आधारित Diff व्यूअर

 (0github.com)
6 पॉइंट द्वारा GN⁺ 2025-11-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कोड बदलाव (diff) में हर लाइन और टोकन को रंगों से अलग करके यह दिखाने वाला टूल कि कहाँ रिव्यू की ज़्यादा ज़रूरत है
  • साधारण bug detection के बजाय, ‘दोबारा देखने लायक हिस्सों’ को उभारने के लिए डिज़ाइन किया गया
  • GitHub Pull Request URL में github.com को 0github.com से बदलते ही तुरंत इस्तेमाल किया जा सकता है
  • अंदरूनी तौर पर repository को VM में clone करके gpt-5-codex चलाया जाता है और JSON संरचना में analysis result तैयार किया जाता है

अवलोकन

  • यह टूल code review प्रक्रिया में बदले गए कोड के हर हिस्से को कितनी सावधानी से रिव्यू किया जाना चाहिए इसे heatmap के रूप में दिखाता है
  • रंगों का निर्धारण मानव ध्यान की आवश्यकता के आधार पर किया जाता है, और यह साधारण error detection से अलग दृष्टिकोण अपनाता है

यह कैसे काम करता है

  • उपयोगकर्ता GitHub Pull Request URL के domain को github.com से 0github.com में बदलकर एक्सेस करता है
  • सिस्टम संबंधित repository को virtual machine (VM) में clone करता है, और हर diff पर gpt-5-codex model चलाता है
  • model द्वारा बनाई गई JSON data structure को parse करके उसे रंगीन heatmap में बदला जाता है

विश्लेषण के मानदंड

  • सिर्फ “bug है या नहीं” नहीं, बल्कि hardcoded secret values, असामान्य encryption modes, जटिल logic आदि
    ऐसे हिस्सों को उभारा जाता है जिन्हें इंसान को दोबारा जांचना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-11-01
Hacker News की राय

  • परिचित codebase में मैं सोचता हूँ, “LLM धन्यवाद, लेकिन मुझे ज़रूरत नहीं क्योंकि मैं इसे बेहतर जानता हूँ”
    वहीं अगर code अपरिचित हो, तो मैं वैसे भी review approve या merge नहीं करता
    फिर भी LLM का यह रचनात्मक उपयोग एक दिलचस्प कोशिश है

    • मैंने खुद test किया। Laravel PR #57499 को रैंडम चुना, लेकिन 60% setting पर सिर्फ test code ही highlight हुआ और महत्वपूर्ण बदलाव छूट गए
      deleted code बिल्कुल दिखाया नहीं गया, और केवल unmodified lines highlight हुईं
      ईमानदार कोशिश थी, लेकिन नतीजा निराशाजनक रहा

  • मुझे समझ नहीं आया कि GitHub पर मेरी तरफ़ से कार्रवाई करने की permission तक क्यों माँगी जा रही थी
    cmux-agent मेरे पूरे GitHub account की access माँग रहा था
    मैं issue दर्ज करना चाहता था, लेकिन repository में issues feature disable था। थोड़ा संदिग्ध सा लगा

    • अगर यह public repository है, तो login के बिना access होना चाहिए
      मैंने incognito mode में example PRs, stack-auth, tinygrad, datasette test किए, और वे ठीक चले
      issues disable होने का पता नहीं था, और अब issues page सामान्य रूप से काम कर रहा है
    • यह GitHub की एक संरचनात्मक समस्या है। संबंधित चर्चा देखें तो OAuth App और GitHub App के permission models अलग हैं
      GitHub App को सिर्फ़ किसी specific repo पर install किया जा सकता है, लेकिन फिर भी उसमें “user की तरफ़ से कार्रवाई” करने की permission शामिल रहती है
      इसी वजह से वह डरावना popup दिखाई देता है
      मेरा app codeinput.com OAuth App है, इसलिए वह सिर्फ़ email माँगता है, लेकिन login के बाद फिर से install process से गुजरना पड़ता है, जिससे authentication flow जटिल हो जाता है
    • app पहली बार चलाते समय GitHub login माँगता है। उससे पहले कुछ भी नहीं देखा जा सकता

  • दिशा दिलचस्प है, लेकिन cost बनाम utility थोड़ा अस्पष्ट है
    सिर्फ़ एक PR diff के आधार पर LLM के लिए project context समझना अभी भी मुश्किल है
    इसके बजाय पुराने bugs या change frequency पर आधारित data-driven heatmap शायद ज़्यादा भरोसेमंद हो

    • अगर Gemini free key इस्तेमाल करें, तो daily request volume काफ़ी होता है, इसलिए छोटी टीमों (10~20 PR/दिन) के लिए यह बड़ा खर्च नहीं है
      अगर इसे personal key के साथ चलाया जा सके, तो और अच्छा होगा
    • सोच रहा हूँ कि diff की entropy analyze करने वाला कोई मिलता-जुलता tool है क्या
    • हमने भी पहले repo को VM में clone करके Codex से explore कराने का experiment किया था, लेकिन latency और cost की वजह से रोक दिया
      Distillation से cost कम की जा सकती है, ऐसा लगता है, लेकिन अभी experiment चल रहा है
      यह भी सोच रहे हैं कि पुराने bugs के साथ correlation को LLM के बिना कैसे calculate किया जाए
    • code review करते समय मैं अक्सर diff में न होने वाली lines का भी ज़िक्र करता हूँ
      ऐसे tools आखिरकार समस्या का सिर्फ़ एक हिस्सा ही हल कर सकते हैं
    • code के जिन हिस्सों में बार-बार बदलाव होते हैं, ज़रूरी नहीं कि वहीं सबसे ज़्यादा bugs हों
      उल्टा यह भी हो सकता है कि लोग उन हिस्सों को ज़्यादा ध्यान से देखते हों
      open source data के आधार पर इसकी जाँच करना दिलचस्प होगा

  • मेरा PR HN पर आया, यह देखकर अच्छा लगा
    अच्छा होगा अगर 0% threshold पर color gradients को कई तरीकों से adjust किया जा सके
    यह भी जानना चाहता हूँ कि PR बनाने से पहले AI द्वारा लिखे code को इस tool से पहले ही review किया जा सकता है या नहीं

    • color और gradients को configurable बनाने की योजना है
      मैं यह भी राय जानना चाहता हूँ कि CLI या HTML के रूप में diff render करने वाला command ठीक रहेगा या नहीं
    • ऐसा tool इस्तेमाल करते-करते शायद खुद coding करने से भी ज़्यादा समय लग जाए

  • domain name 0github.com शायद लंबे समय तक टिकाना मुश्किल होगा। जल्दी कोई दूसरा domain ढूँढना बेहतर होगा

    • जानना चाहता हूँ कि ऐसा क्यों

  • बड़े PRs में यह खास तौर पर उपयोगी लग सकता है
    slider की जगह अगर रंग के हिसाब से click करके उसका मतलब तुरंत देखा जा सके, तो अच्छा होगा
    अभी इसे एक नज़र में समझना मुश्किल है, लेकिन बार-बार इस्तेमाल करने पर आदत पड़ सकती है

    • अभी highlighted शब्दों पर mouse ले जाने से tooltip दिखता है
      इसे mobile पर भी दिखे, ऐसा सुधार करने वाले हैं। अगर कोई और display तरीका बेहतर हो, तो जानना चाहूँगा

  • मैंने इसे एक साधारण Rust PR पर आज़माया, और यह काफ़ी अच्छा चला
    लेकिन highlight की position को थोड़ा और बारीकी से adjust किया जा सके, तो अच्छा होगा
    किसी सहकर्मी के PR में लगभग न दिखने वाली typo पकड़ लेना प्रभावशाली था
    test किया गया PR link
    deleted code का कुछ हिस्सा दिखता है, लेकिन बहुत कुछ अनदेखा कर दिया जाता है
    सोच रहा था कि क्या यह tokens के बीच की दूरी calculate करने का तरीका है

    • implementation इस file में है
      फिलहाल यह एक simple LLM prompt-आधारित तरीका है
      आगे चलकर इसे hallucinated tokens detection के तरीके तक बढ़ाया जा सकता है। इस पर papers ढूँढने का इरादा है

  • आजकल AI द्वारा बनाए गए बड़े PRs बहुत बढ़ गए हैं, इसलिए ऐसे tool की ज़रूरत महसूस हुई
    अच्छा होगा अगर यह reviewer की style सीखे और उसी के हिसाब से customized review दे
    मैं देख रहा हूँ कि क्या यह commit सही है

    • मुख्य logic इस file में है
      DSPy system के साथ reviewer की preferences के अनुसार automated review का experiment चल रहा है

  • असल में, ऐसे tool की ज़रूरत ही न पड़े, इसके लिए उचित आकार के PRs बनाना ज़्यादा महत्वपूर्ण है
    आजकल हम AI से लिखे PRs review कर रहे हैं, और यहाँ तक कि मेरे comments का जवाब भी AI दे रहा है
    लगता है कि आखिरकार reviewer भी AI से replace होने का दौर आ जाएगा

  • मैंने example PR पर click किया, लेकिन वह लगातार loading में ही रहा। लगता है caching की ज़रूरत है

    • caching पहले से होनी चाहिए, जाँच कर रहा हूँ
    • fix कर दिया है। अब यह सामान्य रूप से काम कर रहा है