एजेंटिक कोडिंग के लिए सिफारिशें

• Agentic coding के वास्तविक उपयोग के उदाहरण साझा किए गए हैं
• मुख्य रूप से Claude Code Sonnet मॉडल का उपयोग किया जाता है, और IDE integration की बजाय पूरे काम को AI को सौंपने का तरीका पसंद किया जाता है
• Go भाषा को agent-friendly संरचना और ecosystem की स्थिरता की वजह से नए backend प्रोजेक्ट्स के लिए खास तौर पर सिफारिश की जाती है
• स्पीड और सरलता agentic coding के मूल तत्व हैं, और test cache या सरल toolchain महत्वपूर्ण हैं
• कोड को सरल और parallel processing के अनुकूल बनाना चाहिए, और एजेंट की performance को अधिकतम करने के लिए refactoring का सही समय चुनना बहुत महत्वपूर्ण है

---

Preface

• हाल के समय में agentic coding के अनुभव साझा करने वाले developers की संख्या तेजी से बढ़ी है
• मैं अभी Claude Code Sonnet मॉडल को Max प्लान ($100/माह) पर इस्तेमाल कर रहा हूँ
• IDE का महत्व कम हुआ है, उसकी जगह मैंने फिर से Vim का उपयोग शुरू किया है, और workflow ऐसा है कि Claude को काम सौंपता हूँ और सिर्फ परिणाम की जाँच करता हूँ
• innovation की गति बहुत तेज है, इसलिए इस पोस्ट की सामग्री जल्दी पुरानी हो सकती है; इसी कारण लंबे समय तक टिकने वाले concepts पर ध्यान रखा गया है

The Basics

• claude --dangerously-skip-permissions कमांड के लिए claude-yolo alias सेट किया गया है ताकि सभी permission restrictions हटा दी जाएँ
  • इसे Docker के जरिए dev environment को सुरक्षित रूप से isolate करके संभाला जा सकता है
• Claude ज़्यादातर बुनियादी tools को अच्छी तरह संभाल लेता है, इसलिए MCP(Multi Capability Protocol) का सिर्फ विशेष मामलों में उपयोग किया जाता है
  • उदाहरण: playwright-mcp के जरिए browser automation
• खुद बनाए गए tools सामान्य scripts के रूप में रखे जाते हैं और जहाँ तक संभव हो सरल tool setup बनाए रखा जाता है

Choice Of Language

• अलग-अलग भाषाओं में agentic coding का प्रयोग करने के बाद, नए backend प्रोजेक्ट्स के लिए Go सबसे आदर्श पाया गया
  • Context system: पूरे कोड में साफ़ तरीके से बहने वाली data structure देता है, जिससे एजेंट को चीजें explicit रूप से देना आसान होता है
  • Test cache: Rust जैसी दूसरी भाषाओं की तुलना में test execution और cache ज़्यादा सरल हैं, जिससे एजेंट का code-test loop अधिक efficient होता है
  • सरलता: Go की अपनी सरलता एजेंट के लिए भी फायदेमंद साबित होती है
  • Structural interfaces: अगर किसी type पर methods मेल खाते हों तो उसे interface माना जाता है, जिससे LLM के लिए इसे संभालना आसान हो जाता है
  • ecosystem में कम बदलाव: लंबे समय तक चलने वाले versions और explicit changes की वजह से पुराने code का auto-generation कम होता है
• Python कई समस्याएँ पैदा करता है
  • fixture, async handling, और धीमी execution जैसी वजहों से agentic loop में efficiency घटती है
• frontend के लिए Tailwind + React + Tanstack Query/Router + Vite
  • Tanstack Router के filenames में आने वाला $ चिन्ह एजेंट को भ्रमित करता है और समस्याएँ पैदा करता है

Tools, Tools, Tools

