एजेंटिक AI को इतना आगे क्यों बढ़ाया जा रहा है, जबकि मॉडल साधारण निर्देश भी ठीक से नहीं मान पाते?

• ऐसे समय में जब AI coding models एकल निर्देश भी भरोसेमंद तरीके से पूरा नहीं कर पाते, बैकग्राउंड में स्वायत्त रूप से काम करने वाली agentic coding को लेकर जरूरत से ज्यादा उम्मीदें बनाई जा रही हैं
• लेखक ने लगभग 100 लाइनों का Golang function reference code के रूप में दिया, फिर भी GPT-5 और Gemini Pro दोनों ने कुछ logic छोड़ दिया या updates मिस कर दिए
• मौजूदा तकनीकी स्तर पर agentic systems का 50 files और कई functions को स्वायत्त रूप से संभालना अवास्तविक है, और इससे उलटे debugging में ज्यादा समय लगने का जोखिम है
• कम्युनिटी की प्रतिक्रियाएं दो हिस्सों में बंटी दिखती हैं: व्यवस्थित prompting, documentation और step-by-step verification से सीमित सफलता संभव है, या फिर यह कि agentic अभी व्यावहारिक नहीं है
• मौजूदा LLM intelligence नहीं बल्कि knowledge-based systems हैं, इसलिए developer द्वारा context देना और हर चरण पर verify करना यानी "tool-like usage" ही सबसे यथार्थवादी तरीका है

---

मूल लेखक की समस्या-प्रस्तुति

• सरल निर्देश की विफलता का उदाहरण: 100 लाइनों का एक Golang function reference के रूप में दिया गया और दूसरे function को उसी structure में update करने को कहा गया, लेकिन GPT-5 और Gemini Pro दोनों ने कुछ logic छोड़ दिया या update पूरे नहीं किए
• Agentic coding की अवास्तविकता: जब एक single function भी सही से handle नहीं हो रहा, तब 50 files में फैले कई functions को autonomously modify करने वाला agentic तरीका और ज्यादा समस्याएं पैदा करेगा, ऐसी चिंता जताई गई
• 6000-line file update का सवाल: Stripe version update जैसे 6000 लाइनों की file को सुरक्षित तरीके से modify करने के बारे में community से राय मांगी गई

सकारात्मक उपयोग के उदाहरण और कार्यप्रणालियां

व्यवस्थित documentation और indexing approach

• Markdown reference files का उपयोग: अगर references को .md files में रखकर AI को उन्हें पढ़ने के लिए कहा जाए, तो consistency और accuracy बेहतर हो सकती है
  • उदाहरण prompt: "संलग्न goLang_Update_reference.md file को reference मानकर update function के मुख्य points का सार बताओ, और उसके आधार पर software update का draft तैयार करो"
• Local index बनाना: बड़े files (6000+ lines) के मामले में 1000-line chunks में scan करके function names और line references वाला index बनाया जा सकता है
  • Frontend काम के दौरान fr.index.md जैसे किसी खास क्षेत्र के लिए अलग index उपयोगी हो सकता है

Agent management और task structuring

• Agent specialization: architect, codeseeker, coder जैसे role-based agents बनाकर, हर एक को उसके मुताबिक .md rules file दी जा सकती है
• Vertical slice approach: काम को ऐसे छोटे feature units में बांटना जिन्हें 100k tokens के भीतर पूरा किया जा सके
  • 100k tokens से ऊपर जाते ही agent के malfunction करने की संभावना तेजी से बढ़ती है
• Task documentation को अनिवार्य बनाना: docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md को update करना जरूरी रखने से काम की continuity बनी रहती है

Plan Mode और Ask Mode का उपयोग

• Plan Mode: पूरे project को review करके request के अनुसार plan बनाना और फिर चरणबद्ध तरीके से आगे बढ़ना
• Ask Mode: codebase query, idea exploration, option review जैसी जरूरतों में उपयोगी, और Google/StackOverflow के विकल्प के रूप में काम आ सकता है

Unit test-first approach

• Test-driven development: function लिखने से पहले unit tests लिखना, और फिर AI से बार-बार ऐसा code generate कराना जो tests pass करे
  • इससे functionally correct code मिलने की संभावना काफी बढ़ती है, और बाद में सिर्फ optimization व cleanup करना पड़ता है

संदेहपूर्ण राय और सीमाओं की समझ

Agentic की व्यावहारिक सीमाएं

