कोड रिव्यू को खत्म करने का तरीका

• AI द्वारा जनरेट किए जाने वाले कोड की मात्रा और पैमाना तेज़ी से बढ़ने के साथ, पारंपरिक मैनुअल code review तरीका अब प्रभावी नहीं रहा
• जिन टीमों में AI adoption अधिक है, उनमें काम पूरा होने की मात्रा 21% बढ़ी और PR merge 98% बढ़े, लेकिन PR review समय 91% बढ़ने की विरोधाभासी स्थिति भी सामने आई
• कोड को सीधे जाँचने के बजाय, spec और acceptance criteria की समीक्षा करने वाली upstream validation की ओर मानव की भूमिका शिफ्ट होनी चाहिए
• एकल validation gate की जगह multi-agent competition, deterministic guardrails, BDD, permission systems, और adversarial validation जैसे Swiss cheese model पर आधारित multi-layer trust structure की ज़रूरत है
• "तेज़ी से deploy करो, सब कुछ observe करो, और उससे भी तेज़ rollback करो" का तरीका धीमे review के बाद production debugging की जगह लेने वाला नया paradigm है

---

इंसान पहले से ही code review संभाल नहीं पा रहे हैं

• PR कई दिनों तक पड़े रहते हैं, औपचारिक approval दे दिया जाता है, और reviewers का 500-line diff को बस सरसरी तौर पर देखना ही वास्तविकता है
• code review को quality gate माना जाता है, लेकिन line-by-line review के बिना भी दशकों से software ship करने वाली टीमें रही हैं, और code review का व्यापक प्रचलन लगभग 2012~2014 के आसपास हुआ
• review होने पर भी outages होते हैं, और इसी के जवाब में feature flag, gradual rollout, instant rollback जैसे systems बनाए गए

हर कोड को पढ़ने की कोशिश छोड़नी होगी

• जिन टीमों में AI adoption अधिक है, वहाँ change count और change size दोनों एक साथ तेज़ी से बढ़ रहे हैं
  • 10,000 से अधिक developers और 1,255 teams के data पर आधारित (Faros analysis)
• developers को लगता है कि AI-generated code review करना, peer code review की तुलना में ज़्यादा मेहनत मांगता है
• मैनुअल code review से यह लड़ाई नहीं जीती जा सकती, और code review मौजूदा काम करने के तरीके से मेल न खाने वाला अतीत का approval gate है

AI code review भी आखिरकार सिर्फ़ 'review' ही है

• अगर AI कोड लिख रहा है और AI ही review कर रहा है, तो सुंदर review UI दिखाने का कोई कारण नहीं बचता
• AI code review tools बस थोड़ा समय दिलाते हैं, और इस तरह का review धीरे-धीरे development cycle के बाएँ हिस्से (shift left) की ओर जाएगा
  • CI resources बर्बाद करने और review cycles के बीच version management करने का कोई कारण नहीं है
• agents के कोड लिखने वाले माहौल में "नई नज़र" भी वही blind spots रखने वाला एक और agent ही है, और असली value approval gate में नहीं बल्कि iteration loop में है
• "मैंने AI को एक बार बेवकूफ़ी करते देखा है, इसलिए हमेशा verify करना होगा" वाली प्रवृत्ति तब तक तर्कसंगत थी जब मैनुअल validation संभव था, लेकिन मौजूदा scale पर यह अब व्यावहारिक नहीं रही

code review से intent review की ओर बदलाव

• मानव checkpoints को upstream ले जाना होगा
  • software development में checkpoints के शिफ्ट होने की मिसाल पहले भी है: waterfall sign-off → continuous integration (CI)
• spec-driven development AI collaboration के प्रमुख तरीकों में उभर रहा है
  • इंसानों को spec, plan, constraints, और acceptance criteria की समीक्षा करनी चाहिए; 500-line diff की नहीं
• नए paradigm में spec ही source of truth बनती है, और code spec का output होता है
  • कोड की review नहीं, बल्कि steps, verification rules, और उस contract की review होती है जिसे code को पूरा करना है
• Human-in-the-loop approval, "क्या यह सही लिखा गया है?" से बदलकर "क्या यह सही constraints के साथ सही समस्या हल कर रहा है?" बन जाती है
• सबसे मूल्यवान मानव निर्णय, कोड बनने के बाद नहीं बल्कि पहली लाइन generate होने से पहले काम आता है

multi-layer trust बनाना — Swiss cheese model

• LLM निर्देशों का अच्छे से पालन नहीं करते, बार-बार भटकते हैं, और self-validation में भी भरोसेमंद नहीं होते (कोड टूट रहा हो तब भी आत्मविश्वास से "काम करता है" कह देते हैं)
• समाधान LLM से validation माँगना नहीं, बल्कि validation करने वाली scripts लिखवाना है — judgment से output की ओर शिफ्ट
• trust परत-दर-परत बनता है, और Swiss cheese model के अनुसार imperfect filters को इस तरह overlap किया जाता है कि उनके छेद एक लाइन में न आएँ

