एजेंटिक कोड रिव्यू

• coding agents की तेज़ी से बढ़ती क्षमता के कारण engineering की कठिनाई कोड लिखने से इस पर निर्णय लेने की तरफ खिसक गई है कि उस कोड पर भरोसा किया जाए या नहीं, और review सबसे अधिक leverage वाला काम बन गया है
• AI output को बहुत बढ़ाता है, लेकिन quality और reviewability को घटा देता है; मापा गया अंतर यह है कि 4 गुना कोड के बदले वास्तविक value सिर्फ लगभग 10% बढ़ती है
• ज़रूरी review की कठोरता बदलाव के blast radius (प्रभाव-क्षेत्र) पर निर्भर करती है, और solo developer तथा 10 साल पुराने बड़े सिस्टम को maintain करने वाली टीम की constraints पूरी तरह अलग होती हैं
• agents reasoning करते हैं, लेकिन वह reasoning PR के साथ attach नहीं होती और खो जाती है, जिससे reviewer पर गायब intent को शुरुआत से फिर से reconstruct करने का बोझ आ जाता है
• लिखना सस्ता हो गया है, लेकिन समझना अब भी महंगा है; इसलिए विश्वसनीय review system बनाने वाली टीमें आगे बढ़ेंगी

---

2026 का data वास्तव में क्या दिखाता है

• वर्षों तक किस्सों और बहसों में सीमित रही बात अब बड़े पैमाने पर उन संगठनों ने मापी है जिनके हित अलग-अलग हैं, और कुछ तो प्रतिस्पर्धी भी हैं; निष्कर्ष एक ही है: AI output तो तेज़ी से बढ़ाता है, लेकिन quality और reviewability को घटाता है

• Faros AI measurement (मार्च 2026 data)

  • 4,000 टीमों के 22,000 developers में low-AI adoption से high-AI adoption की ओर बदलाव को track किया गया
  • सकारात्मक पक्ष: developers ने ज़्यादा PR merge किए और ज़्यादा काम पूरा किया, प्रति engineer throughput बढ़ा
  • नकारात्मक metrics
    • code churn 861% बढ़ा
    • incident-to-PR ratio 242.7% बढ़ा
    • प्रति developer defect rate 9% → 54%
    • median review time 441.5% बढ़ा (first review तक का समय और average review time दोनों लगभग 2 गुना)
    • बिना review merge हुए PR 31.3% बढ़े
  • बिना review merge होना किसी की पसंद नहीं था; यह इसलिए हुआ क्योंकि reviewers volume के साथ नहीं चल पाए और बिना पढ़ा गया code merge होना रोज़मर्रा की बात बन गया
  • mature और disciplined engineering practices वाली टीमें भी उतनी ही प्रभावित हुईं; अच्छी process भी सुरक्षा नहीं दे पाई, क्योंकि volume process design की गति से तेज़ पहुँचा

• CodeRabbit study (दिसंबर 2025)

  • open source PR के 470 नमूनों (AI co-authored 320, केवल मानव 150) के analysis में AI changes के साथ लगभग 1.7 गुना अधिक issues पाए गए
    • logic और correctness समस्याएँ लगभग 75% अधिक
    • security issues 1.5~2 गुना अधिक
    • readability problems 3 गुना से अधिक
  • AI director David Loker: "यह अनुमानित और मापने योग्य कमजोरी है, और संगठनों को इसे सक्रिय रूप से कम करना चाहिए" — यानी कमजोरी ज्ञात है और pinpoint की जा सकती है, इसलिए review process को सीधे इस पर लक्षित किया जा सकता है

• GitClear productivity data (2025 तक)

  • जो लोग रोज़ AI इस्तेमाल करते हैं, उनकी raw output non-users की तुलना में लगभग 4 गुना थी, लेकिन एक साल पहले के अपने ही स्तर की तुलना में वास्तविक productivity gain केवल लगभग 12% था
  • यानी 4 गुना code को अंततः इंसान को ही review करना पड़ता है
  • Bill Harding ने स्पष्ट कहा कि उस 12% का भी कुछ हिस्सा selection bias हो सकता है, क्योंकि मज़बूत developers AI group में अधिक केंद्रित हो सकते हैं