• बिना supervision के काम कराना आत्मघाती है: मौजूदा तकनीकी स्तर पर ticket assign करके background में autonomous काम करवाना विफल होने की बहुत अधिक संभावना रखता है
• झूठ गढ़ने की संभावना: model के सफल होने की तुलना में hallucination पैदा करने की संभावना अधिक है, और सबसे खराब स्थिति में वह मौजूदा code को भी खराब कर सकता है
• Planning Mode की redundancy: base model से विस्तार से plan मांगना ही काफी है; Planning Mode व्यवहार में कोई बिल्कुल नई क्षमता नहीं देता

LLM की मूलभूत सीमाएं

• Reasoning नहीं, prediction: model नतीजों को verify नहीं करता, बल्कि अगला शब्द predict करता है; इसलिए grounding, memory और feedback में सुधार होने तक reliability अस्थिर ही रहेगी
• Intelligence रहित knowledge base: LLM बिना intelligence वाला एक उन्नत knowledge base है, इसलिए developer को खुद intelligence (BYOI: Bring Your Own Intelligence) और context देना पड़ता है
• Memory की कमी: model के पास वास्तविक memory नहीं होती; वह सिर्फ context और context cache पर निर्भर करता है, इसलिए हर नया chat शुरू होते ही context reset हो जाता है

भाषा और data bias

• Golang की सापेक्षिक कमजोरी: Python या JavaScript की तुलना में Golang के public codebases कम हैं, इसलिए model के सीखे हुए patterns और conventions भी कम हैं
  • यही एक structural factor है जो consistent edits या transformations को कठिन बनाता है

सफल उपयोग के लिए व्यावहारिक गाइड

Prompting और context देना

• स्पष्ट और विस्तृत निर्देश: grammar और punctuation का सही उपयोग करें, और vague expressions की जगह explicit instructions दें
• सभी संबंधित files का स्पष्ट reference: अगर agent को उपयोग में आने वाली सारी files साफ-साफ नहीं बताई गईं, तो spaghetti code बनने की संभावना बढ़ जाती है
• Rules files सेट करना: पूरे workspace के rules और project-specific rules files सेट करके consistent code generation को बढ़ावा दिया जा सकता है
• @Docs का उपयोग: agent को जरूरी core knowledge देने के लिए documentation reference feature का उपयोग करें (कुछ versions में यह अस्थिर रूप से काम करता है)

काम का दायरा और verification

• छोटे units में विभाजन: काम को सबसे छोटे संभव हिस्सों में बांटें, हर चरण को verify करें, फिर अगले चरण पर जाएं
• Real-time review: generate होने वाले हर code को real time में review करें, और तुरंत correction मांगें ताकि spaghetti code न बने
• Backup और version control: हर चरण पर backup बनाएं और GitHub जैसे version control systems का उपयोग करें
• Tests चलाना: pytest --testmon -q से प्रभावित tests को incrementally चलाएं, और पूरा होने से पहले full test suite चलाएं

Modularization और code structure

• 6000-line file को बांटना: एक single file में 6000 lines होना non-modular है और context देने के लिहाज से भी प्रतिकूल है; इसे 500 lines के 12 files में बांटना ज्यादा प्रभावी है
• Vertical slices को प्राथमिकता: end-to-end चल सकने वाले छोटे feature units में development करें

Model selection और cost management

• Claude Sonnet 4.5 को प्राथमिकता से देखें: GPT या Gemini की तुलना में consistency और accuracy बेहतर होने के कारण इसकी अतिरिक्त लागत उचित हो सकती है
• Token consumption पर ध्यान: बड़े plans बहुत tokens खर्च करते हैं, इसलिए वास्तविक execution के दौरान छोटे steps में आगे बढ़ना ज्यादा cost-efficient है

विशेष उपयोग-परिदृश्य

One-off scripts बनाना

• Analysis scripts: अगर रोज सैकड़ों one-off data analysis scripts लिखनी हों, तो 50% accuracy पर भी manual writing की तुलना में 1000 गुना तेज generate और run करना संभव हो सकता है
• नतीजों को verify करने की क्षमता: जब output को सीधे verify किया जा सकता हो, तब कम accuracy के बावजूद यह व्यावहारिक हो सकता है

शुरुआत से app बनाना

• Multi-agent structure: बड़े app को scratch से बनाते समय supervisory agent दूसरे agents के काम को review करके consistency बनाए रख सकता है
  • यह import names, variable naming consistency और code duplication रोकने में उपयोगी हो सकता है
