एजेंटिक कोडिंग में डेवलपर की क्षमता की भूमिका

• जैसे-जैसे एजेंट-आधारित coding assistants अधिक सक्षम हो रहे हैं, प्रतिक्रियाएँ बहुत विविध हैं, और कुछ लोग यह दावा करते हैं कि "1 साल के भीतर डेवलपर्स की अब ज़रूरत नहीं रहेगी"
• दूसरी ओर, कुछ लोग AI द्वारा जनरेट किए गए कोड की गुणवत्ता और जूनियर डेवलपर्स को इस बदलते माहौल के लिए कैसे तैयार किया जाए को लेकर चिंता जता रहे हैं
• पिछले कुछ महीनों में Cursor, Windsurf, Cline जैसे एजेंट-आधारित coding helpers का उपयोग किया गया, और ये मौजूदा codebase में बदलाव करने में बहुत प्रभावी रहे
• IDE integration ने विशेष रूप से प्रभावित किया; इसमें tests चलाना और errors को अपने-आप ठीक करना, lint/compile errors का पता लगाना और उन्हें ठीक करना, web search, यहाँ तक कि browser preview फीचर भी शामिल हैं
• डेवलपर और AI के बीच सहयोग का अनुभव बहुत प्रभावशाली है और यह तेज़ी से समस्या सुलझाने तथा features लागू करने में योगदान देता है

• लेकिन फिर भी डेवलपर का लगातार हस्तक्षेप, सुधार और दिशा-निर्देशन आवश्यक था
• कई बार बात वास्तविक commit तक पहुँची ही नहीं, और AI अब भी गैर-तुच्छ कामों के लिए अपने-आप कोड लिखने में पर्याप्त नहीं है
• इसलिए डेवलपर की skills और अनुभव अब भी महत्वपूर्ण हैं, और आगे भी उनका लगातार प्रशिक्षण होना चाहिए

वे क्षण जब डेवलपर को सीधे हस्तक्षेप करना पड़ा

• AI tools ने कुछ क्षेत्रों में लगातार कमजोर प्रदर्शन दिखाया, और यह बात बार-बार सामने आई
• इनमें से कुछ को अतिरिक्त prompts या custom rules से आंशिक रूप से कम किया जा सकता है, लेकिन पूरी तरह नियंत्रित करना संभव नहीं
  • LLM कई बार prompt के निर्देशों का सटीक रूप से पालन नहीं करते
  • coding session जितना लंबा चलता है, परिणामों की consistency उतनी घटती जाती है
• इसलिए नीचे दिए गए उदाहरण ऐसी समस्याएँ हैं जो prompt या settings से अलग भी पर्याप्त रूप से हो सकती हैं
• AI की गलतियों को उनके impact radius के आधार पर 3 श्रेणियों में बाँटा गया है
  • a. डेवलपमेंट स्पीड और commit समय में गिरावट
    • AI उल्टा गति धीमी कर देता है
    • कुछ मामलों में यह unassisted coding से भी कम प्रभावी होता है
  • b. टीम workflow में friction पैदा होना
    • एक iteration के भीतर टकराव या सहयोग-संबंधी समस्याएँ पैदा होना
  • c. लंबी अवधि में code maintainability का कमजोर होना
    • शुरुआत में समस्या न दिखे, लेकिन आगे बदलाव या विस्तार के समय दिक्कतें आएँ
• Impact radius जितना बड़ा होगा, टीम को उस समस्या को पहचानने और ठीक करने के लिए उतना ही लंबा feedback loop झेलना पड़ेगा

Impact radius: commit तक पहुँचने के समय में देरी

• इस श्रेणी में वे मामले आते हैं जहाँ AI मददगार होने के बजाय बाधा बना
• क्योंकि यह विफलता का सबसे साफ़ रूप है, इसलिए यह बहुत बड़ी समस्या नहीं बनती
  • ज़्यादातर मामलों में commit से पहले ही डेवलपर समस्या को पहचानकर रोक सकता है

