अगर आप code review अच्छी तरह करते हैं, तो AI agents को भी अच्छी तरह संभाल सकते हैं

 (seangoedecke.com)
15 पॉइंट द्वारा GN⁺ 2025-09-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI agents का उपयोग करने में दक्ष होने के लिए code review skill महत्वपूर्ण है
  • बड़े language models code generation में अच्छे हैं, लेकिन उनमें गहरी निर्णय क्षमता की कमी होती है, इसलिए वे अक्सर गलत दिशा में समय बर्बाद करते हैं
  • केवल बारीक syntax पर टिप्पणी करने वाले तुच्छ review या बिना आलोचना के स्वीकृति देने वाले rubber-stamp review AI उपयोग में मदद नहीं करते
  • अच्छा code review संरचनात्मक दृष्टिकोण को शामिल करता है, यह परखता है कि कोई बेहतर तरीका है या नहीं, और जटिल design से बचने में मदद करता है
  • अंततः AI coding “centaur chess” की तरह एक मॉडल है, जो मानवीय निर्णय और मशीन की उत्पादकता को जोड़ता है, और code review की क्षमता सीधे AI उपयोग की क्षमता में बदल जाती है

AI agents और code review का संबंध

  • AI agents का सही उपयोग करना वास्तव में code review process ही है
  • जो लोग code review अच्छी तरह करते हैं, वे Claude Code, Codex, Copilot जैसे AI code tools का भी प्रभावी उपयोग करते हैं

code review skill क्यों महत्वपूर्ण है

  • बड़े language models बहुत सारा code generate करने में सक्षम हैं, लेकिन अनुभवी software engineers जैसी निर्णय क्षमता अभी उनमें नहीं है
  • इसलिए अगर उन्हें बिना supervision के छोड़ दिया जाए, तो वे अनावश्यक या खराब design पर बहुत सारे resources बर्बाद करने की प्रवृत्ति रखते हैं

AI agents की सीमाएँ और design errors

  • उदाहरण के तौर पर, VicFlora Offline project के विकास के दौरान Codex ने frontend code को reverse-engineer करने में बहुत मेहनत लगाई
    • जबकि वास्तव में data तक पहुँचने का एक अधिक सरल तरीका मौजूद था
    • AI agent का उपयोग करते समय लगभग हर घंटे कोई न कोई संदिग्ध काम करते हुए देखा जा सकता है
    • ऐसी समस्या दिखने पर अगर आप खुद दिशा बदल दें, तो कई घंटों का काम बचाया जा सकता है
  • एक अन्य app development अनुभव में, AI ने साधारण parallel processing के काम के लिए भी जरूरत से ज्यादा background infrastructure बनाने का प्रस्ताव दिया
    • जबकि केवल frontend में non-blocking तरीके से संभालना ही काफी था, फिर भी वह जटिल architecture लाना चाहता था
    • सरलता बनाए रखने के लिए AI को लगातार नियंत्रित करना महत्वपूर्ण है
  • अगर गैर-विशेषज्ञ सिर्फ AI पर भरोसा करके development करते हैं, तो codebase की जटिलता और inefficiency बढ़ती जाती है, और समस्या हल करने की क्षमता उल्टा तेज़ी से घट सकती है

code review का सार और उसका प्रभाव

  • AI के साथ collaboration करना उत्साही लेकिन अनुभवहीन junior developer के साथ काम करने जैसा है
    • AI की निर्णय क्षमता समय के साथ बढ़ती नहीं है, इसलिए लगातार निगरानी आवश्यक है
  • code review में सबसे बड़ी गलती यह है कि केवल लिखे गए code को देखा जाए, और यह न सोचा जाए कि कोई बेहतर विकल्प है या नहीं
    • सबसे अच्छा code review संरचनात्मक दृष्टिकोण से पूरे system context को एकीकृत रूप में देखता है
    • नया और अनावश्यक system बनाने की बजाय मौजूदा system का पुन: उपयोग प्राथमिकता होनी चाहिए
  • केवल code style की बारीकियों पर अटके रहने वाले 'nitpicky' reviewer, AI tools के वास्तविक उपयोग का अवसर खो सकते हैं
  • 'rubber-stamp' reviewer की तरह बिना आलोचना सब पास कर देना, AI/junior developer के साथ प्रभावी collaboration को कठिन बना देता है