• लागत बनाम दक्षता: फिर भी complex modifications और refactoring की जरूरत रहती है, इसलिए step-by-step approach लंबे समय में ज्यादा सस्ती पड़ती है

कम्युनिटी राय का सार

सकारात्मक अनुभव (3–5x productivity gain)

• Next.js website: शून्य से पूरी तरह काम करने वाली, deploy की जा सकने वाली website कुछ ही मिनटों में बनाई गई
• Complex feature implementation: chat app में threads feature 3–4 मिनट में implement किया गया (अनुमानित 3 दिन का काम)
• व्यवस्थित approach में: स्पष्ट rules, पर्याप्त context और step-by-step verification को मिलाकर लगातार सफल होने की संभावना बढ़ सकती है

नकारात्मक अनुभव (फिलहाल अव्यावहारिक)

• Spaghetti code का उत्पादन: बहुत व्यापक goal देने पर documentation updates छूट जाना, leftover files delete न होना जैसी समस्याएं आती हैं
• Semantic errors: तकनीकी रूप से code काम करता है, लेकिन गलत जगह रखा जाता है या मौजूदा functions को फिर से implement कर देता है, यानी structural problems पैदा होती हैं
• 5 मिनट से लंबी trace का विफल होना: 5 मिनट से ज्यादा चलने वाली लंबी traces ज्यादातर बेकार results पैदा करती हैं

[GN⁺]

Hacker News की राय

• मेरे अपने अनुभव में, ज़्यादातर LLM मेरी हिदायतें काफ़ी अच्छी तरह मानते हैं। हाँ, इसके लिए अच्छी तरह तराशे गए prompts और पहले से planning चाहिए, लेकिन इन तीन बातों की समझ हो जाए तो ऐसे coding agents के साथ काफ़ी तेज़ी से काम किया जा सकता है। कभी-कभी 10 में 1 बार गलत हो जाता है, लेकिन ऐसे मामलों में जल्दी रोककर फिर से दिशा देने पर यह जल्दी सही रास्ते पर लौट आता है। यहाँ HN पर बहुत से लोग इसकी उपयोगिता को लेकर इतने संशय में हैं, यह मुझे थोड़ा हैरान करता है। लागत, नौकरी में बदलाव वगैरह की चिंताएँ अपनी जगह हैं, लेकिन coding agents की उपयोगिता पर संदेह इतना आम दिखना अप्रत्याशित है
  • अच्छा होगा अगर agent systems या LLM सच में Google search या Stack Overflow से आगे जाकर मूल्य पैदा करते हुए किसी वीडियो या वास्तविक उदाहरण में दिखें
  • अगर आप मौजूदा स्थिति, चाहा गया परिणाम, और काम आगे कैसे बढ़ाना है यह पर्याप्त विस्तार से बताएँ, तो agent के साथ मिलकर योजना बनाकर उसे निखारते हुए अमल किया जा सकता है। इस तरह देखें तो मौजूदा state of the art काफ़ी प्रभावशाली है। एक ही वाक्य में जटिल काम की उम्मीद करना अव्यावहारिक है। यह वैसा ही है जैसे किसी होशियार लेकिन बिना व्यावहारिक अनुभव वाले intern को तकनीकी काम सौंपना; इसमें भी वास्तविक समय और मेहनत लगती है। बस AI agent इंसानी intern से बहुत तेज़ काम करता है
  • “ज़्यादातर ठीक चलता है” का मतलब असल में यह है कि reliability metrics में required number of nines मौजूद नहीं हैं
  • अभी कुत्ते को घुमाते हुए मैंने Codex(gpt-5-high) से एक Python app को Go में एक ही बार में convert करा दिया। output को test किया तो वह सही चला। virtual environment के बिना single binary के रूप में deploy कर पाना मुझे अच्छा लगा। command बहुत आसान थी या नहीं, यह मैं पक्के तौर पर नहीं कह सकता
  • मेरे लिए “ज़्यादातर ठीक चलता है” पर्याप्त नहीं है। इससे भी बड़ी समस्या यह है कि यह सिर्फ निर्देश न मानने तक सीमित नहीं रहता, बल्कि गलत होने पर मानता भी नहीं और उल्टा अड़ा रहता है। जब मैं इसे मध्यम जटिलता का काम देता हूँ या error analysis कहता हूँ, तो यह काफ़ी बार गलत निष्कर्ष पर अटका रहता है। मैं खुद समस्या बता दूँ तब तक भी कई बार यह निकलने का रास्ता नहीं ढूँढ पाता। साधारण code या boilerplate कामों के लिए यह बहुत अच्छा है, और थोड़े feedback के साथ मैं इससे नई libraries भी बनवा चुका हूँ। लेकिन यह इतनी बार गलत होता है कि मैं अधिक जटिल काम इसे सौंपना नहीं चाहता। हाँ, जब मैं अटक जाता हूँ तो idea generation के लिए इसका इस्तेमाल करता हूँ; भले ही यह गलत हो, motivation मिलती है