• काम न करने वाला कोड

  • AI द्वारा बनाया गया कोड मूल रूप से काम ही नहीं करता
  • डेवलपर को इसे सीधे ठीक करना पड़ता है, या AI session बंद करके हाथ से समस्या हल करनी पड़ती है
  • अनुभवी डेवलपर्स जल्दी समझ सकते हैं कि गलती कहाँ हुई और क्या करना है

• समस्या की गलत diagnosis

  • AI समस्या के कारण का गलत आकलन करता है और गलत दिशा में समाधान आज़माने लगता है
  • पिछले अनुभव के आधार पर डेवलपर AI को गलत रास्ते से वापस ला सका

    उदाहरण: Docker build error को architecture setting की समस्या समझकर configuration बदल दी गई
    असली कारण गलत architecture पर बने node_modules की copy थी
    क्योंकि यह पहले भी कई बार हुई समस्या थी, इसे जल्दी पहचानकर ठीक किया जा सका

Impact radius: iteration के भीतर टीम workflow

• इस श्रेणी में वे मामले आते हैं जहाँ review या डेवलपर हस्तक्षेप की कमी के कारण iteration के दौरान टीम के भीतर friction पैदा होता है
• लेखक ने पिछले विभिन्न टीम अनुभवों के कारण ऐसी समस्याओं को commit से पहले ही पहचानकर समायोजित कर लिया
• नए डेवलपर्स भी AI के साथ trial and error से ये सीखें हासिल कर सकते हैं
• लेकिन यदि AI की वजह से coding speed बहुत बढ़ जाती है, तो टीम इन समस्याओं को संभाल नहीं पाएगी

• शुरुआत में ही अत्यधिक काम

  • AI में incremental implementation की बजाय पूरे feature को एक साथ व्यापक रूप से करने की प्रवृत्ति होती है
  • इससे अगर tech choice गलत हो या feature requirements ठीक से समझी न गई हों, तो बहुत सारा काम बेकार जा सकता है

    उदाहरण: frontend stack migration के दौरान पूरे UI components को एक साथ बदलने की कोशिश
    backend के साथ integrated सिर्फ एक component से चरणबद्ध तरीके से शुरू करना चाहिए था

• कारण विश्लेषण के बिना अंधाधुंध समाधान

  • AI समस्या के root cause का विश्लेषण किए बिना, सिर्फ ऊपर-ऊपर दिखने वाली error को ठीक करने की कोशिश करता है
  • बाद में समस्या सँभालने वाले दूसरे टीम सदस्य पर बिना context के समस्या दोबारा समझने का बोझ आ जाता है

    उदाहरण: Docker build के दौरान memory error आने पर कारण ढूँढने के बजाय सिर्फ memory settings बढ़ा दी गईं

• डेवलपर workflow का जटिल होना

  • AI द्वारा बनाया गया build/run तरीका developer experience को खराब करता है
  • अगर इसे तुरंत commit कर दिया जाए, तो दूसरे टीम सदस्यों के workflow पर भी बुरा असर पड़ता है

    उदाहरण: frontend और backend चलाने के commands अलग-अलग दे दिए गए
    उदाहरण: hot reload फीचर गायब था
    उदाहरण: जटिल build settings के कारण डेवलपर और AI दोनों भ्रमित हो गए
    उदाहरण: Docker error को पहले से पहचानने के बजाय build के अंतिम चरण में जाकर संभालने की कोशिश

• गलत समझी गई या अधूरी requirements

  • अगर feature requirements साफ़ न हों, तो AI उन्हें गलत समझकर पूरी तरह दूसरी दिशा में implementation कर सकता है
  • शुरुआत में हस्तक्षेप करके इसे ठीक करना आदर्श है, लेकिन autonomous AI हो या बिना सोचे काम करने वाला डेवलपर, बाद में सुधार की लागत बढ़ जाती है
  • ऐसी गलत implementations बाद में story की प्रगति के दौरान पकड़ी जाती हैं और काफी rework तथा communication cost पैदा करती हैं

Impact radius: लंबी अवधि की maintainability में गिरावट

