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

• 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 को पढ़ सकते हैं या नहीं, यह अब उतना महत्वपूर्ण नहीं रह जाता