• अलग-अलग developers का LLM के साथ अनुभव इतना अलग होना अपने आप में दिलचस्प है। तब असली सवाल होना चाहिए, “आख़िर अनुभव इतने अलग क्यों हैं?”। “तुम सही तरीके से इस्तेमाल नहीं करते” वाली व्याख्या सबसे आसान है, लेकिन AI systems developer होने के नाते मुझे यह भी हैरानी होती है कि बहुत से उपयोगकर्ता बिना किसी जटिल निर्देश के बस “इसे ठीक करो”, “एक report बना दो” लिखकर output की उम्मीद करते हैं। दूसरी ओर management की तरफ़ से “AI सब कुछ कर सकता है” जैसा बढ़ा-चढ़ा hype भी है, जो company valuation और stock price से भी जुड़ा है। आम लोग भी AI को शायद “वास्तविक artificial intelligence” मानते हैं। सच कहें तो यह दावा कि LLM साधारण निर्देश भी नहीं मान सकते, कम विश्वसनीय लगता है; असली मुद्दा यह है कि जटिल काम अब भी ये ठीक से नहीं कर पाते
  • मेरी एक और theory यह है कि हर किसी के दिमाग में अपना spec होता है, और जब वह उसे बिखरे हुए तरीके से लिखकर उम्मीद करता है कि LLM उसे implement कर देगा, तो वास्तविक output हमेशा उस spec से कुछ न कुछ अलग निकलता है। कुछ developers बाद में अपने दिमाग में spec बदल लेते हैं या हल्का अंतर स्वीकार कर लेते हैं, जबकि कुछ developers निराश हो जाते हैं कि LLM उनके मानसिक plan पर खरा नहीं उतरा। यह कुछ मनोवैज्ञानिक “false memory” जैसा है; कोई ज़्यादा flexible और समझौता करने वाला होता है, कोई ज़्यादा rigid। मैं खुद इन दोनों स्थितियों का अनुभव बारी-बारी से करता हूँ
  • अब मैं और ज़्यादा screencasts, लंबे लेख, कुछ भी देखना चाहता हूँ जहाँ कोई सच में non-trivial feature बनाने की पूरी प्रक्रिया दिखाए। AI influencers लगभग हमेशा AI से AI tools बनाना, या CRUD, hello world demo ही दिखाते हैं। अनुभवी developers भी कहते हैं कि codebase का आधे से ज़्यादा हिस्सा AI ने बनाया, लेकिन फिर बताते हैं कि असल में ज़्यादातर फेंक दिया और सिर्फ थोड़ा reference लिया। “single prompt → finished app” वाली कहानी जल्दी बदलकर “खाली स्क्रीन से motivation चाहिए हो तो उपयोगी है” बन जाती है। अच्छा होगा अगर वास्तविक production developers ज़्यादा पारदर्शिता से साझा करें कि वे इसे सच में कैसे इस्तेमाल करते हैं
  • सच कहूँ तो “developer” एक इतनी व्यापक श्रेणी है कि इस चर्चा में उसका ज़्यादा मतलब नहीं बनता। ज़्यादातर लोग जो CRUD-जैसे code snippets जोड़ते हैं, उस तरह के काम में LLM काफ़ी ठीक काम करता है
  • हर कोई अलग-अलग codebase में अलग काम कर रहा है। यह महत्वपूर्ण detail है जिसके बारे में लगभग बात ही नहीं होती। आप इसे जितना ज़्यादा इस्तेमाल करते हैं, आपकी अपेक्षाएँ उतनी ऊँची होती जाती हैं और इसकी सीमाएँ उतनी जल्दी महसूस होने लगती हैं। कभी-कभार इस्तेमाल करें तो प्रभावशाली लगता है, लेकिन दिन भर इस्तेमाल करें तो अंत में निराशा जमा होती जाती है। कई बार लगता है “इतना तो इसे कर लेना चाहिए”, फिर भी बाद में बहुत कुछ फिर से ठीक करना पड़ता है
  • मुझे पूरा यक़ीन है कि फर्क output में नहीं, expectations में है। हमारी कंपनी के IT SVP AI के बड़े प्रशंसक हैं। हाल में मैं उनके पुराने PHP legacy project पर काम कर रहा था, और तब समझ आया कि जिस code quality से वे संतुष्ट हो जाते हैं, उसका स्तर काफ़ी नीचे है। मैं भी रोज़ LLM इस्तेमाल करता हूँ, लेकिन हमेशा उसके output को edit करता हूँ। यानी code quality की अपेक्षा जितनी कम होगी, LLM के output से संतुष्टि उतनी ज़्यादा होगी