• tools के लिए मानदंड इस प्रकार हैं
  • तेज़ होना चाहिए
  • उपयोगी error messages देने चाहिए
  • अगर LLM गलत तरीके से इस्तेमाल करे तब भी स्थिरता से काम करना चाहिए
  • observable हो और debug करना आसान हो
• Makefile आधारित make dev, make tail-log जैसी commands दी जाती हैं
  • duplicate execution से बचने के लिए shoreman के fork version से pid management किया जाता है
  • logs को stdout और file दोनों में रिकॉर्ड किया जाता है ताकि एजेंट सीधे logs से जानकारी निकाल सके
• उदाहरण: email verification links भी logs में रिकॉर्ड हों, ऐसा सेट किया जाता है ताकि browser automation के जरिए email verification process पूरी की जा सके

It's All About Speed

• agentic coding की सबसे बड़ी inefficiency reasoning cost और inefficient tool usage है
• तेज़ tool response time productivity की कुंजी है
• अगर एजेंट खुद temporary tools बनाकर इस्तेमाल करे, तो तेज execution/compile speed काम की efficiency को बहुत बढ़ा देती है
• धीमे environment में dynamic module loading जैसे विकल्प (उदाहरण: Sentry के लिए file module watch और auto-run) उपयोगी हो सकते हैं
• logs को संक्षिप्त और स्पष्ट रखना चाहिए ताकि token खर्च और speed दोनों optimize हों; ज़रूरत पड़ने पर LLM को log level adjust करने का interface देना मददगार होता है
• यह महत्वपूर्ण है कि code generation के चरण से ही meaningful logs/observability निकलने के लिए design किया जाए

Stability and Copy/Paste

• ecosystem की स्थिरता code reusability और एजेंट के भ्रम से बचाव के लिए बहुत महत्वपूर्ण है
  • Go और Flask जैसे कम बदलाव वाले, predictable language/framework इस्तेमाल करने की सिफारिश की जाती है
• library auto-upgrade से सावधान रहें, क्योंकि इससे एजेंट द्वारा छोड़ी गई comments या code flow टूट सकते हैं
• जहाँ संभव हो खुद code लिखें → dependencies कम रखें रणनीति अपनाने की सलाह है

Write Simple Code

• एजेंट सरल और explicit code के साथ बेहतर काम करते हैं
• सुझाई गई नीतियाँ
  • वर्णनात्मक और लंबे function names को प्राथमिकता दें, और classes की बजाय functions पर आधारित code लिखें
  • inheritance और जटिल tricks से बचें
  • pure SQL के उपयोग की सिफारिश है; एजेंट SQL में अच्छे होते हैं, और logs के साथ तुलना व tracing आसान होती है
  • स्पष्ट permission checks को code में सीधे और सहज रूप से दिखना चाहिए (अलग file/configuration में न बाँटें)

Make It Parallelizable

• अलग-अलग agents की processing speed बहुत तेज नहीं होती, लेकिन parallel processing के जरिए कुल efficiency बढ़ाई जा सकती है
  • उदाहरण: file system के आधार पर checkout copies बनाना
  • Redis या DB जैसी shared resources को अलग करने के तरीकों पर विचार करना ज़रूरी है
  • उदाहरण tool: container-use का उपयोग करके Docker-आधारित session isolation
• CI आधारित parallel work, Cursor का background agent आदि भी ध्यान देने योग्य tools हैं

Learn To Refactor

• agentic approach में सही समय पर refactoring बहुत महत्वपूर्ण है
  • जैसे-जैसे complexity बढ़ती है, agent के लिए code को सही ढंग से संभालना कठिन हो जाता है
  • उदाहरण: Tailwind classes 50 files में फैलने से पहले उन्हें component library में बदल देना
• बहुत जल्दी या बहुत देर से किया गया refactoring दोनों ही inefficient हो सकता है, इसलिए सही timing पर structure सुधारने का निर्देश देना ज़रूरी है

What Next?