• GitHub report

  • Copilot review अब तक 6 करोड़ से अधिक बार चल चुका है, सिर्फ एक साल में 10 गुना वृद्धि; platform पर हर 5 reviews में से 1 से अधिक में agent शामिल है
  • यह अब niche practice नहीं रहा, बल्कि code बनने का एक प्रमुख तरीका है
• चार datasets और चार methodologies एक ही निष्कर्ष पर पहुँचती हैं: bottleneck गायब नहीं हुआ, वह verification stage में shift हो गया है

हर कोई अलग समस्या हल कर रहा है

• ऊपर के ज़्यादातर warning data enterprise telemetry और overwhelmed open source maintainers से आए हैं; कुछ गिने-चुने लोगों के लिए कुछ बनाने वाले solo developers पर ये पूरी तरह लागू नहीं होते

• आपकी स्थिति तय करने वाले तीन variables

  • blast radius: टूटने पर क्या होगा — कुछ नहीं, या नाराज़ users, पैसे का नुकसान, PII exposure
  • code की उम्र: क्या यह अगले हफ्ते फेंक दिया जाने वाला prototype है, या वर्षों तक maintain होने वाला codebase
  • उसे समझने वाले लोगों की संख्या: क्या सिर्फ आप हैं जिनके दिमाग में सब है, या समय के साथ ownership साझा करने वाली टीम है

• solo, greenfield, no users

  • review की दूसरी भूमिका, यानी team के भीतर knowledge distribution, यहाँ होती ही नहीं है (क्योंकि team आप ही हैं)
  • उचित विकल्प: tests और automation पर ज़ोरदार निर्भरता, और केवल सचमुच अहम हिस्सों की review; बाकी पर हल्का touch
  • लेकिन यह तभी काम करता है जब tests सचमुच वास्तविक हों; safety net के बिना review छोड़ने का मतलब काम का गायब हो जाना नहीं, बल्कि उसका और महंगा defer होना है
  • "users नहीं हैं" का मतलब review defer करने की अनुमति है, verification छोड़ने की नहीं

• खतरनाक बीच का चरण

  • जैसे ही project के users आते हैं, bug-finding की भूमिका अचानक महत्वपूर्ण हो जाती है, क्योंकि bugs अब लोगों को नुकसान पहुँचाते हैं; साथ ही knowledge sharing की भूमिका भी चालू हो जाती है
  • अगर team कुछ महीनों तक solo दिनों वाली आदतें जारी रखती है, तो postmortem आने पर Faros के numbers उसी के dashboard बन जाते हैं

• बड़े संगठन, पुराने codebases, बहुत से users

  • सभी warning metrics पूरे बल से लागू होते हैं; जिन changes को कोई नहीं समझता, वे comprehension debt (समझ का कर्ज़) बन जाते हैं और किसी के on-call incident में बदल जाते हैं
  • मुख्य बात यह नहीं कि "companies को सख्त होना चाहिए और solo devs को ढील मिल सकती है", बल्कि यह कि स्थिति के अनुसार review का उद्देश्य बदलता है, इसलिए नियम भी बदलने चाहिए
  • 2 लोगों के prototype पर enterprise-style multi-agent और evidence-required pipeline लगाना बेकार friction है; वहीं payment system पर "tests pass हो गए, deploy कर दो" लागू करना हरे checkmark वाला incident generator है

आज review वास्तव में क्या कर रहा है

• जब इंसान code लिखता था, तो intent साथ में मुफ़्त आता था; जिन विकल्पों को उसने तौला और छोड़ा, वे उसके दिमाग में मौजूद होते थे, इसलिए review का काम उस reasoning को जांचना होता था
• आधुनिक agents भी reasoning करते हैं और अक्सर अपनी thinking trace को दिखाते भी हैं, लेकिन diff बनते ही वह reasoning फेंक दी जाती है और PR के साथ attach नहीं होती
• और वह reasoning भी अक्सर सिर्फ "इसे कैसे implement किया जाए" तक सीमित होती है, न कि "क्या यह शुरू से सही काम है" जैसी मानवीय judgment तक
• नतीजा यह है कि review सामने मौजूद reasoning की जाँच से बदलकर अलिखित intent के reconstruction में बदल जाता है, जिससे यह ज़्यादा कठिन और धीमा हो जाता है — इसी वजह से 441% ज़्यादा समय लगता है

