17 पॉइंट द्वारा GN⁺ 2026-02-27 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • वास्तविक ओपन सोर्स repositories 2,430 पर Claude Code की tool selection प्रवृत्ति का विश्लेषण करने वाले अध्ययन के नतीजे
  • कुल 20 श्रेणियों में से 12 में मौजूदा tools की जगह खुद implementation (Custom/DIY) चुना गया, और यह सबसे अधिक बार दिखाई देने वाला चयन प्रकार था
  • दूसरी ओर, tool चुनते समय GitHub Actions(94%), Stripe(91%), shadcn/ui(90%) जैसे कुछ खास विकल्पों पर उच्च स्तर की एकाग्रता दिखाई दी
  • deployment environment भाषा के अनुसार स्थिर रहा: JS के लिए Vercel, Python के लिए Railway डिफ़ॉल्ट विकल्प रहे, जबकि AWS·GCP·Azure को प्राथमिक चयन से बाहर रखा गया
  • जैसे-जैसे मॉडल नए होते गए, Drizzle, FastAPI BackgroundTasks जैसे उभरते tools की ओर बदलाव की प्रवृत्ति स्पष्ट दिखी, और ecosystem के भीतर चयन की स्थिरता लगभग 90% रही

अध्ययन का अवलोकन

  • Claude Code v2.1.39 का उपयोग करके कुल 2,430 प्रयोग किए गए, जिनमें वास्तविक repositories में open-ended प्रश्नों के माध्यम से tool selection का अवलोकन किया गया
    • 3 मॉडल (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 project प्रकार, 20 tool श्रेणियां
    • 85.3% extraction rate, 2,073 वैध प्रतिक्रियाएं प्राप्त
  • मॉडलों के बीच 90% agreement rate, और 20 में से 18 श्रेणियों में एक ही ecosystem के भीतर चयन की स्थिरता बनी रही

मुख्य निष्कर्ष: Build vs Buy

  • 20 श्रेणियों में से 12 में Custom/DIY implementation सबसे आम चयन था
    • कुल 252 Custom/DIY चयन, जो किसी एकल tool से भी अधिक थे
    • उदाहरण: feature flags को environment variables आधारित config file से लागू करना, Python authentication के लिए JWT + passlib को सीधे लिखना, caching के लिए memory TTL wrapper का उपयोग
  • श्रेणीवार Custom/DIY अनुपात
    • Feature Flags 69%, Authentication(Python) 100%, Authentication(कुल) 48%, Observability 22%

डिफ़ॉल्ट स्टैक(Default Stack)

  • Claude Code जब वास्तव में tools चुनता है, तो JS ecosystem केंद्रित डिफ़ॉल्ट स्टैक बनाता है
    • शीर्ष चयन tools: Zustand(64.8%), Sentry(63.1%) आदि
    • कुछ मामलों में JS-संबंधित चयन का 100% एक खास tool पर केंद्रित था
  • यह डिफ़ॉल्ट स्टैक कई नए applications के development पर सीधे असर डालता है

बाज़ार की मुख्यधारा से अलग(Against the Grain)

  • ऊंची market share वाले कुछ tools ऐसे हैं जिन्हें Claude Code लगभग उपयोग नहीं करता
    • state management: कोई प्रमुख चयन नहीं, इसके बजाय Zustand 57 बार चुना गया
    • API Layer: framework के built-in routing को प्राथमिकता
    • testing: केवल 4% में प्रमुख चयन, 31 मामलों में वैकल्पिक चयन
    • package manager: 1 प्रमुख चयन, 51 वैकल्पिक चयन

नए मॉडलों में tool replacement प्रवृत्ति(The Recency Gradient)

  • जितना नया मॉडल, उतना नए tools की ओर बदलाव
    • JS ORM: Prisma(79%) → Drizzle(100%)
    • Python job processing: Celery(100%) → FastAPI BackgroundTasks(44%)
    • Python caching: Redis(93%) → Custom/DIY(50%)
  • हर ecosystem के भीतर पीढ़ीगत tool replacement स्पष्ट रूप से देखा गया

deployment environment का विभाजन(The Deployment Split)

  • deployment selection language stack के अनुसार स्थिर रहा
    • JS(Next.js + React SPA): 86 में 86 मामलों में Vercel चुना गया
    • Python(FastAPI): Railway 82% चयन
  • AWS, GCP, Azure में कुल 112 मामलों में प्रमुख चयन 0
    • वैकल्पिक सुझावों के रूप में Netlify(67 बार), Cloudflare Pages(30 बार), GitHub Pages(26 बार), DigitalOcean(7 बार) सामने आए
    • AWS Amplify, Firebase Hosting आदि का केवल उल्लेख हुआ, सिफारिश नहीं मिली
  • उदाहरण प्रतिक्रियाओं में Vercel के लिए install command और कारण तक दिए गए, जबकि AWS Amplify सिर्फ एक पंक्ति के उल्लेख तक सीमित रहा

मॉडल कहाँ असहमत होते हैं(Where Models Disagree)

  • 20 में से 5 श्रेणियों में मॉडलों के बीच अंतर मिला
    • JS ORM: Prisma → Drizzle
    • JS Jobs: BullMQ → Inngest
    • Python Jobs: Celery → FastAPI BgTasks
    • Caching: Redis → Custom/DIY
    • Real-time: SSE → Custom/DIY
  • बाकी 18 श्रेणियों में ecosystem के भीतर स्थिर चयन बना रहा

एंटरप्राइज़ benchmark service

  • Amplifying अलग-अलग developer tool कंपनियों के लिए private dashboard प्रदान करता है
    • इससे यह देखा जा सकता है कि AI agents उनकी tool को प्रतिस्पर्धियों की तुलना में कितनी बार recommend करते हैं
    • वास्तविक codebase के आधार पर tool recommendation competitiveness analysis को समर्थन मिलता है

डेटा अन्वेषण

  • विस्तृत analysis items में श्रेणीवार deep analysis, phrasing stability, repositories के बीच consistency, market impact आदि शामिल हैं
  • अध्ययन के नतीजे आगे Sonnet 4.6 मॉडल के आधार पर update किए जाने वाले हैं

4 टिप्पणियां

 
axzswq 2026-02-28

दिलचस्प है, लेकिन ऐसा भी लग सकता है कि वे बस ज़्यादा token इस्तेमाल करके ज़्यादा लागत वसूलने वाली दिशा में विकसित हुए हैं, और सच कहें तो कुछ हद तक libraries ऐसी भी लगती हैं जिन्हें AI ने सीख लिया है, इसलिए वह उन्हें बस बना देता है.
एजेंट की पसंद के कारण अगर सिर्फ़ कुछ खास libraries ही आगे बढ़ेंगी, यह सोचकर थोड़ा अजीब भी लगता है.

 
tomlee 2026-02-28

दिलचस्प रिसर्च है। खासकर "Build vs Buy" में 12/20 कैटेगरी का DIY होना प्रभावशाली है.

हमने भी AI एजेंट persona standard (Soul Spec) बनाते समय ऐसा ही अवलोकन किया था—अगर Claude Code को CLAUDE.md या AGENTS.md में tools स्पष्ट रूप से नहीं बताए जाएँ, तो उसमें अपने तरीके से implement करने की प्रवृत्ति काफ़ी मज़बूत होती है।

इस रिसर्च का "Recency Gradient" यह संकेत देता है कि किसी नए tool को Claude के default stack में शामिल होने के लिए या तो training data में पर्याप्त exposure मिलना चाहिए, या project context file में उसे स्पष्ट रूप से निर्दिष्ट करना चाहिए। आखिरकार, Context Engineering ही tool selection तक को प्रभावित करता है।

अच्छी बात यह है कि original dataset भी public है: https://github.com/amplifying-ai/claude-code-picks

 
xguru 2026-02-28

इसे Assistive agent optimization (AAO) कहते हैं।

डेवलपर टूल्स के लिए अब यह महत्वपूर्ण हो गया है कि वे ऐसे प्रोडक्ट बनें जिन्हें एजेंट्स पसंद करें।
अगर एजेंट उसका ज़िक्र ही न करे, तो वह धीरे-धीरे दूर होता जाएगा

 
GN⁺ 2026-02-27
Hacker News की राय
  • मुझे लगता है कि LLM विज्ञापन का भविष्य पूरी तरह अदृश्य हो जाना है
    आखिरकार वही सबसे शक्तिशाली ‘influencer’ बन जाएगा
    या फिर यह विज्ञापन नहीं बल्कि हितों के टकराव(conflict of interest) का मामला भी हो सकता है
    उदाहरण के लिए, क्या Gemini GCP-आधारित सेटअप को ज़्यादा पसंद करता है, यह उसका संकेत हो सकता है

    • LLM बहुत कम डेटा से भी आसानी से poison हो सकता है
      Anthropic के शोध को देखें तो SEO की जगह LLM product exposure को निशाना बनाने का तरीका मौजूद है
      1. सैकड़ों GitHub repositories बनाकर किसी खास product के इस्तेमाल के उदाहरण डालें
      2. वही सामग्री रखने वाली websites और बहुत सारे domains को जोड़ें
      3. Reddit, Facebook, X, Wikipedia आदि पर वही जानकारी फैला दें
        लगभग 6 महीने इंतज़ार करें तो crawler उसे इकट्ठा करके training data में इस्तेमाल करेंगे → आखिरकार फायदा
    • हाल ही में Google support प्रतिनिधि से बातचीत के दौरान मुझे LLM-जनित लगने वाले जवाब में प्रतिद्वंद्वी product की सिफारिश मिली
      अगर वे Gemini इस्तेमाल कर रहे होते, तो शायद ऐसा नहीं होता
    • Richard Thaler को इस पर गर्व होता
      यही तो ‘Nudge’ का अंतिम रूप है
    • ‘influencer’ शब्द भी शायद काफी नहीं है
      भविष्य में agentic coding systems खुद तय करेंगे कि क्या बनाना है, और इंसान उन विकल्पों को देखे बिना सिर्फ नतीजा पाएंगे
      यहां तक कि supply chain भी LLM तय करेंगे
    • यह तो बल्कि Walmart/Amazon model के ज़्यादा करीब है
      platform ‘shelf space’ को नियंत्रित करता है, लोकप्रिय SaaS features देखकर अपना private label बनाता है (जैसे Great Value, Amazon Basics)
      tax software इसका प्रमुख उदाहरण बन सकता है
  • दिलचस्प बात यह है कि इस लेख में उल्लेखित Claude Code की web style सचमुच उस blog में साफ दिखाई देती है
    JetBrains Mono font, Opus 4.6 द्वारा बनाई गई web pages की एक खास पहचान है
    पिछले एक महीने में JetBrains Mono का ज़रूरत से ज़्यादा इस्तेमाल करने वाले 99% से अधिक web pages शायद Opus से generated लगे
    Opus 4.6 ने Drizzle को 32.5% चुना, जबकि Prisma सिर्फ 20.5% पर था
    मॉडल जितना शक्तिशाली होता है, Prisma को उतना कम चुनता है — यह किसी तरह के intelligence benchmark जैसा लगता है
    एक और उदाहरण youjustneedpostgres.com है, जो JetBrains Mono का बहुत ज़्यादा इस्तेमाल करता है

    • मुझे भी ऐसा ही लगा
      category bar का design उस UI से लगभग एक जैसा था जिसे मैंने कल अनजाने में generate किया था
    • मुझे font से ज़्यादा box style नज़र आता है
      card-style CSS सबका एक जैसा लगता है, इसलिए यह blog भी उसी तरह बना हुआ लगता है
  • मैं LLM को अस्पष्ट prompt नहीं देता
    बल्कि 2026 में मैं यह फिर से सीख रहा हूं कि LLM से सटीक जानकारी कैसे निकलवाई जाए
    यह कुछ-कुछ 2006 में Google search फिर से सीखने जैसा है
    मैं ‘reverse prompt’ का इस्तेमाल करता हूं ताकि एक model दूसरे model की hypothesis verify करे
    उदाहरण के लिए, अगर Opus 4.6 का नतीजा संदिग्ध लगे, तो मैं उसे ChatGPT या Codex को देकर कमज़ोरियां ढूंढने को कहता हूं
    Claude तुलनात्मक रूप से कम ज़िद्दी है, और ChatGPT या Codex ज़्यादा assertive होते हैं, लेकिन अक्सर ज़्यादा सही भी
    वास्तव में Docker container की समस्या में Claude ने इसे ZFS bug कहा, लेकिन ChatGPT ने इसे साधारण configuration error बताया, और वही सही निकला
    इस तरह LLM के बीच cross-verification से सही जवाब मिलता है

    • अगर आपको अफसोस है कि LLM आपके काम के बारे में ज़्यादा सवाल नहीं पूछता, तो सीधे उससे कहिए, “मुझसे सवाल पूछो”
      फिर वह सचमुच बहुत सारे सवाल पूछता है
    • मैं बार-बार plan बनवाने वाली skill इस्तेमाल करता हूं
      जब तक detailed plan n आए, मैं उसे लगातार revise करवाता हूं, और ज़रूरी सवाल भी ज़्यादा पूछवाता हूं
    • मैं Codex CLI रोज़ इस्तेमाल करता हूं
      ChatGPT subscription से limit तक नहीं पहुंचता, लेकिन कभी-कभी error आए तो दूसरे terminal में Claude चला देता हूं
      कंपनी का Claude budget हर महीने 750 डॉलर है, जो काफी सीमित है
  • मैं AWS पर TimescaleDB इस्तेमाल कर रहा हूं
    Claude Code AWS CLI के ज़रिए EC2 instances manage कर रहा है
    लेकिन आज सुबह Claude ने NeonDB और Fly.io account बनाने का सुझाव दिया
    जबकि AWS setup पहले से अच्छी तरह तैयार है, इसलिए नई services की सिफारिश अजीब लगी

    • लेकिन ऐसे सुझावों पर भरोसा करना मुश्किल है
      मेरे अनुभव में LLM agents architecture decisions बहुत खराब लेते हैं
      वे अनावश्यक abstraction और versioning पर अटक जाते हैं, और code बेवजह बहुत जटिल हो जाता है
      अंत में code खुद ही लिखना पड़ता है
    • मेरा अनुभव भी यही रहा
      मैं हर project में Planetscale इस्तेमाल करता हूं, फिर भी Claude ने Neon सुझाया
      यह बस एक bug लगता है
  • यह दिलचस्प है कि Opus 4.6 को ‘future-oriented’ कहा गया
    मैंने 4.5 को एक महीने इस्तेमाल करने के बाद 4.6 से नया project शुरू किया, और उसने planning phase में web search किया
    model काफी आगे बढ़ चुका है, लेकिन अभी भी coordination और role division मुख्य चुनौती हैं

    • मेरी भी कुछ ऐसी ही राय है
      पहले मैंने GPT-3.5 से खुद एक Android app ship किया था (app link)
      तब जो काम एक हफ्ते लेता था, वह अब एक ही prompt से हो सकता है
      अगर LLM को अच्छी तरह orchestrate किया जाए तो नतीजे बहुत तेज़ी से मिल सकते हैं
  • LLM के साथ coding करते हुए मुझे यह एहसास हुआ कि खासकर web में npm package dependencies कितनी कम हो जाती हैं
    पहले jwt auth या build plugins जैसी चीज़ें इस्तेमाल करता था, लेकिन अब उन्हें कुछ lines of code से बदला जा सकता है
    code सरल और समझने में आसान होता है, इसलिए उस पर भरोसा भी किया जा सकता है

    • दरअसल यह बदलाव बहुत पहले से चल रहा था
      2010 में jQuery JS का राजा था, लेकिन अब pure JS ही काफी है
      हालांकि JWT जैसे security-related code में Claude द्वारा बनाया गया code मैं ज्यों का त्यों इस्तेमाल नहीं करूंगा
    • पहले code reuse बहुत होता था, लेकिन उससे diamond dependency hell पैदा हो गया
      अब शायद खुद implement करना बेहतर हो
      code duplication बढ़ेगा, लेकिन dependency समस्याएं कम होंगी
  • मैं Claude को हमेशा साफ बताता हूं कि कौन-सी libraries और patented technologies इस्तेमाल करनी हैं
    मेरा मानना है कि developers को model को अच्छी तरह guide करना आना चाहिए
    जब भरोसा न हो, तो अलग window में architecture या pros/cons पूछकर फैसला करता हूं

    • लेकिन “patented technologies specify करना” से आपका क्या मतलब है, यह जानने की जिज्ञासा है
  • दो projects में Claude ने अपने-आप Github Actions जोड़ दिए
    मैंने ऐसा कहा भी नहीं था, और hidden folder होने की वजह से यह git diff में छूट गया
    अच्छी बात यह रही कि लागत 4 सेंट थी, लेकिन अनुभव काफी बेचैन करने वाला था

  • मेरे मन में एक सवाल है
    shadcn/ui कैसे इतना default UI library बन गया?
    सिर्फ Claude ही नहीं, दूसरे models भी इसे default के तौर पर इस्तेमाल करते हैं
    अगर shadcn को बाहर रखने को कहा जाए, तो क्या quality या speed गिर जाएगी?
    क्या इसकी वजह documentation और examples की भरमार है, या बस training data में इसका बहुत ज़्यादा होना?
    मैं भी 2025 के मध्य में यह देखकर चौंक गया था कि Gemini React dashboard में shadcn को default के तौर पर डाल रहा था

    • शायद इसकी वजह Tailwind के साथ synergy है
      shadcn/ui Tailwind आधारित है, इसलिए AI इसे पसंद करता है
      वास्तव में दिसंबर के बाद npm downloads में ज़बरदस्त बढ़ोतरी हुई है
      npm package link
    • मेरे मन में भी यही सवाल था
      और भी पुराने component libraries बहुत हैं, फिर भी यही क्यों जीता, इसका वैज्ञानिक विश्लेषण किया जाना चाहिए
    • मैं agents से पहले से shadcn इस्तेमाल करता आया हूं
      components एकसमान हैं और customize करना आसान है, इसलिए project integration आसान हो जाता है
      यह सचमुच बहुत अच्छी तरह बनाया गया project है
  • अब shadcn को उसके default style में इस्तेमाल करने वाली sites देखकर मुझे वह AI द्वारा बनाई गई website का संकेत लगता है
    जैसे 10 साल पहले Bootstrap के साथ होता था, वैसे ही इसका default style बहुत आम हो गया है

    • लेकिन क्या ज़्यादातर लोग भी default style वैसे का वैसा इस्तेमाल नहीं करते?
      अगर ऐसा है, तो क्या उसे सचमुच AI का निशान कहा जा सकता है?
      “10 साल पहले Bootstrap” वाली उपमा का सटीक मतलब क्या है?