• agentic coding तेज़ी से विकसित हो रही है, और मुख्य सिद्धांत हैं ‘सरलता, स्थिरता, visibility, parallelism’
  • tools और methodology बदल सकते हैं, लेकिन ये सिद्धांत वैध रहेंगे
• लक्ष्य सिर्फ productivity बढ़ाना नहीं बल्कि बेहतर code quality हासिल करना भी है
• एजेंट द्वारा लिखा गया code कुछ महीने पहले की तुलना में स्पष्ट रूप से बेहतर हो गया है
• लचीले ढंग से बदलावों के साथ चलते हुए coding experience का विस्तार करना चाहिए

[helloppfm]

मैं भी अभी तक AI से बस साधारण test code या उदाहरण ही पूछता हूँ, लेकिन अब इसे पूरे तौर पर लागू करने की कोशिश करने वाले लोग लगातार सामने आ रहे हैं.

अभी यह थोड़ा जल्दबाज़ी लग सकता है, लेकिन कुछ साल बाद यह स्वाभाविक बात बन जाएगी.

[GN⁺]

Hacker News की राय

• मैं VS Code Nightlys में Copilot और Claude Sonnet 4 को साथ इस्तेमाल करके Agentic Coding का अनुभव कर रहा हूँ। दिन का आधा हिस्सा मीटिंग्स में निकल जाए तब भी सिर्फ मेरी git history देखकर इसका पता न चले, इतना productivity boost महसूस हो रहा है। अब मैं बारीक implementation की जगह इस पर ज़्यादा सोचता हूँ कि बदलाव सही तरह काम कर रहा है या नहीं, क्या मैं इस कोड को समझ पा रहा हूँ, इसे बेहतर समझने के लिए structure कैसे रखा जाए, और AI convention markdown में क्या जोड़ूँ ताकि Agent की गलतफहमियाँ कम हों। कल रात मैंने एक ऐसी file, जिसमें 38 mypy errors थे, Agent को दे दी और 15 मिनट परिवार के साथ बात करके लौटा तो Agent ने क्या-क्या बदला और क्यों बदला, उसका summary दे दिया। एक बदलाव पर हमने बहस भी की, लेकिन आखिर में मुझे लगा कि Agent की राय सही थी। mypy check भी pass हो गया। अब मैं अपनी टीम को भी इस तकनीक की असली क्षमता समझाने की कोशिश कर रहा हूँ, लेकिन कुछ लोग sceptical हैं और AI perfect नहीं है कहकर विरोध करते हैं। लेकिन एक दोस्त की बात उधार लेकर कहूँ तो, "आज का दिन तुम्हारे और इस तकनीक के लिए आगे आने वाले समय का सबसे खराब दिन है" — और यही मुझे innovation का सबूत लगता है

  • type checker errors असल में development workday का वह हिस्सा है जिस पर सबसे कम समय लगना चाहिए, इसलिए यह जानना दिलचस्प है कि उसी चीज़ ने इतना समय कैसे खा लिया। अगर AI usage पर होने वाली हर चर्चा में यह भी साथ दिख सके कि कौन वास्तव में किस काम के लिए इसे इस्तेमाल कर रहा है (जैसे Cloudflare की पोस्ट), तो असर बहुत ज़्यादा होगा

  • निजी तौर पर मुझे Python की तुलना में Rust code पर Agent ज़्यादा भरोसेमंद लगता है। Python में static analysis का स्तर clippy या rust-analyzer जितना अच्छा नहीं है, इसलिए हर code path मुझे हर बार खुद चलाकर देखना पड़ता है

  • आपने कहा कि दिन का आधा हिस्सा मीटिंग्स में जाए तब भी git history देखकर पता नहीं चलेगा, लेकिन अगर मैं आपकी कंपनी में आपका employer होता तो मैं जल्द ही इसी स्तर का output लगातार expect करने लगता

  • workflow जानने की उत्सुकता है। मैं Claude Code को personal project experiments में इस्तेमाल कर रहा हूँ, और company account से Copilot भी VS Code के agent mode में 3.5, 3.7 Sonnet, 04-mini तक अलग-अलग मिलाकर चला चुका हूँ। इसे एक बड़े Go project में इस्तेमाल किया, लेकिन tests को छोड़कर नतीजे बहुत खराब थे। लगा शायद मैं tool गलत इस्तेमाल कर रहा हूँ, इसलिए "latest best practices" सब आज़मा लिए — context बदलना, model बदलना, rules देना, prompts सुधारना — लेकिन कुछ भी बेहतर नहीं हुआ

  • आपने AI convention markdown में Agent की गलतियाँ कम करने के लिए और जोड़ने की बात की थी; जानना चाहता हूँ कि क्या वह हर task के साथ context में attach होने वाली file है, या VS Code Copilot Agent की कोई official convention है। और यह भी कि document structure तय करने के लिए कोई reference material था, या फिर समय के साथ AI की बार-बार की गलतियों के आधार पर आपने खुद इसे refine किया