• AI Slop and the Software Commons (2026 paper)

  • Reddit और Hacker News की 15 threads के 1,154 posts का analysis
  • एक developer के शब्दों में, agent PR review उसे "इस code को पहली बार देखने वाला इंसान" बना देता है
  • paper के अनुसार review को "गायब intent को recover करने के लिए design नहीं किया गया था"

• समाधान एक tooling problem है

  • गायब intent recover किया जा सकता है — reasoning मौजूद थी, बस फेंक दी गई
  • अगर agent से यह कहलवाया जाए कि उसने क्या करने की कोशिश की और क्या विकल्प छोड़े, और उसे PR के decision log के रूप में capture किया जाए, तो reconstruction cost का बड़ा हिस्सा गायब हो सकता है
• सिर्फ "AI से AI की review" अपने आप में पूरा जवाब नहीं है; अलग prior knowledge वाला दूसरा model कई वास्तविक bugs पकड़ सकता है, लेकिन "क्या यह बदलाव बनाना ही चाहिए था" जैसी मानवीय judgment नहीं दे सकता

tools अच्छे हैं, लेकिन ठीक उस वजह से नहीं जिस तरह वे खुद को बेचते हैं

• dedicated AI review tools अब काफ़ी अच्छे हो चुके हैं, और side projects सहित हर चीज़ पर कम-से-कम मुख्य coding agent, और संभव हो तो dedicated review agent चलाने की सिफारिश की जाती है

• प्रमुख tools की विशेषताएँ

  • CodeRabbit: सबसे व्यापक रूप से deployed, स्वतंत्र Martian benchmark (जनवरी~फ़रवरी 2026) में F1 में प्रथम, लगभग 49% precision के साथ industry-best recall
  • Greptile: precision छोड़कर recall हासिल करता है; एक benchmark में bug detection rate लगभग 82% (CodeRabbit के 44% के मुकाबले), लेकिन false positives अधिक
  • Anthropic Code Review: उसके अपने engineers ने जिन findings को error कहा, वे 1% से कम थीं, और वास्तव में review प्राप्त करने वाले PR का अनुपात 16% से 54% तक बढ़ा

• 4 reviewers parallel experiment (vendor के बाहर के results)

  • एक engineer ने 3.5 हफ्तों तक वास्तविक 146 PR और 679 findings पर CodeRabbit, Sentry Seer, Greptile और Cursor BugBot को parallel चलाया
  • 617 unique flagged locations में 93.4% सिर्फ एक tool ने पकड़ीं; 6% दो tools ने, तीन tools द्वारा लगभग कुछ नहीं, और चारों ने मिलकर एक भी नहीं
  • चारों tools ने कभी भी एक ही line को साथ में flag नहीं किया
  • हर tool की अपनी ताकत थी: Greptile correctness और architecture में लगभग zero false positives, CodeRabbit सबसे चौड़ा जाल और one-click fixes, Seer operational outage severity में मज़बूत
  • यहाँ heterogeneity ही असली बात है — एक ही model की चार copies सिर्फ बड़ा bill देती हैं; सचमुच अलग चार reviewers ऐसे bugs दिखाते हैं जो कोई अकेला नहीं पकड़ता

• practical guidance

  • किसी एक best tool की तलाश न करें (ऐसा कोई नहीं है)
  • high-risk क्षेत्रों में जानबूझकर अलग स्वभाव वाले दो tools साथ चलाएँ (ऊपर के experiment में रोज़मर्रा की correctness के लिए Greptile + operational outage severity के लिए Seer)
  • अगर आप solo हैं, तो एक अच्छा reviewer और वास्तविक tests काफ़ी हो सकते हैं
  • marketing से अलग, अपनी खुद की codebase पर मापना ज़रूरी है, क्योंकि हर result किसी खास codebase तक सीमित होता है

क्या AI को review का ज़्यादा हिस्सा सौंप देना चाहिए

• एक साल पहले यह सवाल लगभग विधर्म जैसा लगता, लेकिन अब अनुभवी engineers यही पूछ रहे हैं — क्या machines को review का ज़्यादा, शायद अधिकांश, हिस्सा संभालना चाहिए?