• यह सबसे छिपा हुआ और खतरनाक impact radius है
  • शुरुआत में कोड सामान्य रूप से काम करता दिखता है, लेकिन बाद में बदलाव और विस्तार करना कठिन हो जाता है
• ऐसी समस्याएँ अक्सर कई हफ्तों या महीनों बाद ही सामने आती हैं
• खासकर इस क्षेत्र में लेखक के 20+ वर्षों के विकास अनुभव ने सबसे बड़ी भूमिका निभाई

• लंबा-चौड़ा और दोहराव वाला test code

  • AI test generation में अच्छा है, लेकिन अक्सर ये समस्याएँ आती हैं:
    • मौजूदा tests में integrate करने की बजाय नई test functions बना देता है
    • जो हिस्से पहले से covered हैं, उन पर भी बहुत ज़्यादा assertions जोड़ देता है
  • नए डेवलपर्स के लिए एक भ्रामक बात: ज़्यादा tests ≠ बेहतर tests
  • duplication जितनी बढ़ती है, maintainability उतनी कठिन होती जाती है, और code बदलने पर बहुत सारे tests fail होने की संभावना बढ़ती है
  • custom commands से इसे कम करने की कोशिश की गई, लेकिन यह अब भी बार-बार होता है

• reusability की कमी

  • AI द्वारा लिखा गया कोड अक्सर कम modular होता है, इसलिए उसे दोबारा इस्तेमाल करना कठिन होता है

    उदाहरण: पहले से मौजूद UI component को पहचान न पाना और उसका duplicate implementation कर देना
    उदाहरण: CSS classes का उपयोग करने के बजाय inline styles का अत्यधिक इस्तेमाल

• ज़रूरत से ज़्यादा जटिल या verbose code

  • AI कई बार ज़रूरत से अधिक कोड बना देता है, इसलिए गैर-ज़रूरी हिस्सों को हाथ से हटाना पड़ता है
  • इससे maintenance cost बढ़ती है और बदलाव करते समय error की संभावना भी बढ़ती है

    उदाहरण: CSS बदलते समय बहुत सारे duplicate styles को एक-एक करके हटाना पड़ना
    उदाहरण: JSON data दिखाने के लिए अनावश्यक रूप से जटिल web component बना देना
    उदाहरण: refactoring के दौरान मौजूदा dependency injection chain को न पहचानना,
    और पहले से inject किए गए value को फिर एक और parameter के रूप में पास करके design को और जटिल बना देना

    • value = service_a.get_value(); ServiceB(service_a, value=value) रूप

निष्कर्ष: क्या AI सारा कोड लिख सकता है?

• अब तक के अनुभव के आधार पर, 1 साल के भीतर AI द्वारा पूरे कोड का 90% स्वायत्त रूप से लिख दिया जाना व्यावहारिक रूप से संभव नहीं
• हालाँकि, कोड लिखने में सहायक भूमिका के रूप में कुछ टीमों और codebases में 90% तक सहायता संभव है
• वास्तव में लेखक 15K LOC के मध्यम-जटिलता वाले प्रोजेक्ट में लगभग 80% तक AI की मदद ले रहा है

AI की गलतियों को रोकने के तरीके

• व्यक्तिगत डेवलपर स्तर पर क्या किया जा सकता है

  • AI द्वारा बनाए गए कोड की हमेशा सावधानी से review करें
    • ऐसा लगभग कभी नहीं होता कि उसमें सुधार की ज़रूरत न हो
  • अगर AI session भ्रमित करने लगे तो उसे तुरंत रोक दें
    • prompt बदलें, या सीधे manual काम पर लौट जाएँ (जिसे कभी-कभी "हैंडमेड coding" भी कहा जाता है)
  • कम समय में चमत्कारिक रूप से बने "विश्वसनीय दिखने वाले" solutions से सावधान रहें
    • उनमें लंबी अवधि की maintenance cost छिपी हो सकती है
  • pair programming अपनाएँ
    • 4 आँखें, 2 दिमाग बेहतर निर्णय देते हैं