AI tools के उपयोग कौशल पर विचार

  • git जैसे पारंपरिक tools की स्पष्ट संरचना और उपयोग विधि होती है, लेकिन AI की बुनियादी संरचना अपारदर्शी है
    • AI लगभग हर तरह की computation कर सकता है
  • कुछ लोग मानते हैं कि AI tools का हर दिशा में उपयोग करना ही AI skill है
    • वास्तव में, अनुभवी उपयोगकर्ता इससे कहीं अधिक संभावनाएँ निकाल सकते हैं
  • अभी तक AI code agents कई तरह के कामों में मदद कर सकते हैं, लेकिन करीबी supervision की जरूरत रहती है
  • "centaur chess" मॉडल की तरह, जब अनुभवी इंसान की दिशा और AI के सुझाव मिलते हैं, तो सर्वोत्तम productivity हासिल की जा सकती है
  • AI उपयोग की वास्तविक क्षमता अंततः code review skill और आलोचनात्मक design judgment पर निर्भर करती है
  • जितनी अच्छी code review skill होगी, agentic AI tools का प्रभाव उतना अधिकतम होगा

अंतिम विचार और आगे की दिशा

  • AI agents समय के साथ ऐसा महसूस करा सकते हैं मानो वे धीरे-धीरे अधिक अनुभवी engineer जैसे बन रहे हों
  • आने वाले कुछ वर्षों में AI के साथ collaboration का अनुभव mid-level engineer के साथ काम करने के स्तर तक विकसित हो सकता है
  • अभी के लिए Codex, Claude Code, Copilot जैसे विभिन्न AI tools के साथ प्रयोग करना उपयोगी है, और आलोचनात्मक supervision skill सबसे महत्वपूर्ण अंतर पैदा करने वाला तत्व है

अतिरिक्त राय

  • Hacker News आदि में इस पर चर्चा हुई है कि “AI agents किस स्तर तक उपयोगी हैं”
    • लेखक का मानना है कि केवल code review के आधार पर AI, Linux kernel स्तर का योगदान नहीं दे सकता
    • कुछ लोगों का यह भी मत है कि style और naming जैसी code review विधियाँ भी महत्वपूर्ण हैं
    • code review में design discussion होने पर आलोचनात्मक दृष्टि मौजूद है, लेकिन लेखक इसे नकारात्मक नहीं मानते

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