• AI review के काम करने का असहज सच

  • Anthropic की findings में 1% से कम गलत चिह्नित थे; AI उन bugs को पकड़ लेता है जो इंसान छोड़ देते हैं, और दिन के 30वें PR पर भी नहीं थकता — वही समय जब इंसान सबसे कम भरोसेमंद होता है
  • दूसरी ओर इंसान pace बनाए नहीं रख पा रहे — बिना review merge 31% बढ़े, review time तीन-अंकीय प्रतिशत में बढ़ा
  • ईमानदार framing यह नहीं है कि "क्या AI को ज़्यादा करना चाहिए", बल्कि यह है कि "AI तो पहले से कर रहा है; सवाल यह है कि क्या हम इसे जानबूझकर करेंगे, या ऐसे दिखावा करते रहेंगे कि इंसान सब पढ़ रहे हैं"

• Loop engineering का नज़रिया

  • loop की मूल धारणा यह है कि agent को prompt देने वाले इंसान से आगे बढ़कर agent को prompt देने वाली system बनाई जाए, और उसके केंद्र में यह तय करने वाला judge agent हो कि काम पूरा हुआ या नहीं
  • तब reviewer को design के अनुसार inner loop से हटाया जाने लगता है; writing के automation के एक साल बाद verification भी automate होने लगता है, और इंसान ऊपर की परत में धकेल दिया जाता है

• बंद loop का जोखिम

  • अगर एक agent लिखे, दूसरा review करे और तीसरा निर्णय दे, तो यह correlated blind spots वाले models का बंद loop बन जाता है — खासकर जब वे एक ही family के हों और एक ही जगह आत्मविश्वास से सहमत हो जाएँ
  • बिना इंसान के आत्मविश्वास भरा "looks good" दरअसल borrowed confidence है — system का confidence हमारा confidence बन जाता है, जबकि वास्तव में किसी ने भी पूरी चीज़ नहीं समझी

• इंसान गायब नहीं होता, एक स्तर ऊपर जाता है

  • हर diff पढ़ने से हटकर, इंसान उस हिस्से का owner बनता है जो models को transfer नहीं किया जा सकता; accountability यहीं महत्वपूर्ण हो जाती है
  • इंसान के लिए सुरक्षित रखा जाने वाला क्षेत्र: क्या यह सही बदलाव है, अगर गलत हुआ तो महँगे high-blast-radius gates, और वह behavior जिसे किसी ने spec ही नहीं किया है (models मौजूदा code की review करते हैं; जो requirements लिखी ही नहीं गईं, उन्हें वे मुश्किल से flag करते हैं)
  • human in the loop से human on the loop तक — हर PR पढ़ने के बजाय system को sample, spot-check और audit करना, और सीमित attention को वहीं लगाना जहाँ गलती सचमुच दर्द देती है

• Kun Chen का case (पूर्व Meta L8 engineer, solo builder)

  • वह रोज़ लगभग 40 PR ship करता है और उसने लगभग code review बंद कर दी है; 20~30 agents को parallel चलाता है
  • उसका effort plan पर shift हो गया है — वह पहले से detailed plan लिखता है, agents घंटों तक चलते हैं, और plan की quality यह तय करती है कि unmonitored execution कितनी देर चल सकती है
  • उसने verification नहीं छोड़ा; उसने intent पहले ही लिख दिया, जिससे "code को पहली बार देखने वाला इंसान" वाली समस्या आधी हल हो जाती है, क्योंकि इंसान बाद में नहीं बल्कि पहले से कारण समझता है
  • वह safety net के बिना काम नहीं करता — merge से पहले code की जाँच करने वाला automatic review gate, जिसे वह No Mistakes कहता है, हमेशा मौजूद रहता है; agent अटकने पर escalation का इंतज़ार करता है
  • लेकिन वह solo builder है, न बड़ी टीम है न 10 साल पुराना minefield system; उसकी परिस्थितियाँ अधिकांश पाठकों जैसी नहीं हैं — अगर उसकी शैली को multi-user teams पर कॉपी किया गया, तो Faros के numbers सीधे आपके dashboard पर दिखाई देंगे
• spectrum का निष्कर्ष: solo और no-user स्थिति में AI को लगभग सब कुछ सौंपना 2026 में बचाव योग्य रुख हो सकता है; बड़े और multi-user माहौल में पहला और दूसरा pass, और उबाऊ 90%, machines करें, लेकिन load-bearing paths पर वास्तविक इंसान बनाए रखें; कितना मानवीय review रखा जाए, यह guilt नहीं बल्कि blast radius से तय होने वाला dial है