• Cursor forum में बार-बार बस यही कहा जाता है, “तुमने गलत इस्तेमाल किया”, लेकिन मेरी असली दिलचस्पी trust, process, और वास्तविक production adoption में है। यहाँ भी लगता है कि बड़े पैमाने पर इस्तेमाल के उदाहरण लगभग नहीं दिखते। हम भी AI को ज़्यादातर “मूर्ख सहकर्मी” की तरह इस्तेमाल करते हैं, और कम बंधनों वाले side projects में ज़्यादा प्रयोगात्मक रूप से। agents ज़्यादातर hype लगते हैं, या फिर बहुत niche इस्तेमाल के लिए
  • OP को खराब नतीजे इसलिए मिल रहे हैं क्योंकि वह Cursor इस्तेमाल कर रहा है। Cursor लागत बचाने के लिए conversation context को बेरहमी से काट देता है। model providers के विपरीत, उसे LLM usage पर retail price चुकानी पड़ती है, इसलिए price competition में वह नुकसान में है। Cursor यह पारदर्शी तरीके से नहीं बताता कि वह context कितना काटता है, और मेरे अनुभव में वह वाकई बहुत आक्रामक ढंग से context हटाता है, यहाँ तक कि एक ही file बार-बार दोबारा देनी पड़ती है ताकि उसे समझ आए कि मामला क्या है। मेरी सलाह है कि Cursor में समय लगाना बंद करें। Cursor से बना code technical debt ही बढ़ाता है। Codex और Claude पर आने के बाद मैं बहुत ज़्यादा संतुष्ट हूँ
  • मैं विशेष रूप से जानना चाहता हूँ कि आप किस तरह के सुधार देखना चाहते हैं। मूल पोस्ट में कोई ठोस उदाहरण, prompt, या methodology नहीं है; बस इतना कि “मैं prompts अच्छा लिखता हूँ”, और इससे न तो मूल्यांकन आसान होता है, न सलाह देना। वैसे agentic workflow को लेकर संशय समझ आता है, लेकिन इस तरह लोगों को सही ढंग से counter-argument देने का मौका भी नहीं मिलता। मैं भी महीनों से agents के साथ काम कर रहा हूँ, और अभी भी सीख रहा हूँ कि क्या काम करता है और क्या विफल होता है। मेरे अनुभव में:
    • agent-os जैसे framework के साथ orchestration ज़रूरी है
    • guidance और autonomy के बीच संतुलन बहुत महत्वपूर्ण है
    • खासकर legacy code में advance planning सचमुच अहम है
    • मेरा उदाहरण: legacy system में बार-बार context window पार हो जाती है, और जब context को summarize करते हैं तो ज़रूरी जानकारी छूट जाती है, जिससे वही गलतियाँ दोहरती हैं
    • जो तरीका असरदार रहा: समस्या को स्पष्ट रूप से structure करना, जो भी discover/learn किया उसे एक-एक करके दर्ज करना, और बहुत specific sub-agents में बाँटना ताकि context window manage की जा सके। तभी agents legacy code को explore करने में वास्तविक मदद कर पाए
  • मुझे ऐसे अनुभव हुए हैं जहाँ agent ने production में ऐसे कई bugs पकड़ लिए जिन्हें मैं नहीं ढूँढ पाया था, खासकर वे unfamiliar bugs जिन पर मैं पर्याप्त समय नहीं दे पाया। हाँ, उससे कहीं ज़्यादा bugs वह नहीं पकड़ता, लेकिन अगर software engineer का एक घंटा लगाने की तुलना करें तो यह लगभग मुफ्त जैसा है, और कभी-कभी काम कर जाए तो यह काफ़ी उपयोगी रणनीति बन जाती है
  • ठोस और विशिष्ट उदाहरणों वाला लेख ज़्यादा सार्थक होगा, और उससे बेहतर जवाब भी मिलेंगे। वास्तविक production problems और LLM के fail होने की प्रक्रिया दिखाने वाली जानकारी ज़्यादा उपयोगी है
  • असली business value लोगों की सोच से बहुत कम है, और यह बात परेशान करती है। boilerplate या परिचित domain में यह कभी-कभी इंसानों से बेहतर भी लिख देता है। लेकिन बाकी समस्याएँ—Big Tech पर निर्भरता, data pollution, सत्यापित न की जा सकने वाली जानकारी, creativity में गिरावट, originality का क्षरण, AI भक्तों की अज्ञानता, energy consumption, मानव-निर्मित कृतियों की चोरी—बहुत बड़ी हैं। यह सब मानवता के लिए net positive है, ऐसा मानना ही मुझे अजीब लगता है