1 टिप्पणियां

 
GN⁺ 2025-09-23
Hacker News राय

  • यह मानना काफ़ी संदिग्ध है कि खराब process में भी अगर quality control अच्छा हो तो अच्छे नतीजे आ सकते हैं — जैसे, "चाहे लगातार कबाड़ निकलता रहे, बस कोई उसे चेक कर ले तो ठीक है"। असल दुनिया में मैंने इसे काम करते नहीं देखा। अमेरिकी ऑटो उद्योग में ऐसा करने की कोशिश हुई थी, लेकिन कोई सफल उदाहरण याद नहीं आता। कल्पना कीजिए, मैं टीम लीड हूँ और मेरा मैनेजर मुझसे कहे, "5 सक्षम लोगों की जगह 25 बिल्कुल नए लोगों को रख लेते हैं, शायद किस्मत से कुछ सही निकल आए, तुम सब review कर लेना।" यह पूरी तरह बेतुकी बात लगेगी। लेकिन जैसे ही इस scenario में AI आ जाता है, बहुत से लोग सोचने लगते हैं, "हूँ? शायद यह चल जाए?" यही बात अजीब लगती है.

    • कम अनुभवी या कम प्रेरित लोगों के code का review करना भी बहुत थकाने वाला होता है। मानसिक और भावनात्मक, दोनों तरह की भारी energy लगती है। एक ही feature को 4 बार review करते-करते आप ऊब जाते हैं, और फिर quality जिस स्तर तक जा सकती थी उससे पहले ही हार मान लेते हैं.

    • यह Edward Deming द्वारा जापान में विकसित और पश्चिम में फैलाए गए quality management के आदर्श के बिल्कुल उलट है। quality लोगों से नहीं, process से आती है। अगर आपने जानबूझकर defect-heavy process चुना है और उम्मीद करते हैं कि इंसान बाद में गलतियाँ पकड़ लेंगे, तो quality आपका लक्ष्य हो तो यह बिल्कुल अच्छी पद्धति नहीं है। LLM का कई तरह से इस्तेमाल हो सकता है, लेकिन उनमें से सिर्फ कुछ ही वास्तव में फ़ायदेमंद हैं। management इस भ्रम में है कि AI हर समस्या हल कर सकता है, और लगता है कि या तो वे AI की strengths और limitations समझते नहीं, या Deming की सीख भूल चुके हैं.

    • evolution भी random mutation और selection का ही मामला है, और जटिल जीवन का अस्तित्व खुद उसका उदाहरण है। यह मेरा पसंदीदा तरीका नहीं है, लेकिन लोग trending buzzword पर इतने मोहित हो जाते हैं कि जहाँ फिट न बैठे वहाँ भी उसे ठूँसने लगते हैं। कुछ kitchen products के plastic parts आज भी ऐसे बनते हैं कि पहले खराब quality में ढाले जाते हैं, फिर दिहाड़ी मज़दूर उन्हें चाकू से हाथ से ठीक करके पैक करते हैं। मैंने खुद ऐसी temporary नौकरी की है। semiconductors में chip binning / yield management को भी बहुत ऊँचे failure rate वाले उदाहरण के रूप में देखा जा सकता है। आसपास देखें तो संदिग्ध process कोई अपवाद नहीं, बल्कि रोज़मर्रा की बात है.

    • जैसे ही आप खुद को "AI को अच्छी तरह संभालने वाला" मानने लगते हैं, एक भ्रम पैदा होता है कि "अब मैं जिन समस्याओं को हल कर सकता हूँ, उनका दायरा बहुत बढ़ गया है"। यह हर general-purpose technology के साथ होता है। पहले genetic algorithm के craze में भी ऐसा ही था। हर कोई कोई 'general-purpose' tool ढूँढता है और फिर सोचता है कि उसी से सब कुछ हो जाएगा। असल में वे बिना context के optimization करने लगते हैं। AI इस प्रवृत्ति का और भी चरम उदाहरण है.

    • process कितना भी अच्छा हो, उससे यह सीखना संभव नहीं कि वास्तव में काम करने वाला system कैसे बनाया जाए। बार-बार जो pattern दिखता है वह यह है कि टीम लंबे समय तक भटकती रहती है, और अंत में वही engineer जिसे सच में समस्या हल करना आता है, खुद आगे बढ़कर सही दिशा तय करता है.

  • AI से required parameters का पालन करवाना सच में बहुत मुश्किल है। वह हमेशा किसी अजीब random दिशा में भटक जाता है। nftables highlighting पर काम करते समय 230 tokens, 2,500 states, और 50,000 से ज़्यादा state transitions थे। AI को पाँच साफ़ rules देने पर भी वह हर बार किसी random जगह पर उनसे हट जाता था। सिर्फ coding output ही नहीं, बहुत simple Vimscript भी ठीक से नहीं बना पाता। आखिरकार मैं AI का इस्तेमाल सिर्फ documentation के लिए करता हूँ। फिर भी 'rule', 'chain_block stmt', 'map_stmt_expr' जैसी चीज़ों को तोड़कर समझाने में AI अब काफ़ी अच्छा होने लगा है। मुझे बस अपनी ज़रूरत के syntax patterns copy-paste करने होते हैं.

  • AI code generation project की शुरुआती stage में काफ़ी useful है, लेकिन mature projects के लिए चिंताजनक बातें हैं। हाल ही में 280K+ LOC का Postgres parser Multigres में merge किया गया, और वह public review के बिना हुआ। open source ecosystem में यह सावधानी की बात है। बहुत से लोग सीखने और reference के लिए ऐसे projects पर निर्भर करते हैं, और अगर ठीक review के बिना AI code शामिल होने लगे तो उनकी educational value और dependency पर trust दोनों कमज़ोर पड़ते हैं। code review सिर्फ bugs पकड़ने के लिए नहीं होता; यह collaborators के सीखने, design decisions समझने, और collective knowledge बनाने का मुख्य साधन है। समस्या speed नहीं, बल्कि knowledge transfer process की है। वैसे PR public होने में लगे समय के बारे में यह लिंक देखें.

    • मैंने इस काम की निगरानी की थी, और बेहतर दिशा पर feedback हमेशा स्वागतयोग्य है। यह स्थिति खास इसलिए थी क्योंकि इसमें LLM का उपयोग करके Postgres C parser का translation किया गया था। इस पैमाने पर line-by-line review करना संभव नहीं था, इसलिए consistency सुनिश्चित करने के लिए अलग procedure बनाया गया। दो महीने तक रोज़ बारीकी से जाँच हुई। Postgres के ज़्यादातर tests लाकर सफलतापूर्वक port किए गए, इसलिए operational reliability भी अच्छी तरह सुनिश्चित हुई। Multigres अभी बहुत शुरुआती stage में है, इसलिए आगे Vitess जैसे और projects में large-scale copy/translation की कोशिशें होंगी। सुधार के सुझाव अपनाए जाएँगे। लेखक पूरी प्रक्रिया समझाने वाला blog भी तैयार कर रहे हैं, उसे देखना। व्यक्तिगत रूप से मैं LLM की मदद से हासिल हुए नतीजों से काफ़ी चकित था। बेशक कुछ skill ज़रूरी थी, और इस व्यक्ति ने यहाँ दिए गए benchmarks भी पार कर लिए.

  • मेरा process लगभग ऐसा है

    1. AI को requirements देना
    2. AI से कहना कि वह मुझसे unclear points पर सवाल पूछे
    3. जब उसके सवाल खत्म हो जाएँ, तो उससे requirements को formal PRD के रूप में दोबारा लिखवाना
    4. मैं critique करता हूँ
    5. उससे दो alternative architectures प्रस्तावित करवाना
    6. मैं एक चुनकर उसकी आलोचना करता हूँ
    7. उससे दो detailed TODO lists बनवाना
    8. मैं एक चुनकर उसकी आलोचना करता हूँ
    9. TODO में से किसी एक के लिए दो implementation approaches बताने को कहना
    10. मैं एक चुनकर उसकी आलोचना करता हूँ
    11. फिर 9 पर वापस
      बीच-बीच में snapshots लेकर पीछे भी लौट जाता हूँ।
      इस तरह, भले ही शानदार स्तर का न सही, कम से कम मेरी implementation के लिए baseline बनने लायक output मिल जाता है।
      नुकसान यह है कि इसमें बहुत ज़्यादा समय लगता है, और 80% मामलों में लगता है कि अगर मैं शुरू से सब खुद कर लेता तो ज़्यादा तेज़ होता.

    • यह अकेले करने से भी धीमा लगता है। AI coding का अनुभव वैसा है जैसे किसी mid-level developer ने वीकेंड की रात पीते-पियाते आपके notes के आधार पर कुछ improvisation कर दिया हो और अब आपसे कहे, "देखो, मैंने कुछ बना दिया, कैसा है?" आप बस कहते हैं, "NO, यह पसंद नहीं आया," और अगर direction मोटे तौर पर ठीक हो, तो उसे refactor करते हुए Monday morning से शुरू करने की तुलना में थोड़ा समय बचता है.

    • ऐसे step-by-step guides हर बार देखने पर लगता है कि यह तो बस बहुत बड़ी झंझट जोड़ देता है, और AI से जिस efficiency की उम्मीद थी वह खत्म हो जाती है। मेरे अनुभव में यह लगभग सच है। हाँ, कुछ पल ऐसे होते हैं जब AI मददगार होता है, लेकिन कब और कहाँ वह उपयोगी होगा, यह पहचानना भी अपने आप में एक अहम skill है.

    • मैं थोड़ा lower layer पर काम करता हूँ, और आमतौर पर मेरा तरीका यह होता है:

      • basic interface खुद बनाता हूँ, या अगर पहले से हो तो अगले चरण पर जाता हूँ
      • LLM को autocomplete tool की तरह इस्तेमाल करता हूँ
      • requirements लिखता हूँ और बताता हूँ कि कौन-सी entry-point files बदलनी हैं
      • goal एक साथ पूरा नहीं देता, हर बार सिर्फ एक step देता हूँ
      • जैसे ही कुछ गलत होने के संकेत मिलें, तुरंत बीच में दखल देकर रोक देता हूँ, या अगर AI गलत हो तो दिशा ठीक करता हूँ
        आम तौर पर जब बहुत broad और लंबे goals एक साथ दे दिए जाते हैं, तो agent अक्सर काम पूरा होने के बिंदु को ही गलत समझ लेता है.

    • मैं भी कुछ ऐसा ही, बस थोड़ा simplified process इस्तेमाल करता हूँ। PRD देता हूँ, rough architecture भी बता देता हूँ, फिर हर component को मनचाहे तरीके से implement करने को कहता हूँ। समय अभी भी बहुत लगता है, और खुद करना शायद तेज़ होता, लेकिन अब हाथ से लाइन-दर-लाइन code लिखना झंझट लगता है, इसलिए सोचता हूँ कि LLM से function level पर करवाऊँ.

    • अगर मैं AI का इस्तेमाल सिर्फ rough approach, libraries, या language features समझने के लिए करता, और असली काम खुद करता, तो शायद मैं बहुत तेज़ होता.

  • अगर आप code review अच्छे से कर सकते हैं, तो शायद AI agents का इस्तेमाल ही न करना बेहतर हो.

    • मैंने खुद उन साथियों का code review किया है और bugs ठीक किए हैं जो Claude Code जैसे agents के प्रेम में पड़ गए थे। मेरा अनुभव यह रहा कि code अक्सर ऐसा लगता था जैसे किसी hallucination में लिखा गया हो, और जिसने लिखा वह उसके बारे में कुछ ठीक से समझा भी नहीं पाता था। फिर भी, मुझे यकीन है कि कुछ लोग सच में बहुत अच्छा code बनाते होंगे, लेकिन मैंने जो देखा वह सब निराशाजनक था। अच्छा यह है कि कुछ लोगों ने खुद ही यह समझ लिया और फिर सही तरीकों पर लौट आए। आजकल agent-based workflows से निकलने वाले output को अगर आलोचनात्मक नज़र से देखें, तो जवाब काफ़ी साफ़ है। जो लोग code review अच्छे से करते हैं, वे इस निष्कर्ष पर और जल्दी पहुँचेंगे.

    • अगर मैं code review में अच्छा हूँ, तो मैं उसी skill को और बेहतर करना चाहूँगा.

  • जो लोग code review बहुत ध्यान से करते हैं, उन्हें AI tools के इस्तेमाल में मुश्किल होती है, और जो लोग ढीले-ढाले review करते हैं, वे AI पर ज़्यादा निर्भर हो जाते हैं।
    यानी, जो लोग code review अच्छे से करते हैं, उनके लिए खुद coding करना बेहतर है। ऐसे projects को लंबे समय तक खुद maintain भी करना होता है, इसलिए उन्हें खुद लिखना ज़्यादा स्वाभाविक है। अगर coding आपको न तो बोझ लगती है और न ही मुश्किल, तो AI इस्तेमाल करने की खास ज़रूरत नहीं। AI का सबसे अच्छा उपयोग तब है जब किसी अनजान tool या नई चीज़ को थोड़ा-बहुत समझना हो। आजकल LLM की वजह से search engine summaries बेहतर हुई हैं, यह मैं मानता हूँ। बेकार documentation में उलझना या असल मुद्दे से असंबंधित बातों में भटकना लगभग शून्य हो गया है.

  • code review भी काम का हिस्सा है, लेकिन यह सबसे कम मज़ेदार हिस्सा है। developers संतोष सीधे coding से लेते हैं। AI tools मददगार हो सकते हैं, लेकिन वे इतने unpredictable और साथ ही इतने convincing लगते हैं कि उनका और ज़्यादा ध्यान से review करना पड़ता है, और इस तरह बोझ बढ़ जाता है। हमने ऐसे tools क्यों बनाए जो मज़ेदार हिस्सा छीन लेते हैं और सिर्फ गैर-मज़ेदार हिस्सा बढ़ा देते हैं? मैं सोचता हूँ, "code review" के लिए dedicated agent कहाँ है?

    • सच कहूँ तो मुझे code 'लिखना' अपने आप में बहुत मज़ेदार नहीं लगता। समस्याएँ हल करना, नई चीज़ें बनाना, systems को तोड़कर बेहतर structure में फिर से जोड़ना — यह ज़्यादा मज़ेदार है। LLM के साथ coding करने पर लगता है कि ideas को छूने-समझने लायक वास्तविक output में बदलने की speed बहुत बढ़ जाती है। existing code में type safety बेहतर हो जाती है, documentation सुधरती है, और complex refactoring आसान हो जाती है। मैं LLM से problem-solving की उम्मीद नहीं करता; मैं उससे context इकट्ठा करने, patterns दोबारा लागू करने, और repetitive code automate करने की उम्मीद करता हूँ। खासकर जब code कई files में बँटा हो और मुझे उन्हें हाथ से न लिखना पड़े, बल्कि AI generate कर दे और मैं सिर्फ हर change verify कर लूँ, तो यह बहुत सुविधाजनक होता है.

    • OpenAI Codex Cloud ने code review feature जोड़ा है, और नया GPT-5-Codex model code review के लिए विशेष रूप से train किया गया है [Codex upgrades का परिचय]। Gemini और Claude में भी GitHub Actions के साथ code review feature और Claude GitHub integration जैसी सुविधाएँ आ गई हैं। GitHub ने भी अपना Copilot Code Review feature launch किया है। CodeRabbit, Greptile, Qodo Merge जैसे dedicated startups भी कई हैं.

    • जिस पल मुझे सच में रोमांच महसूस होता है, वह तब होता है जब implementation करते-करते उसके नीचे छिपी कोई बहुत elegant structure मिल जाती है, जो अब तक के programming के तरीके, बल्कि कभी-कभी जीने के तरीके तक बदल देती है। (हालाँकि ऐसा बहुत कम होता है.)

    • junior developers अक्सर code खुद लिखना पसंद करते हैं, जबकि seniors ज़्यादा code हटाने में आनंद लेते हैं। मेरी नज़र में code review मेरे काम का सबसे मज़ेदार हिस्सा है — कम से कम जब deadline सिर पर न हो। इसलिए यह कहना कि code review मज़ेदार नहीं है, मुझसे सहमत नहीं होता.

    • शुरुआत में कहा गया था कि "ज़्यादातर developers नई चीज़ें बनाना पसंद करते हैं", लेकिन वास्तव में बहुत से लोग दूसरों द्वारा बनाए गए codebase पर patterns और structure समझना और उसे improve करना ज़्यादा पसंद करते हैं। कुछ लोगों के लिए पूरी तरह नई चीज़ बनाना — initial design से लेकर endless iterations तक — ज़्यादा थकाऊ होता है। जहाँ तक इस सवाल का संबंध है कि "हमने मज़ेदार हिस्सा हटाकर सिर्फ उबाऊ हिस्सा क्यों बढ़ा दिया", शायद इसलिए कि focus वहीं किया गया जहाँ productivity gains सबसे ज़्यादा महसूस होते हैं। review AI के लिए CodeRabbit, GitLab Duo जैसे कई विकल्प पहले से मौजूद हैं। RooCode की तरह Git diff देकर भी code review कराया जा सकता है.

  • इस लेख का शीर्षक कुछ ज़्यादा ही सरल लगता है। code review और design review अलग चीज़ें हैं, और AI के साथ कोशिश सिर्फ इन दो तक सीमित नहीं है। AI का उपयोग करने के लिए उस domain का expertise चाहिए। coding को ही लें, तो सिर्फ review skill काफ़ी नहीं; AI को जो भी काम दिया गया हो, उसे validate करने की क्षमता भी चाहिए। विडंबना यह है कि AI सबसे ज़्यादा मदद तब करता है जब मैं किसी ऐसी language या framework से जूझ रहा हूँ जिसे मैं अच्छी तरह नहीं जानता — लेकिन उसी समय मैं deep code review भी नहीं कर पाता। यह भी दिलचस्प है कि AI/LLM युग में "coding" शब्द फिर से लोकप्रिय हो गया है। आजकल कंपनियाँ शायद सिर्फ coder नहीं, बल्कि architecture, requirements analysis, full-stack development और operations सब संभाल सकने वाले engineers चाहती हैं.

    • मेरा आधिकारिक title "Software Engineer" है, लेकिन पिछले 5 साल में मैंने

      1. अपनी टीम के लिए Kubernetes cluster खुद set up और operate किया
      2. Docker का बहुत ज़्यादा इस्तेमाल किया
      3. CI/CD pipelines विकसित कीं
      4. integration और testing अनगिनत बार की
      5. system diagrams सहित requirements documentation बहुत की
      6. वह तरह-तरह के IT काम किए जो infra team नहीं करती
      7. और कभी-कभी code भी लिखा

    • AI agents का सही उपयोग review process जैसा ही है
      क्योंकि LLM बहुत बड़ी मात्रा में code बना सकता है, लेकिन उसमें अभी भी किसी सक्षम software engineer जैसी गहरी judgment नहीं है।
      code को लंबे समय तक गलत दिशा में जमा होने देने से बेहतर है कि course correction जल्दी की जाए। जैसे किसी junior developer के साथ करते हैं, वैसे पहले बड़ी तस्वीर और design पर बात करें, और direction भटकते ही जल्दी रोकें। अगर 100K tokens का code जमा हो जाने के बाद पता चले कि शुरुआती 100 lines ही गलत थीं, तो फिर पूरी चीज़ उखाड़नी पड़ती है.

  • मुझे साथियों के साथ code review करके shared knowledge और standards बेहतर होने का एहसास बहुत पसंद है। लेकिन किसी ज़िद्दी और असहयोगी AI के code का review करने की कल्पना से ही burnout महसूस होता है.

  • कभी-कभी लगता है, अगर मैं अपने काम के सबसे उबाऊ हिस्से में ही बहुत अच्छा हो गया, तो क्या मुझे सारी ज़िंदगी वही करना पड़ेगा? सच कहूँ तो यह पसंद नहीं। और जैसा लेख में भी कहा गया, bugs का शुरू में ही न आना हमेशा बेहतर है; बाद में पकड़ना अपने साथ जोखिम लेकर आता है.