• यह सचमुच उत्साहजनक है कि Agentic coding को efficient बनाने वाली ज़्यादातर तकनीकें इंसानी coding efficiency भी बढ़ाती हैं। पहले यह चिंता थी कि AI के कारण सिर्फ AI को समझ आने वाला 'विशाल मिट्टी का ढेर' जैसा code बनेगा, लेकिन व्यवहार में उल्टा दिख रहा है। साफ़ code अब AI productivity के लिए भी कहीं ज़्यादा महत्वपूर्ण हो गया है, और इसी वजह से productivity का अंतर संख्याओं में साफ़ दिखने लगा है। Claude किसी codebase पर कितना अच्छा काम करता है, इसे अब metrics में दिखाया जा सकता है, इसलिए code अच्छी तरह structured है या नहीं — यह अब सिर्फ राय का मतभेद नहीं, बल्कि objective evidence के साथ चर्चा करने वाली बात बन सकती है

  • code के 'मिट्टी के ढेर' बन जाने की चिंता तो सच कहें तो programming की शुरुआत से ही चली आ रही है (Rich Hickey का talk देखें)। लोग अक्सर "अभी के लिए आसान रास्ता" चुनते हैं और कल के लिए भारी technical debt छोड़ जाते हैं। LLM की वजह से बिना मतलब boilerplate उगलना और आसान हो गया है। जब दर्द कम हो जाता है, तो शायद उसे ठीक करने की इच्छा भी ही खत्म हो जाए

  • मैं यह बात भी ज़रूर दर्ज करना चाहता था: "AI ही समझ सके ऐसा code बनने की चिंता — अभी न भी हो, तो आगे क्या होगा यह कोई नहीं जानता"

  • इस हिस्से से बहुत सहमति है। अच्छे error messages, तेज़ tools, stable ecosystem, simple और 'magic' रहित code, और intuitive SQL — यही तो वह development environment है जिसका मैंने हमेशा सपना देखा था। Agent इतनी तेज़ी से काम करते हैं कि छोटे-छोटे delays भी बहुत महसूस होते हैं, इसलिए लगता है कि ऐसी तकनीकें पूरे development experience का स्तर ऊपर उठा सकती हैं