वास्तव में क्या करना चाहिए

• संगठनात्मक सिद्धांत: review effort को गलती की लागत के अनुसार align करें, सस्ते deterministic काम को जितना हो सके आगे खींचें, और मानवीय attention को उन कामों के लिए reserve करें जो सिर्फ इंसान कर सकता है

• author नहीं, risk के आधार पर tiers बनाएँ (Tier by risk, not by author)

  • config changes के लिए linter और एक बार सरसरी नज़र काफ़ी है
  • core business logic paths में बदलाव के लिए full stack चाहिए: types, tests, एक-दूसरे से अलग दो AI reviewers, उस system का human owner, और security pass
  • boilerplate पर भारी review बर्बाद न करें, और सिर्फ tests के green होने पर बड़े changes पास न करें

• महँगी tail को जल्दी fail करें (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (जनवरी 2026) में agent-authored 33,707 PR का अध्ययन
  • agents छोटे और अच्छी तरह परिभाषित changes में अच्छे हैं, इसलिए लगभग 28% PR लगभग तुरंत merge हो जाते हैं; लेकिन subjective feedback मिलते ही वे अक्सर "ghost" हो जाते हैं और review की असली back-and-forth प्रक्रिया छोड़ देते हैं
  • संबंधित 2026 paper में reviewer attrition rejected agent PR का 38% पाया गया
  • researchers ने file type और patch size जैसे सस्ते signals से ऐसे high-maintenance PR को इंसान द्वारा देखे जाने से पहले predict करने वाला "circuit breaker" बनाया, और यह अच्छा चला

• review के योग्य होने की threshold ही बढ़ाइए

  • समाधान repository को lock करना नहीं, बल्कि बिना evidence आए changes की review ही अस्वीकार करना है
  • review से पहले अपेक्षित चीज़ें: बदलाव के उद्देश्य का statement, बिना annotation वाला 3,500-line का dump नहीं बल्कि diff, test output, और इसे वास्तव में run किया गया इसका evidence
  • intent reconstruction का महंगा काम खुद absorb करने के बजाय उसे submitter के पास वापस भेजिए, जो इसे कम लागत पर कर सकता है

• PR को जानबूझकर छोटा रखें

  • agent PR बड़े निकलते हैं (Faros data में average 51% बड़े), और reviewer engagement PR merge होने का सबसे मज़बूत predictors में से एक है
  • बड़े और review न किए जा सकने वाले PR या तो तुरंत reject होते हैं, या उससे भी बुरा, rubber-stamp हो जाते हैं
  • agent को छोटे commits बनाने के लिए निर्देश दें; इंसान द्वारा वास्तव में पढ़ा जा सकने वाला diff अब शिष्टाचार नहीं, बल्कि design constraint है

• code से ज़्यादा test changes को ध्यान से पढ़ें

  • एक देखने लायक agent failure mode: behavior बदलने के बाद assertions को नए टूटे behavior के अनुरूप फिर से लिखकर test को "ठीक" कर देना
  • 200 edited tests के ऊपर green check का कोई मतलब नहीं, जब तक आप यह verify न कर लें कि edits सही थे; ऐसे diff जिनमें बहुत सारे tests फिर से लिखे गए हों, उन्हें flag मानकर पहले पढ़ें
  • mutation testing का मूल्य: coverage बताती है कि line चली या नहीं, mutation testing बताती है कि अगर वह line गलत हो तो test उसे पकड़ेंगे या नहीं

• CI को हिलाई न जा सकने वाली दीवार समझें

  • GitHub जिन patterns पर reviewers को चेतावनी देता है, उन पर नज़र रखें: हटाए गए tests, skipped lint, कम किए गए coverage thresholds, पहले से मौजूद helpers की duplicate copies, और prompt में बहने वाला untrusted input
  • आख़िरी बिंदु पर विशेष ज़ोर — agent-built features prompt injection का नया source हैं; अगर user-controlled text को सीधे LLM call में भेजा गया, तो vulnerability diff में नहीं दिखेगी, बल्कि बाद में आने वाले data में छिपी रहेगी
  • agents pass होने के लिए बुरे इरादे से नहीं, फिर भी CI को कमजोर कर देते हैं, क्योंकि gradient descent हरे check तक पहुँचने का सबसे सस्ता रास्ता खोजता है; deterministic gates ही ऐसी चीज़ हैं जिनके निर्णय को आत्मविश्वासी paragraphs पलट नहीं सकते, इसलिए उन्हें सख़्त रखें

• merge का owner इंसान हो

  • model को on-call page नहीं किया जा सकता और न ही उससे accountability ली जा सकती है, इसलिए merge button दबाने वाला इंसान ही owner है
  • जब AI review शांत और आत्मविश्वासी स्वर में "looks good" कहता है, तो वह अक्सर ऐसा confidence देता है जो अर्जित नहीं किया गया
  • हर AI review को verdict नहीं, sensor की तरह लें — निर्णय नहीं, data

अगर आप टीम चला रहे हैं, तो इसका क्या मतलब है

• shipping की binding constraint अब यह नहीं रही कि code कितनी जल्दी लिखा जा सकता है, बल्कि यह है कि जिस इंसान पर भरोसा है वह बदलाव की correctness को कितनी जल्दी लेकर आश्वस्त हो सकता है
• generation को bottleneck मानकर review को मुफ़्त समझने वाली planning speed dashboards को हरा रखती है, लेकिन भीतर ही भीतर ठहराव पैदा करती है
• Faros report स्पष्ट रूप से कहती है कि output बढ़ने के साथ QA और review work भी बढ़ता है; review gap बंद किए बिना "AI से हम तेज़ हो गए" कहकर engineering headcount घटाना खतरनाक है
• तीन-अंकीय प्रतिशत से बढ़ा review time एक senior engineer tax है, और यह सबसे भारी बोझ उन्हीं लोगों पर डालता है जिन्हें bottleneck नहीं बनना चाहिए; merged PR गिनने वाले metrics में यह दिखाई भी नहीं देता
• open source maintainers इस दीवार से सबसे पहले और सबसे ज़ोर से टकरा रहे हैं — plausible लेकिन खोखले contributions की लगातार धारा, चाहे सद्भावना से आए, वास्तविक triage time खाती है; यह कोयला खदान की कैनरी है, enterprise अगला है
• जो टीमें अच्छा करती हैं, वे review capacity को AI द्वारा खुली अतिरिक्त जगह नहीं, बल्कि ऐसा वास्तविक संसाधन मानती हैं जिसे मापा, संरक्षित और जानबूझकर खर्च किया जाना चाहिए

लिखना सस्ता हुआ, समझना नहीं

• किसी भी छोर की एकसमान सलाह न मानें — solo और no-user संदर्भ में enterprise के churn और duplication वाले डरावने किस्से आज की आग नहीं, बल्कि भविष्य का जोखिम हैं; इसलिए tests पर भरोसा करें, केवल अहम चीज़ों की review करें, लेकिन ईमानदारी से मानें कि defer किया गया काम अब भी कर्ज़ है
• बड़े और multi-user संदर्भ में यहाँ दिए गए सभी warning metrics सीधे आपकी कहानी हैं; एकमात्र काम की चीज़ है risk-based tiering, evidence की मांग, जानबूझकर heterogeneous review process, और merge की स्पष्ट human ownership
• पूरे spectrum में जो नहीं बदलता, वह बुनियादी economics है — writing सस्ती हुई है, लेकिन understanding उतनी ही महंगी बनी हुई है जितनी हमेशा थी
• आगे चलकर वही टीमें अच्छा करेंगी जो सबसे ज़्यादा code generate नहीं करतीं, बल्कि ऐसा review system बनाती हैं जिस पर सचमुच भरोसा किया जा सके; जो कभी भी "tests pass हो गए" और "इंसान समझता है कि यह क्या और क्यों कर रहा है" को एक नहीं मानतीं
• Simon Willison के शब्दों में, काम का सार ऐसा code सौंपना है जिसके काम करने का प्रमाण हो — agents ने इसे नहीं बदला, उन्होंने सिर्फ proof को एक साइड-task से उठाकर काम के केंद्र में ला दिया है
• किसी system को इतनी गहराई से समझने की क्षमता कि आप उसके पीछे खड़े हो सकें, software की सबसे टिकाऊ और रोचक skills में से एक है, और इसे बेहद अच्छी तरह सीखने का यह शायद सबसे सही समय है