Layer 1: कई विकल्पों की तुलना

• एक agent से सही जवाब माँगने के बजाय, तीन agents अलग-अलग तरीके से कोशिश करें और सबसे अच्छा परिणाम चुना जाए
• चयन मैनुअल होना ज़रूरी नहीं; जैसे सबसे अधिक validation steps पास करने वाला, सबसे छोटा diff, या नई dependencies न जोड़ने वाला विकल्प ऊपर रखा जा सकता है
• options की लागत software engineering के इतिहास में सबसे निचले स्तर पर है

Layer 2: deterministic guardrails

• काम को validate करने के लिए deterministic तरीके चाहिए — tests, type checks, contract validation जैसी चीज़ें जो राय नहीं बल्कि तथ्य से जुड़ी हों
• LLM से "क्या यह हो गया?" पूछने के बजाय, validation steps को इस तरह define किया जाए कि वे pass/fail outputs दें
• guardrails की hierarchy:
  • coding guidelines — custom linter से लागू की जा सकती हैं
  • पूरे संगठन के invariant rules — hardcoded credentials, API keys, tokens पर रोक जैसी non-negotiable बातें
  • domain contracts — framework, services, या codebase के क्षेत्रों के हिसाब से नियम (जैसे payment domain में हर amount के लिए Money type का उपयोग)
  • acceptance criteria — हर task के लिए अलग मानदंड
• validation steps को code लिखने से पहले define किया जाना चाहिए; बाद में सिर्फ़ पहले से मौजूद चीज़ को साबित करने के लिए नहीं
  • अगर agent code और tests दोनों लिखता है, तो यह समस्या को बस आगे खिसकाना है; validation criteria implementation से नहीं बल्कि spec से आने चाहिए

Layer 3: इंसान acceptance criteria define करें

• इंसान जहाँ सबसे ज़्यादा value जोड़ते हैं, वह है upstream में success की definition तय करना
• BDD(Behavior-Driven Development) फिर से प्रासंगिक हो रहा है
  • natural language में expected behavior लिखना और उसे tests में automate करना इसका तरीका है
  • पहले code भी खुद लिखना पड़ता था, इसलिए spec लिखना extra work लगता था; लेकिन agent environment में spec ही primary output है
• इंसान spec लिखते हैं, agents implement करते हैं, और BDD framework validate करता है — जब तक failure न हो, implementation पढ़ने की ज़रूरत नहीं
• इंसान जिन कामों में अच्छे हैं: "सहीपन" को define करना, business logic और edge cases को encode करना, और क्या-क्या गलत हो सकता है इस पर सोचना
• इंसानों द्वारा लिखे गए और machines द्वारा validated acceptance criteria ही वास्तव में महत्वपूर्ण gate हैं

Layer 4: permission systems को architecture बनाना

• agents क्या छू सकते हैं और किन चीज़ों के लिए escalation चाहिए, यह एक architectural decision होना चाहिए
• ज़्यादातर agent frameworks permissions को all-or-nothing की तरह संभालते हैं, लेकिन granular control ज़रूरी है
  • utility function bug fix करने वाले agent को infrastructure configuration की access की ज़रूरत नहीं
  • test लिखने वाले agent को CI pipeline बदलने की permission की ज़रूरत नहीं
• scope उतना ही संकीर्ण होना चाहिए जितना कि agent को उपयोगी काम करने के लिए पर्याप्त हो
  • उदाहरण: "utils/dates.py में date parsing bug fix करना" task हो, तो सिर्फ़ उसी file और test files की access मिले
• escalation triggers भी महत्वपूर्ण हैं: authentication logic बदलना, database schema बदलना, नई dependency जोड़ना जैसी patterns, agent के confidence से अलग, अपने-आप human review trigger करें

Layer 5: adversarial validation

• ज़िम्मेदारियों का separation: एक agent काम करे, और दूसरा agent validate करे — मुख्य बात यह है कि वे एक-दूसरे पर भरोसा न करें
  • जैसे QA team को engineering manager को report नहीं करना चाहिए, और code writer अकेले reviewer नहीं होना चाहिए — यह पुराना लेकिन अहम pattern है
• इसे architecture के स्तर पर enforce किया जा सकता है: coding agent को पता न हो कि validation agent क्या जाँचेगा, और validation agent code बदल न सके — यानी design के हिसाब से adversarial
• इससे आगे, तीसरा agent पहले agent द्वारा बनाई चीज़ को edge cases और failure modes को निशाना बनाकर तोड़ने की कोशिश करे — हर change पर red team/blue team automation जैसा मॉडल