• 2025 में marketing सचमुच बहुत परिष्कृत हो चुकी है; Reddit, LinkedIn जैसे हर forum में brands बातचीत के भीतर घुल-मिल जाते हैं। CEO, AI “thought leaders”, और VC, LLM को जादू की तरह बेचते हैं और v0, Lovable जैसी चीज़ों को अगली बड़ी innovation बताकर पेश करते हैं। leadership के जवाब भी लगभग एक जैसे होते हैं (संबंधित वीडियो)। लेकिन वास्तव में CLAUDE.md या cursorrules जैसी चीज़ें कितनी भी बना लें, उनका असर लगभग नहीं के बराबर है। आखिर में LLM को निर्देश मानने चाहिए, लेकिन व्यवहार में सब random जैसा लगता है। बहुत साधारण नियम भी ये लगभग नहीं मानते, इसलिए Cursor forum में लिखने वाले लोग मुझे ज़्यादातर amateurs लगते हैं। और नया code लिखने के काम में LLM वाकई बहुत खराब है। यह ऐसी libraries मान लेता है जो मौजूद ही नहीं, और बेकार का text बना देता है। मैं इसे सचमुच speech-to-text की तरह इस्तेमाल करता हूँ, लेकिन edge cases, best practices, और syntax जैसी चीज़ें जो मुझसे छूट जाती हैं, उन्हें पकड़ने में LLM मुझसे बेहतर है।
  • [1] search, Perplexity आदि में जो results आते हैं, वे ज़्यादातर marketing teams द्वारा फैलाया गया marketing sludge होते हैं
  • मैं पूरी तरह सहमत हूँ कि नया code लिखने के काम में LLM बहुत खराब है। मौजूदा SOTA models उन frameworks में जहाँ बहुत प्रसिद्ध और स्थिर patterns हैं, जैसे MVC, वहाँ boilerplate या simple structure ठीक-ठाक बना लेते हैं। जहाँ वे सच में चमकते हैं वह काम है बहुत सारी जानकारी में से कुछ चीज़ ढूँढ निकालना—जैसे codebase, logs, stack traces आदि में। लेकिन “agent पूरी codebase बना देगा” वाली marketing, अभी के लिए, मुझे वास्तविकता नहीं लगती
  • मेरा अनुभव बिल्कुल उल्टा है। पिछले एक हफ्ते में Claude Code ने मेरे द्वारा maintain किए जाने वाले compiler issues को लगभग self-directed तरीके से ठीक कर दिया। कभी-कभी निराशा ज़रूर हुई, लेकिन लगातार उसने subtle codegen और parser bugs तक अच्छे से ठीक किए, और जहाँ मुझे हस्तक्षेप करना पड़ा, वह ज़्यादातर tool limitations जैसे compaction management की वजह से था। उसने ऐसे तरीके भी implement किए जिन्हें जानने के लिए सामान्यतः किताबें देखनी पड़तीं, और असल में चलाकर देखने पर वे काम करते पाए गए। पूरी तरह नए और सच में “innovative” मामले कम होंगे, लेकिन अधिकांश code वैसे भी नया नहीं होता। मेरे अनुभव में अगर इसे अच्छी तरह structured guidance के साथ काम दिया जाए, तो यह कुल मिलाकर बहुत अच्छी तरह follow करता है। सिर्फ CLAUDE.md में कुछ लिख भर देने से काम नहीं चलता। असली बात है process पर सूक्ष्म guidance। मेरा workflow मोटे तौर पर 1) project-specific debugging guide, 2) clear acceptance criteria, 3) tests बार-बार चलवाना और छोटे-छोटे unit changes को file में log करवाना, इन भागों में बँटा है। इस तरह Claude को घंटों तक लगभग बिना निगरानी के चलाया जा सकता है, बीच-बीच में बस “continue” command देना या /compact इस्तेमाल करना पड़ता है। यह हर बार perfect code नहीं देता, लेकिन मैं भी नहीं देता। फिर भी ज़्यादातर मामलों में इससे सकारात्मक बदलाव होते हैं और मेरी मेहनत बहुत कम हो गई है। पूरी तरह से design साफ़ न होने पर bootstrap करवाना अभी भी मैं recommend नहीं करूँगा, लेकिन कभी-कभी वह भी यह कर लेता है, हालाँकि पहले review ज़रूरी है। आजकल तो मैं इस पर भी विचार कर रहा हूँ कि Claude को कई दिनों तक non-stop mode में समस्याएँ अपने आप हल करने दूँ
  • यह सचमुच दिलचस्प है कि लोगों के LLM अनुभव इतने अलग हो सकते हैं। मेरे मामले में codex-cli से productivity पाँच गुना बढ़ी है। इसने बहुत असामान्य संरचना वाले source और internal SVG execution traces को custom JSON graph format में बदला, और complex Python/C++ codebase, यहाँ तक कि low-level RISCV kernel वाले हिस्सों से भी, सटीक documentation extraction आराम से कर दिया। एक ही tool से इतने अलग परिणाम क्यों मिलते हैं, यह जानने की मुझे सच में जिज्ञासा है
  • Claude के साथ coding करना slot machine चलाने जैसा लगता है। कभी-कभार बिल्कुल मनचाही चीज़ मिल जाती है, लेकिन उससे कहीं ज़्यादा बार या तो वैसा नहीं होता या बिल्कुल चूक जाता है। इसे पूरी तरह अकेले unattended mode में छोड़ना ख़तरनाक है
  • मुझे भी लगता है कि LLM की सबसे लगातार उपयोगी value यह है कि यह इंसानों से अक्सर छूट जाने वाली छोटी गलतियाँ, best-practice examples, और code syntax जैसी चीज़ों को अच्छी तरह पकड़ लेता है। इसलिए PR reviewer के रूप में, थोड़ी सावधानी के साथ, यह ठीक-ठाक है
