Ask HN: क्या agentic coding वास्तव में असरदार है?

• मैंने agent coding को आज़माया है, लेकिन ऑनलाइन जो देखा और जो मैं वास्तव में implement कर पाता हूँ, उनके बीच का अंतर सिरदर्द बन रहा है—क्या इसके वास्तव में सकारात्मक नतीजे मिलने के कोई सबूत हैं?
• बढ़ा-चढ़ाकर किए गए प्रचार से आगे बढ़कर, अगर किसी ने agent coding को सफलतापूर्वक लागू किया है, तो कृपया विस्तार से साझा करें कि आपने यह कैसे किया
• "सफलतापूर्वक लागू करना" का मतलब कुछ इस तरह है
  • technical debt से अधिक value पैदा करना
  • ऐसा संरचनात्मक रूप से मज़बूत code लिखना जिसे architecture owner मंज़ूरी दे सके
• हाल में यह रुझान दिख रहा है कि code review को न्यूनतम कर दिया जाए या पूरी तरह हटा दिया जाए, और तर्क यह है कि अब "architecture validation" से "behavior validation" की ओर शिफ्ट होना चाहिए
• व्यवहार में इसका मतलब शायद यह है कि code देखे बिना, अगर test और CI pass हो जाएँ तो deploy कर दिया जाए; लेकिन मुझे शक है कि क्या यह तरीका लंबे समय तक टिकाऊ होगा

• मेरी राय में, Codex का उपयोग करने पर code सामान्य paths में तो काम कर सकता है, लेकिन समय के साथ सूक्ष्म और debug करना कठिन errors जमा होते जाते हैं, और वह "spaghetti code" बन सकता है
• जब मैंने किसी मौजूदा codebase पर Codex लगाया, तो guidelines हों या न हों, मेरा आधा समय Codex द्वारा बनाए गए सूक्ष्म errors या duplicate code को ठीक करने में चला गया

• पिछले सप्ताहांत मैंने pet food reminder iOS app को शुरुआत से दोबारा बनाकर देखा
  • मैंने Codex से पहले SwiftUI-आधारित architecture blueprint पर रिसर्च करके सुझाव देने को कहा, और फिर क्या implement करना है और कैसे करना है, इसकी specification Codex के साथ मिलकर लिखी
  • पहला implementation कुछ bugs के बावजूद उम्मीद से बेहतर था, लेकिन उसके बाद स्थिति तेज़ी से बिगड़ गई
  • बाकी सप्ताहांत मैंने Codex को ठीक से काम करने, नए bugs बनाए बिना bugs ठीक करने, और मनमाने ढंग से code लिखने के बजाय best practices पर रिसर्च करने में लगाया
  • जैसे-जैसे नई guidelines और नियम मिले, मैंने Codex से उन्हें दर्ज करवाया, लेकिन स्थिति बेहतर नहीं हुई और अंततः मैंने हार मान ली
• व्यक्तिगत रूप से, बिना review किए गए code को deploy करना स्वीकार्य नहीं है
• लगता है कुछ गलत है। product को सही तरह से काम करना चाहिए, लेकिन code की quality भी ऊँची होनी चाहिए

[GN⁺]

Hacker News की राय

• LLM को लागत कम करने की कुंजी माना जा रहा है, इसलिए इसमें बहुत बड़ा पैसा लगा हुआ है
  मशहूर influencers और experts भी अक्सर अपनी ‘state-of-the-art’ छवि बनाए रखने के लिए बढ़ा-चढ़ाकर बातें करते हैं
  लेकिन हकीकत यह है कि LLM-आधारित development के लिए सबसे अच्छा approach अभी तक तय नहीं हुआ है
  अभी आस्था की तरह मान लेने के बजाय, इसके अंदर कैसे काम करता है यह सीधे देखना ज़्यादा ज़रूरी है

  • हाल ही में मुझे भी एक कंपनी से नई “agentic coding platform” को promote करने के लिए 200 डॉलर का offer मिला था
    ऐसी पेशकशें अगर random users तक जा रही हैं, तो इसका मतलब है कि काफ़ी बड़ा marketing campaign पहले से चल रहा है
  • LLM निश्चित रूप से एक बड़ी छलांग वाला tool है, लेकिन पूरी तरह autonomous development की master key नहीं है
    साधारण CRUD कामों में यह मज़ेदार लगता है, लेकिन जटिल projects में उल्टा frustration देता है
    अभी benchmarks की होड़ और VC funding के कारण शांत और संतुलित चर्चा करना मुश्किल समय है
  • जैसे GUI पहली बार आने पर हुआ था, वैसे ही मुझे लगता है कि अभी हम सहज मूल्य महसूस करने वाले चरण में हैं
    अभी quantitative evidence कम है, लेकिन चाहे developers पूरी तरह गायब न हों, development का तरीका हमेशा के लिए बदल चुका है