"अच्छे code" का मतलब बदल रहा है

• agent systems के incentives सरल हैं: दिए गए task को पूरा करना और निर्देश देने वाले को संतुष्ट करना — long-term correctness या business requirements उनकी स्वाभाविक प्रेरणा नहीं हैं
• इन्हें constraints में encode करना इंसानों की भूमिका है
• जहाँ agents code generate भी करते हैं और पढ़ते भी हैं, वहाँ "अच्छे code" की शक्ल ज़्यादा standardized होगी, और नए codebase में देने वाली दिशा कम हो जाएगी
• भविष्य की दिशा: "तेज़ी से deploy करो, सब कुछ observe करो, और उससे भी तेज़ rollback करो"
  • इसके उलट: "धीरे review करो, फिर भी bugs छूट जाएँ, और production में debugging करो"
• मशीनों को ज़्यादा पढ़कर आप नहीं जीत सकते; ज़रूरत है ऐसी upstream thinking की, जहाँ निर्णय सच में मायने रखते हैं और इंसान मशीनों से बेहतर सोचते हैं
• अगर agents code को अच्छी तरह संभाल सकते हैं, तो इंसान उस code को पढ़ सकते हैं या नहीं, यह अब उतना महत्वपूर्ण नहीं रह जाता

[shlee1503]

कोड रिव्यू bottleneck है, तो रिव्यू ही मत करो — ये बात इतनी अनोखी है कि हँसी आ रही है hahaha

[bbulbum]

मुझे जानने की जिज्ञासा है कि AI से पहले क्या सबके यहाँ code review सच में ठीक से काम करता था।
जो संगठन code review को तेज़ी और मेहनत से करते थे, वे वास्तव में बहुत दुर्लभ थे।
AI से पहले भी बहुत से developers code review में सुस्त थे, reviews लंबित पड़े रहते थे, और वे ढीले-ढाले होते थे।

[snisper]

मेरे अनुभव में, अमेरिकी tech कंपनियाँ सिद्धांतों के मुताबिक चलती थीं, जबकि घरेलू कंपनियों सहित विदेशों की कई कंपनियाँ बुरी तरह अव्यवस्थित थीं.
दूसरे शब्दों में कहें तो, जितना review सख्त होता था उतना ही काम का stress ज़्यादा होता था, और अव्यवस्थित review तुलनात्मक रूप से ज़्यादा ढीले-ढाले होते थे

[hanje3765]

मुझे लगता है कि review का खत्म होना behavior incentives का नतीजा है।
अगर कंपनी की मांग कम error rate है, तो वह reviews को और सख्ती से लागू करेगी,
और अगर तेज़ feature release है, तो reviews धीरे-धीरे छोड़े जाने लगेंगे।
review के गायब होने की बात से मुझे लगता है कि कंपनियां तेज़ feature release को प्राथमिकता दे रही हैं।
लेकिन अगर मैं investor होता, तो शायद मैं भी वही मांग करता, हाहा

[vk8520]

मुझे ठीक से समझ नहीं आ रहा। अगर यह कहकर कि review bottleneck बन गया है, review ही न करने को कहा जाए, तो लगता है कि हम अपने मूल दायित्व को भूल रहे हैं। बल्कि मेरा मानना है कि implementation time जितना कम हुआ है, उतना ही review time अनिवार्य रूप से आवंटित करना बेहतर तरीका होगा।

[moregeek]

क्या हम बस black boxes जोड़ते ही रहें?

[ahwjdekf]

कोड को बस एक ब्लैक बॉक्स की तरह बना दें और केवल नतीजे देखें... मतलब कुछ ऐसा ही है... क्या सच में यह सही दिशा है... मुझे लगता है कि कभी न कभी ऐसा समय ज़रूर आएगा जब AI से लिखे गए मौजूदा कोड को पूरी तरह उलट-पुलट कर फिर से बनाना पड़ेगा।

[dhlee0305]

यह कुछ वैसा ही सवाल लगता है जैसे कहना कि "FSD अब इतना स्मार्ट हो गया है, इसलिए ड्राइवर सो भी जाए तो चलेगा।"
तकनीकी रूप से लगता है कि धीरे-धीरे ऐसा दौर आ सकता है, लेकिन असली बात यह होगी कि जवाबदेही जैसी बाधा को हम कैसे पार करेंगे।
मुझे लगता है कि code review कम से कम एक न्यूनतम सुरक्षा उपाय तो है।

[brilliant08]

उससे भी ऊपरी कॉन्सेप्ट, यानी intent validation, इंसान ही क्यों करता है..?

[adieuxmonth]

असल में, प्रोग्रामिंग language में coding करवाने की भी ज़रूरत नहीं है।

[ewpes]

अगर AI को वही prompt दिया जाए, तो उसके output को review करना कुछ हद तक मॉडल की performance test करने जैसा नहीं लगता?