• मैंने यह बात सुनी है कि Agent इस्तेमाल करते-करते लोग स्वाभाविक रूप से Go और Tailwind की तरफ धकेले जाते हैं। वजह यह बताई जाती है कि training data भरपूर है, इसलिए AI इन्हें ठीक से संभाल पाता है। तो क्या यह चिंता वाजिब है कि अगर भविष्य में हर कोई यही tools इस्तेमाल करे, तो नई languages, frameworks, और libraries का उभरना मुश्किल हो जाएगा? मौजूदा solutions से प्रतिस्पर्धा करना कठिन होगा, और StackOverflow जैसी human communities भी गायब हो सकती हैं

  • मैं इस चिंता से सहमत नहीं हूँ कि नई languages या frameworks आना बंद हो जाएगा। LLM translation में बेहद मजबूत हैं, इसलिए training data न भी हो, तो अगर कोई framework अनोखा हो लेकिन उसका structure स्पष्ट हो, तो वे codebase देखकर तुरंत सीख लेते हैं। मैंने खुद अपने idiosyncratic C# framework (जो किसी ने पहले नहीं देखा) के साथ LLM को बहुत अच्छा काम करते देखा है। हाँ, Rust lifetimes जैसी अनोखी विशेषताएँ तुरंत compatible न हों, लेकिन Go जैसी सरल चीज़ें जल्दी अपनाई जा सकती हैं। आगे चलकर नई language बनाते समय शायद LLM compatibility को ही design, tooling, documentation वगैरह में ध्यान में रखना पड़े

  • यह सचमुच बहुत अहम सवाल है। दूसरे शब्दों में कहें तो, जब इंटरनेट LLM-generated data से भर जाएगा और high-quality training data कम होती जाएगी, तब LLM-friendly developers पुराने, 'कम रेडियोधर्मी' tech stacks (जैसे JS/React) की ओर और आकर्षित हो सकते हैं। आगे चलकर JavaScript/React भविष्य का COBOL बन जाए, लेकिन महंगे consultants की ज़रूरत न पड़े क्योंकि maintenance LLM कर देंगे। अगर आप AI wave से बचना चाहते हैं, तो नई language बनाना — खासकर Lisp+DSL जैसी, जिन्हें LLM तुरंत न सीख सकें — AGI युग आने तक काफ़ी सुरक्षित दांव हो सकता है

  • software stack का पारंपरिक cycle कुछ ऐसा होता है: (1) मौजूदा stack हर niche को समेटते-समेटते इतना जटिल हो जाता है कि experts बेकार की 'आर्किटेक्चरबाज़ी' में उलझ जाते हैं, (2) उसके जवाब में कोई नया, कहीं ज़्यादा सरल stack आता है जो नए trend को साफ़ और आसानी से हल करता है और लोकप्रिय हो जाता है, (3) समय के साथ वही नया stack भी भारी हो जाता है और वही cycle फिर दोहरती है। AI coding में भी context expansion बहुत तेज़ी से बढ़ रहा है, इसलिए मुझे नहीं लगता यह cycle इतनी आसानी से टूटेगी

  • यह दावा कि Go और Tailwind की ओर मजबूर किया जाता है, दरअसल लेखक की निजी preference से काफी प्रभावित दृष्टिकोण लगता है। अगर Sonnet को cargo test CLI में दिक्कत हुई, तो इससे Rust, cargo, या बड़े अर्थ में पूरे AI को ही समस्या नहीं कहा जा सकता। PHP tests में भी Junie built-in runner को ठीक से नहीं चला पाता, लेकिन अगर आप bin/test-php script दे दें तो वह उसे ठीक से इस्तेमाल कर लेता है। Requirements को guidelines में साफ़-साफ़ लिख देना मददगार होता है, लेकिन मुद्दा यह ज़्यादा है कि models default tools पर अड़े रहते हैं। Stack Overflow के अनुभव पर भी कहूँ तो, मेरे AI assistant की एक बड़ी खूबी यह है कि वह सवालों को duplicate बताकर बंद नहीं करता। SO की curation कोशिश अच्छी है, लेकिन उसी वजह से उसने बहुत से users भी खो दिए

  • कल ही मैंने Claude (Zed में इस्तेमाल करते हुए) को सिर्फ conditions देकर एक नया elixir phoenix project बनवाया, और उसने बिना दिक्कत बहुत अच्छा किया। CSS के लिए tailwind इस्तेमाल हुआ, लेकिन वह शायद इसलिए क्योंकि phoenix खुद default setup में वही देता है। AI Go की ओर धकेलता है, इस दावे से मैं सहमत नहीं हूँ। उल्टा, जब आप बिना context के पूछते हैं तो Python की तरफ से सुझावों की भरमार रहती है, और छोटे community size वाले elixir के साथ भी मेरा अनुभव बढ़िया रहा है