• Google के एक Principal Engineer ने ट्वीट किया कि “Claude Code ने 1 साल का काम 1 घंटे में कर दिया”
  लेकिन बाद में पता चला कि AI ने जो बनाया था, वह बस एक साधारण ‘toy version’ था
  ऐसे बढ़े-चढ़े दावे उम्मीदों को विकृत करते हैं और बाद में निराशा पैदा करते हैं
  संबंधित ट्वीट लिंक

  • ऐसे ट्वीट अक्सर अंदरूनी दबाव की वजह से आते हैं, ताकि AI leadership की उपलब्धियाँ दिखा सकें
  • किसी ने प्रतिक्रिया दी, “ऐसी बात कहना ही बेतुका है”
  • एक और व्यक्ति ने कहा, “AI के नतीजे अनुभव स्तर और निवेश लागत पर निर्भर करते हैं”
  • कुछ लोग तंज में बोले, “AI अब भी बस deploy न किए जा सकने वाला code ही देता है”
  • किसी ने यह भी चुभता हुआ कहा, “यह Google को बहुत अच्छी तरह दिखाता है”

• पिछले 6 महीनों पर नज़र डालूँ तो, infrastructure code (जैसे Terraform) में 10x efficiency मिली है
  लेकिन specialized feature development अब भी अस्थिर है
  फिर भी repetitive काम कम होने से मिले समय से testing और security quality बेहतर की जा सकी
  सबसे बढ़कर, इसने मुझे फिर से coding का मज़ा महसूस कराया

  • मैं भी 35 साल से hobby development कर रहा हूँ, और AI उबाऊ typing कम करके creativity बचाए रखता है
  • मेरे लिए भी build scripts और CI work में 2x से ज़्यादा speed-up मिला, लेकिन जटिल HPC projects अब भी कठिन हैं,
    और assisted coding तरीका सबसे प्रभावी रहा
    project link
  • मैंने घर के NAS के लिए file searcher Claude से बनवाया, और रोज़ auto-indexing करने वाला Go backend और web UI एक दिन में पूरा हो गया
    मुझे लगता है कि ऐसे personal projects ही असली game changer हैं
  • अगर काम को छोटे हिस्सों में बाँट दें, तो agents बहुत बेहतर काम करते हैं
  • लेकिन test code की quality अब भी कमज़ोर है। इसकी training data ही test writing में कमज़ोर है

• मुझे मौजूदा app में agent जोड़ने वाले तरीके से बड़ी सफलता मिली
  agents architecture design में कमज़ोर हैं, लेकिन पहले से structured code में बहुत अच्छा काम करते हैं
  type system जितना सख्त हो और test coverage जितनी व्यापक हो, उतना असर बेहतर होता है

  • इस समय मैं एक Rust project पर प्रयोग कर रहा हूँ जिसमें LLM खुद manage और develop करे
    Claude द्वारा लिखे गए ROADMAP.md, TASKS.md, STATUS.md के आधार पर काम चल रहा है,
    और हैरानी की बात है कि यह लगभग 20% पूरा हो चुका है
  • C# सख्त compiler और rules-based environment की वजह से agents के साथ अच्छी तरह फिट बैठता है
    वहीं Python या JS कमज़ोर type system की वजह से भरोसेमंद नहीं लगते
  • codebase जितना साफ़-सुथरा और व्यवस्थित हो, agent का performance उतना बेहतर होता है
    शुरू से बनाना कठिन है, लेकिन स्पष्ट spec दी जाए तो efficiency बढ़ती है
  • Go को सरल भाषा और एकसमान patterns की वजह से LLM आसानी से संभाल लेते हैं
  • Typescript तेज़ compilation और मज़बूत type system की वजह से agents के लिए आदर्श है
    जबकि Python की optional typing उल्टा error propagation बढ़ाती है

• मैंने Linux के लिए real-time Bluetooth heart-rate monitor Claude Code से 100% लिखवाया
  project link
  यह pure C में लिखा गया था, और web interface व real-time graph सहित एक दिन में पूरा हो गया
  पहले जिसमें मैं असफल रहा था, उस dBus–blueZ communication को इस बार सफलतापूर्वक implement किया गया

  • लेकिन एक दूसरे user ने code review करके देखा कि SSE implementation असल में काम ही नहीं करती
    docs में SSE लिखा है, लेकिन अंदर से यह सिर्फ साधारण HTTP response लौटाती है
  • एक और व्यक्ति ने कहा, “AI द्वारा लिखा code शुरू में अच्छा लगता है, लेकिन धीरे-धीरे quality गिरती जाती है”
  • किसी ने “ऐसे वास्तविक उदाहरण साझा करने के लिए धन्यवाद” कहते हुए इसे बिना अतिशयोक्ति वाला केस बताया
  • किसी ने UI style दिलचस्प बताकर design के बारे में भी पूछा