• टीम और संगठन स्तर पर प्रतिक्रिया रणनीतियाँ

  • मौजूदा code quality monitoring tools का सक्रिय उपयोग करें
    • उदाहरण: Sonarqube, Codescene
    • AI tools का उपयोग करते समय code duplication, code smells आदि पर और अधिक बारीकी से नज़र रखनी चाहिए
  • Pre-commit hook और IDE-integrated code review सेट करें
    • विकास की शुरुआत में ही समस्याएँ पकड़ने के लिए shift-left strategy को मज़बूत करें
  • अच्छी code quality habits को फिर से स्थापित करें
    • टीम के भीतर AI code से पैदा हुई समस्याओं के उदाहरणों ("Go-wrong log") को साप्ताहिक retrospectives में साझा करें
  • custom rules का सक्रिय उपयोग करें
    • अधिकांश AI tools prompt के साथ भेजे जाने वाले ruleset को configure करने की सुविधा देते हैं
    • टीम मिलकर ruleset को बेहतर बनाकर AI की गलतियाँ कम कर सकती है
    • लेकिन session जितना लंबा होता है, rules को ignore किए जाने की संभावना उतनी बढ़ती है
  • विश्वास और संवाद पर आधारित team culture बनाएँ
    • AI को अपनाना एक नया बदलाव है, और यह समझना चाहिए कि सब अभी सीखने की अवस्था में हैं
    • "AI है, तो और तेज़ काम करो" जैसी दबाव वाली संस्कृति quality risk बढ़ाती है
    • psychological safety वाली टीमों में समस्याएँ साझा करना और उनसे सीखना अधिक सक्रिय रूप से होता है

[bus710]

जो लोग उस टूल का इस्तेमाल कर रहे हैं, वे क्षमता से अलग देखें तो आखिर सभी डेवलपर ही होंगे.... आगे चलकर यह कहकर प्रचार करना कि डेवलपर की ज़रूरत नहीं रहेगी, थोड़ा अजीब लगता है।

[prunusnira]

आगे चलकर क्या होगा, कहना मुश्किल है, लेकिन अभी तो इसे मुख्यधारा में इस्तेमाल करने लायक नहीं लगता... मैंने हाल ही में Cursor इस्तेमाल किया, लेकिन वह basic file import path भी ठीक से नहीं पकड़ पा रहा था। फिर भी, मैं क्या बनाना चाहता हूँ यह कुछ हद तक पहले से अंदाज़ा लगा लेना काफ़ी हैरान करने वाला था।

[daddy]

जब Docker build के दौरान memory error आया, तो शुरुआत में यह पूछने के बजाय कि आखिर इतनी memory इस्तेमाल क्यों हो रही थी, memory setting बढ़ा दी गई
-> क्योंकि.. पहले भी अनगिनत मामलों में हम यही करते आए हैं।
-> आज का AI, दरअसल हमारे अतीत का ही रूप है

[GN⁺]

Hacker News राय