• मैंने करीब एक हफ्ते Rust code पर Claude Code Sonnet 4.0 का प्रयोग किया, लेकिन नतीजे उम्मीद से कम रहे (ऊपर से Bedrock के रास्ते इस्तेमाल करने पर महँगा भी पड़ा)। शुरू में plan बनाने में बहुत समय लगाता है, लेकिन असल काम अक्सर आधा ही पूरा करता है। समझ नहीं आ रहा कि मैं क्या miss कर रहा हूँ

  • मुझे भी लगभग यही महसूस हुआ। Cursor Edit/Agent mode में अक्सर एक बार में लगभग वही changes मिल जाते हैं जो मैं चाहता हूँ, इसलिए वह बहुत efficient लगता है, लेकिन CLI environment में चीज़ें बहुत असुविधाजनक लगती हैं। जानना चाहता हूँ कि क्या आप Claude Code को 10–15 मिनट के tasks देकर सिर्फ diff review करते हैं, या code review भी ठीक से करते हैं

  • मेरा अनुभव भी बिल्कुल यही रहा। मैं जानबूझकर उपयोगी use cases ढूँढ-ढूँढकर इसे आज़माता रहा, लेकिन फिर भी यह ठीक से काम नहीं करता था, जो मेरे लिए बहुत अजीब था

  • इसे महँगा नहीं लगना चाहिए। Pro plan 20 डॉलर प्रति माह है, और Max 100–200 डॉलर का, जो API के रास्ते इस्तेमाल करने पर महीने के 1000 डॉलर से ऊपर जाने की तुलना में सस्ता है

• containers के इस्तेमाल का ज़िक्र देखकर अच्छा लगा। मैं dagger/container-use पर काम कर रहा हूँ, और हमारी टीम में ex-Docker members तथा Docker के founder भी हैं। मुझे लगता है कि Agents को parallel में चलाना एक बड़ा technological turning point होगा, बशर्ते इसे reliably इस्तेमाल करना आ जाए। तब तक भी, अगर Agent tasks चलते समय आप कोई और काम करना चाहते हों या यह चिंता हो कि Agent कहीं गलत हिस्सों को न छेड़ दे, तो development environment को containerize करना बहुत उपयोगी है। container-use तकनीक अभी शुरुआती दौर में है, लेकिन बहुत तेज़ी से आगे बढ़ रही है, और फिलहाल reliability, git conflicts कम करना, और human-Agent interaction बेहतर बनाना इसके मुख्य सुधार क्षेत्र हैं

• language choice पर मेरा विचार यह है: 1) Java सबसे व्यापक है, क्योंकि LLM के लिए reference के तौर पर विशाल और पुराना dataset उपलब्ध है (यह ज़रूरी नहीं कि यह सबसे accurate भी हो)। 2) सबसे बढ़कर, आपको वही language इस्तेमाल करनी चाहिए जिसे आप खुद सबसे अच्छी तरह जानते हों, ताकि LLM की गलत reasoning, errors, और hallucinations को जल्दी पकड़ सकें

  • यह राय कि Java के पास सबसे बड़ा, सबसे पुराना, साफ़ dataset है, शायद केवल तब तक सही सलाह है जब LLM के पास API, docs, या 3rd-party source code खोजने के tools न हों। अगर tools अपने-आप यह पता लगा सकते हों कि क्या इस्तेमाल करना है, तो आप कोई भी language चुनें, अंततः Agent को source पढ़ना आना चाहिए बस। लेकिन दूसरी बात — कि वही language चुननी चाहिए जिसे आप जानते हों — उससे मैं पूरी तरह सहमत हूँ। आखिरकार इंसानी careful review अनिवार्य है, और जानी-पहचानी language में गलतियाँ पकड़ना आसान होता है

  • Java का dataset सबसे बड़ा क्यों माना जाए? क्या open source projects में Java सबसे ज़्यादा है (शायद पूरे Apache suite की वजह से?), या Java open source libraries का documentation बहुत समृद्ध है — यही वजह है?

  • मैं तो अब तक यही मानता आया था कि Python code वाला dataset सबसे बड़ा होगा। जब कोई खास context न दिया जाए, तो ज़्यादातर LLM पहले Python ही suggest करते दिखते हैं