[conpages]

सोचने लायक विचार तो है, लेकिन लगता है कि अभी इसके लिए बहुत जल्दी है — ऐसा नज़रिया ज़्यादा हावी है।

[github88]

लगता है जैसे निष्कर्ष पहले से तय करके LLM से बस उसे लिखवा लिया गया हो। कुतर्क।
लगता है कि production का कोई अनुभव ही नहीं है

[myc0058]

बस सपने जैसी बात लगती है।
समय बीतने के साथ तो documentation भी बेअर्थ लगने लगती है, और review भी और ज़्यादा सख्ती से होने लगती है, है न?

[fantajeon]

हाँ~ ऐसी बहस छेड़कर सोचने पर मजबूर करने वाले लेख के रूप में ही इसका मकसद काफ़ी हद तक पूरा हो गया था।

[gomjellie]

यह एक अनुवादित लेख है: https://rosetta.page/post/anuvad-code-review-ko-hatane-ka-tarika-QTVz6

[brainer]

यह वैसे भी ऐसी समस्या है जिसे शुरुआत में ही planning चरण में फ़िल्टर किया जा सकता है।

[foriequal0]

कोड को हाथ से लिखने की प्रक्रिया में डेवलपर स्वाभाविक रूप से planning भी करता है, design भी, exploration भी, understanding भी, testing भी, self-review भी, और समस्या होने पर बाद की प्रतिक्रिया की प्रक्रिया भी—ये सब वह implicit और parallel तरीके से करता है, इसलिए स्वाभाविक रूप से हर पहलू आपस में समायोजित होता रहता है। इसलिए मेरा मानना है कि testing या review थोड़ा कम भी हो, तब भी चीजें कुछ हद तक चल जाती थीं.
लेकिन अगर हाथ से लिखने की प्रक्रिया ही हटा दी जाए, तो जो implicit प्रक्रियाएँ थीं उन्हें explicit सीमाओं में बाँटना पड़ता है। क्योंकि कोड लिखने वाले और उसे review करने वाले पक्ष और भी ज़्यादा अलग हो जाते हैं, इसलिए communication की inefficiency बढ़ती है। कोड लिखने वाले पक्ष पर भरोसा और कम हो जाने से review की लागत भी बढ़ जाती है.
मुझे लगता है कि यह doorman's fallacy जैसी अवधारणा से मिलता-जुलता है.

[remin1994]

यह वह विषय है जिस पर मैं भी कंपनी में अक्सर सोचता रहा हूँ, और यह अच्छा है। मुझे लगता है कि इसे उस हार्नेस में भी लागू करके देखना चाहिए जिसे मैं व्यक्तिगत रूप से बना रहा हूँ।

[jayhanx]

मुझे लगता है कि धीरे-धीरे हम review को और सरल करते हुए और testing को ज़्यादा सख्त बनाने की दिशा में बढ़ेंगे।

[smoonsf]

यह सिर्फ़ कोड रिव्यू को हटा देने की बात नहीं लगती, बल्कि उससे ऊपर के कॉन्सेप्ट—यानी intent—और यह कि वह intent सही तरह से काम कर रहा है या नहीं, इसे स्पष्ट रूप से verify कर सकने वाले output के आधार पर review करने की बात लगती है.

मौजूदा समय में, design या architecture level के बजाय code implementation की details को black box की तरह बनाए रखना वांछनीय है, ऐसा मेरा मानना है.

[moregeek]

मुझे लगता है कि वह ब्लैक बॉक्स जमा होते-होते ऐसी स्थिति तक पहुँच सकता है जहाँ AI भी ठीक से कुछ नहीं कर पाएगा। लगता है कि सब लोग सुविधा के नशे में कुछ ज़्यादा ही डूबे हुए हैं। मुझे लगता है कि कभी न कभी कोई बड़ा हादसा होगा।

[raykim]

मैं भी ऊपर वाले व्यक्ति की राय से सहमत हूँ। अगर किसी दिन अचानक यह पता चले कि मॉडल ने human code के किसी हिस्से को गलत तरीके से सीखा था, और हमें एहसास हो कि वह अब तक code में लागू होता रहा है? वह दिन सब कुछ उलट-पुलट करने वाला भी हो सकता है..

चाहे latest model कितना भी कमाल कर ले, अगर वह swe benchmark में "हमेशा" (6 nine, 0.999999) full marks नहीं ला सकता, तो मुझे लगता है कि यह संभावना खुली हुई है।

[shakespeares]

Intention review. अच्छा शब्द है।

[ljyda214]

AI की वजह से तेज़ होती इस दौर में कैसे प्रतिक्रिया देनी चाहिए, इस पर मैं सोच रहा था
यह कोड रिव्यू पर एक नया नज़रिया देने वाला अच्छा लेख है!