• आजकल ज़्यादातर development के लिए Cursor का इस्तेमाल करता हूँ। यह लेख मेरे अनुभव से बहुत मिलता-जुलता है

  • ऐसा लगता है कि AI agent लगभग 2021 के आसपास आकर रुक गया है। अगर आप कोई नया package install करते हैं, तो Claude 4 साल पहले popular रहे पुराने packages या implementations की तरफ लौट जाता है। इसे ठीक करना बहुत frustrate करने वाला होता है। साफ़ instructions देने से समस्या कुछ कम हो सकती है, लेकिन हल नहीं होती
  • इन गलतियों की अप्रत्याशितता खास तौर पर चुनौतीपूर्ण है। कुछ महीने पहले मैंने Claude का इस्तेमाल करके एक उपयोगी web app "one-shot" में बनाया था। वह fully functional था और हैरान कर देने वाली हद तक sophisticated भी। अगर मैं उसे अकेले बनाता, तो शायद कई हफ्ते या weekend लगते। लेकिन जब मैंने उससे दिए गए file का इस्तेमाल करके favicon update करने को कहा, तो वह एक घंटे तक बेकार चक्कर काटता रहा (आखिर में मैंने खुद ही कुछ मिनटों में ठीक कर लिया)। कुछ दिन पहले मैंने फिर से लगभग उसी दायरे का एक web app बनाने की कोशिश की। करीब 4 घंटे तक agent से जूझने के बाद मैं code को पूरी तरह फेंक देने के लिए तैयार था
  • यह approach मुझे उन projects पर काम शुरू करने की हिम्मत देती है जिन्हें मैं समय, expertise या motivation की कमी के कारण आज़मा नहीं पाता था। friction का कम होना दिलचस्प है, लेकिन कुछ meaningful बनाना अब भी कठिन है। एक sophisticated MVP बनाने में अब भी काफ़ी मेहनत लगती है
  • मैं बार-बार खरगोश और कछुए की कहानी के बारे में सोचता हूँ। AI agent पर भरोसा करना लुभावना है क्योंकि शुरुआत में progress बहुत तेज़ लगती है। लेकिन अंत में अक्सर ऐसा लगता है कि धीमे और सावधानी से काम किया होता तो ज़्यादा ठोस प्रगति होती। हाथ से बनाते समय शायद ही कभी पीछे लौटना पड़ता है या पूरी approach छोड़नी पड़ती है। AI-driven approach में आप 10 गुना तेज़ चल सकते हैं, लेकिन रास्ते में लगभग 70% काम फेंक भी सकते हैं
  • इन अनुभवों की वजह से मुझे नहीं लगता कि 1 साल के भीतर AI 90% code autonomous तरीके से लिखेगा। हाँ, 90% code लिखने में वह मदद ज़रूर कर सकता है
  • मौजूदा माहौल self-driving car के hype cycle जैसा है। बहुत से bold promises और असली प्रगति ज़रूर हुई है, लेकिन मुझे नहीं लगता कि अगले 5 साल में हम ऐसी दुनिया देखेंगे जहाँ AI अपने दम पर उपयोगी software लिखे

• मैं AI का इस्तेमाल इस तरह करता हूँ: IDE में writing assistant की तरह, जो मुझे एक बहुत smart और sophisticated rubber duck की तरह जवाब देता है

  • मैं अक्सर किसी खास code snippet पर बार-बार चर्चा करता हूँ। आम तौर पर उसे लगभग बिना context के दिया जाता है, फिर उसे तब तक refine करता हूँ जब तक functionality सही काम न करे, और उसके बाद उसे broader context में fit करता हूँ (या वह हिस्सा मैं खुद संभाल लेता हूँ)
  • मैं इसका इस्तेमाल इस तरह नहीं करता: ऐसे agent की तरह नहीं जो अपने आप कोई broad goal पूरा करे
  • वजह: agent system के output को उस चीज़ के साथ align रखने के लिए, जिसे आप वास्तव में हासिल करना चाहते हैं, बहुत ज़्यादा समय और मेहनत लगती है। ठीक वही सारे कारण जो इस शानदार लेख में बताए गए हैं
  • विडंबना यह है कि AI को एक बेहद सक्षम writing assistant की तरह इस्तेमाल करने से workflow काफ़ी तेज़ हो जाता है। इसलिए कुछ हद तक कम agentic AI मुझे और ज़्यादा critical बनाता है, और agentic AI की quirks के हिसाब से ढलने के लिए जो अतिरिक्त समय लगाना पड़ता है, उसके प्रति भी ज़्यादा आलोचनात्मक बनाता है

• मुझे यह बिल्कुल समझ नहीं आता

  • मैं नहीं समझ पाता कि अनुभवी developers इतने साफ़ तौर पर खराब और असंतोषजनक अनुभव से खुद को बाँध लेने को लेकर इतने उत्साहित क्यों हैं
  • मुझे code लिखना और problems solve करना पसंद है। इसी वजह से मैंने software development को profession चुना