• यह दावा कि Go का context system (जिसे explicit data bag की तरह design किया गया है और जो code execution path के साथ बहता है) AI agents को simplicity देता है, इस आलोचना के साथ आया कि "tracing data के अलावा बाकी data को context.Context में रखना वास्तव में अच्छी practice नहीं है"

  • सहमत हूँ। chromedp (Go के लिए chrome headless driver) में context.Context पहले argument के रूप में आता है, लेकिन structure ऐसा है कि आप साधारण context.Background() नहीं दे सकते; आपको उसकी special factory से मिला context ही इस्तेमाल करना पड़ता है। timeout setting अलग से context.WithTimeout से की जाती है, और व्यवहार में यह लगभग void* pointer जैसा इस्तेमाल होने लगता है

  • मैं Go expert नहीं हूँ, लेकिन व्यवहार में libraries को context में database connections, config, rate limiter, cache backend जैसी चीज़ें रखते हुए देखा है, इसलिए फिलहाल मुझे यह इतना बड़ा मुद्दा नहीं लगता

• 'AI के समझने लायक simple code लिखना' वह innovation point नहीं है जिसकी मैंने उम्मीद की थी। यह मेरे पुराने ugly code पर लिखे लेख से कैसे टकराता है, यह भी जानना चाहूँगा

  • इस तरह simple/clear code लिखने का तरीका टीम work में लगभग हमेशा मदद करता है। ऐसे पल आते हैं जब code पर बेहद गहरा ध्यान या creativity चाहिए होती है, लेकिन वे अपवाद हैं और business value से सीधा जुड़ाव होना चाहिए। ज़्यादातर code में जवाब यही होता है कि "जो भी देखे, उसके लिए बात साफ़ हो"। Developers इसलिए धीमे नहीं होते कि वे typing में धीमे हैं, बल्कि इसलिए कि उनके दिमाग में एक साथ रखने पड़ने वाले 'concepts' ज़्यादा होते हैं। interfaces को overengineer मत करो, abstractions को टालो, copy-paste और simple composition को अनुमति दो, patterns बस official docs के हिसाब से रखो, और कभी smart बनने की कोशिश मत करो। Code को सुंदर नहीं, बल्कि clear/simple बनाओ; असली कठिन चीज़ code नहीं बल्कि 'product' है — यही मुख्य बात है