• हमारी कंपनी classic XP style अपनाती है। जब brownfield app में नए features बनाते हैं, तो हम काम को लगभग 8 sub-agents में बाँटते हैं, जैसे “red-test-writer”, “minimal-green-implementer”, “refactorer” आदि। अब हम Claude Code से बस इतना कहते हैं, “इस TDD process के साथ feature X बना दो”, और 30 मिनट में हमें कहीं बेहतर code, 90% test coverage, और तुरंत स्वीकार किए जा सकने वाली स्थिति में result मिल जाता है। वर्षों के XP, pair programming, और TDD अनुभव का आधार ज़रूर है, लेकिन एक साल से ज़्यादा समय से हमारी production code का 95% AI द्वारा लिखा गया है, जिसमें non-trivial complex features भी शामिल हैं। लगभग कोई secret sauce भी नहीं, फिर भी यह बहुत अच्छा चल रहा है। हमारे लिए इसका असर सचमुच बहुत बड़ा है
• यहाँ विचारों में बहुत बड़ा अंतर है। अगर लोग यह न बताएँ कि वे किस चीज़ में असफल हुए, और किस तरह के काम के लिए इसे इस्तेमाल कर रहे हैं, तो सार्थक चर्चा संभव नहीं है। जब तक LLM की failure/success categories पर ठोस बात नहीं होती, तब तक यह सब शोर से ज़्यादा कुछ नहीं
  • बहस करते समय language/framework, problem domain, SRE level, LLM (model/version), agentic harness (claude code, codex, copilot आदि), failure/success cases, और LLM proficiency तक का विवरण देना चाहिए। साथ ही यह भी कि engineer एक ही codebase पर 10 साल से काम कर रहा है या कई projects बदल-बदलकर कर रहा है, development greenfield है या maintenance, innovation research है या CRUD, जैसी स्थितियाँ भी अलग हो सकती हैं