• उदाहरण: Docker build के दौरान memory error आने पर, शुरुआत से यह पूछने के बजाय कि इतनी memory इस्तेमाल ही क्यों हो रही थी, उसने memory setting बढ़ा दी

  • AI सचमुच हमारी ही तरह है

• developer skill अब भी ज़रूरी है — अगर आप चला नहीं सकते, तो steer भी नहीं कर सकते। लेकिन developer energy का क्या? AI से पहले मैं दिन में लगभग 2 घंटे ही coding कर पाता था (यानी असली code-writing time)। लेकिन Claude Code के साथ मैं बिना रुके आसानी से 5 घंटे coding कर सकता हूँ। यह साइकिल की जगह electric bicycle चलाने जैसा लगता है। AI मुझे Steve Jobs के "bicycle for the mind" रूपक जैसा लगता है — यह मुझे replace नहीं करता, लेकिन अब मैं बहुत ज़्यादा दूर और तेज़ जा सकता हूँ

• यह diagram बहुत relatable है — हमारी team यहाँ दी गई हर चीज़ पर टिक करती है। और अभी हम AI का इस्तेमाल भी नहीं कर रहे! सोचो जब हम आखिरकार AI इस्तेमाल करेंगे तब क्या होगा...

  • "गलत समझी गई requirements" और "ज़रूरत से ज़्यादा complex implementation" तो practically हमारे mascot हैं। हम बेहतर शुरुआती बातचीत और iterative reviews के ज़रिए इस chaos को धीरे-धीरे सुलझा रहे हैं। लेकिन आदतें आसानी से नहीं जातीं। क्या कोई AI की मदद के बिना भी इन pitfalls से निकल पाता है?

• जो बात मुझे साफ़ दिखती है, वह यह है: मेरे आसपास AI का इस्तेमाल हो रहा है

  • अक्सर ऐसे tools बनाने और maintain करने पड़ते हैं जो development tools, observability, logging, transformation वगैरह के लिए हों। agents का इस्तेमाल करके इन्हें बनाने और बदलने में मुझे काफ़ी success मिली है। उदाहरण के लिए, custom planning system से data collect करने और logs जुटाने वाले tools
  • इन tools को बनाने में critical path से बाहर generated boilerplate काफ़ी होता है। ज़्यादातर दिनों में मैं यह काम करना नहीं चाहता

• AI को बहुत steer करना पड़ता है, लेकिन मैं अब भी इस आशावादी सोच पर कायम हूँ कि बेहतर prompts से बेहतर agents मिलेंगे

  • लेख का एक उदाहरण लें: code reuse। जब आप code लिखते हैं, तो आपके पास पहले से मौजूद code का एक मानसिक inventory होता है। आप अवचेतन रूप से खुद से पूछते हैं, "क्या यह नया task उस code से बहुत मिलता-जुलता है जो पहले से काम कर रहा है और test हो चुका है?" मैंने coding agents को दिए जाने वाले शुरुआती prompts का बारीकी से अध्ययन नहीं किया है, लेकिन मेरा intuition कहता है कि prompt में यह जोड़ना अच्छा होगा कि agent codebase में मौजूद चीज़ों की inventory बनाए रखे, और नए code batch की योजना बनाते समय नए task की requirements की तुलना पहले से मौजूद चीज़ों से करे
  • हाँ, इससे planning process में बहुत सारे compute cycles बढ़ेंगे। लेकिन साफ़-साफ़ कहना चाहिए कि "यही वह कीमत है जो agents से code लिखवाने के लिए चुकानी पड़ती है"। बेहतर planning > problem-solving ability

• मैं यह कहकर शुरुआत करना चाहता हूँ कि AI tools उन चीज़ों में हमेशा खराब नहीं होते जिन्हें मैंने गिनाया है

  • लगता है वहाँ "not" छूट गया है। वे यह क्यों कहेंगे कि वे हमेशा खराब हैं? उलटी दिशा ज़्यादा समझ में आती है
  • इसके अलावा, वहाँ grammar mistake भी है: "effected" की जगह "affected" होना चाहिए

• क्या Martin Fowler अब अपनी website पर जगह किराए पर दे रहे हैं?