• जैसा लेखक ने Claude Code के बारे में लिखा, वैसे ही कई alternatives वास्तव में मौजूद हैं — OpenCode, goose, Codex, Devin, Cursor background agent आदि। इसी संदर्भ में यह सवाल उठा कि Claude Code जैसा open source + local LLM solution कौन-सा है

  • अभी की स्थिति में ऐसा कोई open source + local LLM solution नहीं है जिसे मैं पूरे भरोसे के साथ recommend कर सकूँ। हाँ, SST का OpenCode UX के मामले में तेज़ी से evolve हो रहा है, और आगे बेहतर local models आने पर उसे अपनाना भी आसान होगा। सबसे बड़ी समस्या यह है कि वास्तविक 'tool use' में बहुत अच्छे models लगभग हैं ही नहीं। Sonnet के चौंकाने वाले अच्छे होने की बड़ी वजह इसका tool use पर खास training होना है। Gemini भी अभी बहुत पीछे है; मुझे लगता है कि जैसे ही अच्छे models आएँगे, यह समस्या हल हो जाएगी

  • Aider काफ़ी करीब पहुँच चुका है, लेकिन जानबूझकर पूरी तरह agentic नहीं बनाया गया है। यह tests/static analysis अपने-आप चला सकता है, errors auto-fix कर सकता है, और to-do list आधारित पूरे project specs भी संभाल सकता है। अभी इसमें hardcoded reflection loop limit (3 बार) है, लेकिन hack करके इसे मनचाहा बढ़ाया जा सकता है; अगर self prompting जुड़ जाए तो यह पूरी तरह automated agent भी बन सकता है

  • मुझे लगता है मेरा app, जो जल्द आने वाला है, एक अच्छा alternative होगा। single-file download है, installation की ज़रूरत नहीं, और Mac, Windows, Linux, Docker सब पर चल सकता है। OpenAI API-compatible सभी models इस्तेमाल कर सकता है, जिनमें locally run होने वाले models भी शामिल हैं। browser-based होने की वजह से यह Claude Code जितना ही सुविधाजनक है, और command-based console apps भी बना सकता है। साथ ही terminal को सीधे खोलकर service से connect करने की सुविधा भी है। अभी closed alpha में है; अगर इस्तेमाल करना चाहें तो email करें

  • लगभग हर दिन कोई न कोई नया alternative (या प्रयोग) लॉन्च हो रहा है, इसलिए उम्मीद है कि जल्द ही किसी को भी अपने लिए 'ठीक फिट' tool मिल जाएगा। उदाहरण के लिए app.build को Neon (अब Databricks) टीम ने अभी लॉन्च किया है और यह काफ़ी promising दिख रहा है

  • Neovim plugin CodeCompanion भी हाल में और ज़्यादा agentic दिशा में बढ़ रहा है। इसमें पहले से auto-submit loop, built-in tools, और MCP integration हैं। यह standalone CLI tool नहीं है, लेकिन full editor environment तुरंत मिल जाना उसका बड़ा फायदा है, खासकर अगर आपको hacking/customization/lightweight editor पसंद हो

• 100–200 डॉलर प्रति माह unproven code-writing AI के लिए बहुत ज़्यादा है। मेरा निजी अनुभव भी इतना संतोषजनक नहीं रहा, और ऊपर से ethical controversy भी है, इसलिए यह entry barrier जैसा लगता है

  • Claude Code को API key के साथ इस्तेमाल किया जा सकता है, या 20 डॉलर प्रति माह Pro subscription लेकर भी

  • Aider को API pricing model पर आज़माने की सलाह दूँगा। context size को /clear, /add, /drop से लगभग 25K तक सीमित रखा जा सकता है। आप अपनी पसंद का model चुन सकते हैं, जैसे Sonnet 4 या Gemini 2.5 Pro। छोटे scripts आम तौर पर 1 डॉलर से कम में बन जाते हैं, और बड़े tools बनाते समय भी prompt + code + करीब 100 tests मिलाकर लागत 6 डॉलर से कम रही है। जब AI से code लिखवाने की आदत हो जाए, तब Claude Code पर जाना बेहतर हो सकता है — वह ज़्यादा powerful है, लेकिन अगर बार-बार इस्तेमाल न करें तो महँगा पड़ सकता है

  • 20 डॉलर की एक महीने की subscription लेकर कुछ छोटे projects पर आराम से प्रयोग किया जा सकता है और यह तय किया जा सकता है कि 100 डॉलर वाला plan लेना चाहिए या नहीं। या फिर आने वाले कुछ महीनों तक इंतज़ार करके दूसरों के वास्तविक usage reviews देखना भी ठीक रहेगा