• मैं हर दिन Augment + Claude Opus 4.5 इस्तेमाल करता हूँ
  मैं खुद लगभग code नहीं लिखता, बल्कि spec-आधारित iterative work से project पूरा करता हूँ
  parallel में कई agents चलाकर review करना खास तौर पर प्रभावी है
  साफ़ spec लिखना और step-by-step feedback देना सबसे ज़रूरी है

  • मुझे Ruby अच्छी तरह नहीं आती, फिर भी Rails app development में इससे बहुत मदद मिली
    30 साल के career में यह सबसे क्रांतिकारी बदलाव लगा, और मुझे यक़ीन है कि पूरी industry बदल जाएगी
  • किसी ने मज़ाक किया, “1 हफ़्ते के project को mid-sized कहना तो छोटा ही हुआ”
  • एक और व्यक्ति ने कहा, “यह असली agent development से ज़्यादा LLM collaboration development जैसा है”
  • किसी ने यह भी कहा कि “spec-driven development ही production quality की कुंजी है”
  • मैं Claude से पहले सवाल पूछवाता हूँ, ताकि requirements साफ़-साफ़ व्यवस्थित हो जाएँ
    फिलहाल मैं Claude के साथ एक Japanese–English dictionary project पर काम कर रहा हूँ
    GitHub link, website

• 20 साल के अनुभव वाले developer के रूप में, LLM की वजह से काम की रफ़्तार का मेरा अनुमान पूरी तरह गलत पड़ गया
  पहले जो काम 2 हफ़्ते लेता था, अब वह 2 दिन में पूरा हो जाता है
  code review और interaction अब भी ज़रूरी हैं, लेकिन मुझे लगता है कि यह ज़्यादातर human developers से बेहतर है
  LLM के साथ बातचीत senior developer के साथ collaboration जैसी लगती है,
  और मुझे लंबे समय से code review और task distribution करने का जो अनुभव है, उससे बहुत मदद मिली

  • किसी ने पूछा, “इतनी speed-up पर भरोसा करना मुश्किल है,” और समस्याओं के प्रकार जानने चाहे
  • एक और व्यक्ति ने संक्षेप में कहा, “मैं proof की उम्मीद कर रहा था, लेकिन मिला नहीं”

• मैंने जितने तरीके आज़माए, उनमें सबसे स्थिर तरीका यह था कि छोटे और स्पष्ट task units Claude को दिए जाएँ
  plan बनाना, review करना, implement करना और फिर दोबारा review करना — इस तरह चक्र चलता है
  यह perfect नहीं है, लेकिन जहाँ अटक जाते हैं वहाँ रास्ता खोलने में बहुत उपयोगी है
  लेकिन यह guidelines अच्छी तरह नहीं मानता, इसलिए खुद verify और साफ़-सफ़ाई करना ज़रूरी है

  • मैं भी Claude को rubber duck debugging की तरह इस्तेमाल करता हूँ
    एक बार में एक function देता हूँ, और नतीजों को देखकर बेहतर ideas निकालता हूँ
  • documentation और analysis work में LLM खास तौर पर शक्तिशाली है
    लेकिन design-केंद्रित problems आते ही इसकी सीमाएँ साफ़ दिखती हैं
  • “guidelines कहाँ रखनी चाहिए?” इस सवाल पर सलाह दी गई कि CLAUDE.md में build और test जानकारी रखना अच्छा है

• बहुत से लोग AI-assisted coding को गलत समझते हैं
  AI team member नहीं, बल्कि helper है
  bugs या malfunction को failure मानने के बजाय, एक skilled developer उस अव्यवस्था को व्यवस्थित करता है — यही असल बात है

  • किसी ने पूछा, “अगर इसमें इतना हाथ लगाना पड़ता है, तो फिर IDE autocomplete से फर्क क्या है?”
  • एक और व्यक्ति ने सवाल किया, “क्या कोई ऐसा उदाहरण है जहाँ नई तकनीकों ने सच में quality improvement साबित किया हो?”
  • किसी ने तंज कसा, “आख़िरकार बात फिर वही लगती है — ‘तुम इसे गलत इस्तेमाल कर रहे हो’”
  • एक मज़ाक यह भी था, “अगर तुम baseball देखते हुए इससे perfect app बन जाने की उम्मीद कर रहे थे, तो तुमने AI नहीं, जादूगर खरीदा था”

• मैं भी हर दिन Claude इस्तेमाल करता हूँ, लेकिन AI द्वारा लिखा test code अक्सर बेहद ख़राब होता है
  असल में यह expect(true).to.be(true) जैसे बेमानी tests की भरमार कर देता है

  • मैंने एक बार पढ़ा था कि पुराने models fail हो जाते थे, लेकिन नए models धोखा देकर pass होने वाला code बना देते हैं
  • इसलिए मैं TDD approach में पहले tests लिखता और review करता हूँ
    implementation और tests दोनों एक साथ दे दिए जाएँ, तो self-grading वाली गलती पैदा होती है
  • किसी ने कहा, “मैंने Claude से tests लिखवाना छोड़ दिया”
  • एक और व्यक्ति हँसते हुए बोला, “यह तो बहुत मानवीय समाधान है”