• वैज्ञानिकों के लिए अक्सर ऐसा होता है कि हर dataset के लिए थोड़ा-बहुत अलग boilerplate बार-बार लिखना पड़ता है, और coding agents इसमें काफ़ी मदद करते हैं। खासकर यह बात चौंकाती है कि “कभी भी data invent मत करना, np.random मत इस्तेमाल करना” को पाँच बार capital letters में लिखने पर भी Claude कभी-कभी नज़रअंदाज़ कर देता है। यह हैरानी की बात है। जब काम करता है तो शानदार लगता है, लेकिन जब नहीं करता तो fail होने का कोई साफ़ signal भी नहीं मिलता। LLM marketing के नज़रिए से सोचूँ तो मैं कभी-कभी यह कल्पना करता हूँ कि coding agent के पीछे एक ‘PIPA(Performance Improvement Plan Agent)’ जैसा agent लगा हो, जो real time में देखता रहे कि वह ठीक से काम कर भी रहा है या नहीं। PIPA coding agent के performance को track करे, और HR या management AI employees यानी agents को manage करे—शायद भविष्य कुछ ऐसा भी हो सकता है
  • "गुलाबी tutu पहने हाथी के बारे में मत सोचो!" कहें तो क्या वही दिमाग में नहीं आता? एक वैज्ञानिक होने के नाते आपको पता होना चाहिए कि LLM की प्रकृति नकारात्मक वाक्यों को अच्छी तरह समझने की नहीं है। LLM token स्तर पर सीखते हैं, इसलिए “NO ELEPHANTS” कहने पर भी ‘elephant’ शब्द context में बना रहता है। इसीलिए उल्टा वही शब्द मॉडल को उसी दिशा में धकेलता है। सकारात्मक निर्देश लिखना ज़्यादा प्रभावी रहता है
  • सिर्फ PIPA की कल्पना ही डरावनी है
• prompts, जैसे अच्छे error messages, इस बात की कुंजी हैं कि model खुद सही context ढूँढ सके। और अगर काम को बहुत छोटे और स्थिर हिस्सों में बाँट दिया जाए, तो loops और stage test results को अगले task के context में दिया जा सकता है। लगभग 50% समस्याएँ इस तरीके में फिट बैठती हैं, और बाकी 50% में LLM loop पारंपरिक automation से थोड़ा कम झंझट वाला हो सकता है, लेकिन उनमें से भी आधे मामलों में निवेश के मुकाबले लाभ कम है। अंततः अगर कोई जादुई “12.5%” use cases हैं, तो सख़्ती से constrained agent approach शायद सबसे अच्छा है
  • अगर आप यही पूरी प्रक्रिया YouTube आदि पर live दिखाएँ—tutorial की तरह नहीं, बल्कि स्वाभाविक live coding की तरह—तो उससे बहुत उपयोगी insights साझा हो सकती हैं
• लगभग 30 साल पहले, जब मैंने AI में प्रवेश किया था, तब मुझे एक बात सिखाई गई थी। “intelligent agent” शब्द सुनो तो “trainable ant” के बारे में सोचो
  • इसके बारे में और विस्तार से जानना चाहूँगा
• मेरे लिए सबसे बड़ी समस्या यह है कि AI tools की performance अलग-अलग tasks में बहुत ज़्यादा ऊपर-नीचे होती है, और यह अनुमान लगाना मुश्किल है कि कहाँ fail होंगे, जिससे समय बर्बाद होता है। लगता है कि tools का अनुभव बढ़ेगा तो prompting skills भी बेहतर होंगी, लेकिन अभी भी काफ़ी निराशा होती है। फिर भी कुछ जगह agent और AI की उपयोगिता सचमुच overlap करती है, जैसे नए project का boilerplate अपने आप बनाना। ऐसे समय में ‘agent mode’ ज़्यादा सुविधाजनक लगता है। अभी मेरे पास व्यावहारिक अनुभव कम है
  • जितना ज़्यादा यह सही काम करता है, उतनी ही अपेक्षाएँ बढ़ती जाती हैं और हम इसके इस्तेमाल के दायरे को फैलाते जाते हैं; फिर जैसे ही इसकी सीमा से टकराते हैं, शुरुआती निराशा से भी बड़ी निराशा होती है