20 पॉइंट द्वारा GN⁺ 2025-10-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code सिर्फ एक coding tool नहीं, बल्कि agent operating system के रूप में विकसित हो चुका है, जो filesystem access और Unix command integration के ज़रिए अलग-अलग workflows को support करने वाला एक अभिनव सिस्टम है
  • खास तौर पर Obsidian note system के साथ integration के माध्यम से यह note-taking, research, और विचारों को व्यवस्थित करने की प्रक्रिया को automate करता है, और SSH connection के साथ mobile से भी access होने वाला एक पूरा note operating system बनाता है
  • filesystem access feature इसका मुख्य differentiator है, जो बातचीतों के बीच memory और state को बनाए रखना संभव बनाता है, और ChatGPT या browser-based Claude की गंभीर सीमाओं जैसे context window constraints और memory limitations की समस्या को हल करता है
  • Unix philosophy (simplicity, composability, text stream processing) LLM के tool-use pattern से पूरी तरह मेल खाती है, जिससे 50 साल पुराने design principles आधुनिक AI systems के लिए optimal architecture के रूप में फिर से सामने आते हैं
  • email management automation (Inbox Magic), open source tool (Claudesidian) जैसे practical application examples के ज़रिए यह रेखांकित किया गया है कि filesystem-based agent systems, जटिल multi-agent structures की तुलना में, ज़्यादा reliable और debuggable AI applications बनाने की बुनियाद हैं

Claude Code की खासियत

  • हाल की AI चर्चाओं में मैं हमेशा Claude Code की हैरान कर देने वाली क्षमताओं के बारे में उत्साह से बात करता रहा हूँ, और समझाता रहा हूँ कि यह tool एक साधारण coding assistant से बढ़कर एक पूर्ण agent operating system बन चुका है
  • खास तौर पर Obsidian note app के साथ इसका integration महत्वपूर्ण है; Obsidian, Notion या Evernote से अलग, सभी files को local hard drive पर साधारण Markdown files के रूप में store करता है
    • इसी वजह से यह AI coding tools के लिए एक आदर्श target बन गया, और मैंने शुरुआत Cursor से की थी, लेकिन जल्दी ही Claude Code पर आ गया
    • मैं इस सिस्टम पर इतना निर्भर हो गया कि आखिरकार घर पर एक server सेटअप किया और SSH के ज़रिए smartphone से connect होकर चलते-फिरते notes लिखने, पढ़ने और विचार व्यवस्थित करने का environment बना लिया
  • कुछ हफ़्ते पहले मैं Dan Shipper के AI & I podcast में शामिल हुआ था, जहाँ इस सिस्टम का गहन विवरण दिया; इस लेख में मैं उसके बाद मिली कुछ अतिरिक्त insights साझा कर रहा हूँ

Cursor की तुलना में Claude Code की बढ़त

  • “Claude Code क्यों खास है?” इस सवाल का जवाब देना आसान नहीं था, लेकिन निष्कर्ष यह निकला कि यह हर मामले में Cursor से बेहतर होने की बात नहीं, बल्कि कुछ खास तत्वों का संयोजन असाधारण रूप से अच्छा काम करता है
  • हाल में मैं इसे मौजूदा codebase पर काम करने से ज़्यादा, Claude Code की capabilities के ऊपर पूरी तरह नई चीज़ें बनाने के लिए इस्तेमाल कर रहा हूँ
  • Unix दर्शन के साथ परफेक्ट तालमेल

    • Claude Code का रहस्य उसके tool approach में है; terminal-based application होने के कारण accessibility में कुछ समझौते ज़रूर हैं, लेकिन इसके बदले यह native Unix command integration जैसी शक्तिशाली क्षमता देता है
    • Unix philosophy को Doug McIlroy ने 1978 में Bell System Technical Journal में दस्तावेज़ित किया था, और उसमें चार मुख्य सिद्धांत बताए गए थे:
      • 1. हर program को एक काम बहुत अच्छे से करने के लिए बनाओ। नए काम के लिए मौजूदा program में feature जोड़ने के बजाय नया program बनाओ
      • 2. हर program का output किसी दूसरे, अभी तक अज्ञात program के input के रूप में इस्तेमाल हो सके, यह मानकर चलो
      • 3. software को इस तरह design और build करो कि उसे जल्दी, आदर्श रूप से कुछ हफ़्तों के भीतर, आज़माया जा सके
      • 4. programming effort को कम करने के लिए कम-कुशल श्रम के बजाय tools का उपयोग करो
    • Peter H. Salus ने 1994 की “A Quarter-Century of Unix” में इसका संक्षिप्त रूप इस तरह दिया:
      • ऐसा program लिखो जो एक काम अच्छे से करे
      • ऐसे programs लिखो जो साथ मिलकर काम करें
      • ऐसे programs लिखो जो text streams को संभालें (क्योंकि वही universal interface है)
  • LLM और Unix commands की परफेक्ट जोड़ी

    • ये 50 साल पुराने सिद्धांत ठीक उसी तरह मेल खाते हैं जिस तरह LLM tools का उपयोग करते हैं
    • models लगातार output को input में “pipe” करते रहते हैं (बीच में अपनी fuzziness का उपयोग करते हुए), ठीक Unix के | command की तरह, जहाँ एक command का output दूसरी command के input से जुड़ता है
    • जब model tools को प्रभावी ढंग से combine नहीं कर पाते, तो लगभग हमेशा वजह यह होती है कि tools बहुत ज़्यादा जटिल हैं
    • Claude Code के कमाल की पहली वजह यही है: Unix को चलाने वाले commands LLM उपयोग के लिए पूरी तरह उपयुक्त हैं
      • commands सिर्फ सरल ही नहीं, बल्कि बहुत अच्छी तरह documented भी हैं, इसलिए models के पास training के लिए पर्याप्त source material था
  • filesystem access की क्रांति

    • दूसरा तत्व Claude Code की code लिखने की क्षमता है, और हाल में prose लिखने की क्षमता भी
    • Pragmatic Engineer की Claude Code निर्माण पर गहन पड़ताल पढ़ते समय मुझे जवाब मिला: filesystem access
    • filesystem सब कुछ बदल देता है
      • ChatGPT और browser-based Claude की दो गंभीर कमियाँ हैं: बातचीतों के बीच memory का अभाव, और संकीर्ण context window
      • filesystem दोनों समस्याओं को हल करता है: Claude Code अपने लिए notes लिख सकता है, knowledge जमा कर सकता है, और चल रही summaries बनाए रख सकता है
      • इसके पास state और memory होती है, और यह एक ही बातचीत से आगे भी सोच सकता है

AI Overhang

  • जब मैंने 2022 में पहली बार GPT-3 API का उपयोग किया था, तब मेरा अनुमान था कि भले ही models उस क्षण के बाद बेहतर न हों, फिर भी use cases खोजने में 10 साल लगेंगे
  • models वास्तव में बेहतर हुए हैं (reasoning models ने tool calling को reliable बनाया), और filesystem की खोज इस दावे को साबित करती है
  • Pragmatic Engineer interview में Claude Code के शुरुआती version को बनाने वाले Boris Cherney ने इसे “product overhang” की अवधारणा से समझाया:
    • product overhang का मतलब है कि model किसी खास काम को कर सकता है, लेकिन जिस product में AI चल रहा है वह उस capability को capture करने के लिए बना ही नहीं है
    • models पहले से filesystem navigation कर सकते थे, लेकिन इस क्षमता के इर्द-गिर्द बना product मौजूद नहीं था
  • लेखक का तर्क है कि असली बात filesystem + Unix commands का संयोजन है, लेकिन मूल बिंदु यह है कि model capability पहले से मौजूद थी और बस जागने का इंतज़ार कर रही थी
  • Claude Code, overdesigned interfaces के माध्यम से model capabilities को सीमित करने के बजाय उन्हें capture करता है, इसलिए यह reliable agent systems बनाने के blueprint की तरह काम करता है

कोड से आगे

Claudesidian open source project

  • मैंने Claude Code + Obsidian setup के बारे में बात की थी, और वास्तव में एक कदम आगे बढ़कर “Claudesidian” को open source भी किया
    • इसमें मेरे Claude Code + Obsidian setup में इस्तेमाल होने वाले कई tools और commands शामिल हैं
    • इसे मैंने experimentation ground की तरह इस्तेमाल किया, खासकर early upgrade tools बनाने के लिए
    • अगर केंद्र में changes होते हैं, तो उन्हें अपने Claudesidian में ला सकता हूँ, और AI यह जाँचता है कि update होने वाली files में changes हैं या नहीं; अगर हैं, तो नए updates और मौजूदा changes को smart तरीके से merge करने की कोशिश करता है
  • दोनों projects एक ही Unix philosophy principles का पालन करते हैं: सरल, composable, एक काम अच्छे से करने वाले, और साथ में काम करने वाले tools

Inbox Magic - email automation system

  • एक project पर काम चल रहा है जिसका नाम “Inbox Magic” है (इसके लिए शायद कोई बेहतर नाम सोचा जाएगा), जो अभी launch के लिए तैयार नहीं है लेकिन जल्द साझा किया जाएगा
  • यह Claude Code repository है जिसे Gmail toolset तक access मिला हुआ है, और कई prompts व commands के ज़रिए यह email assistant की तरह काम करती है
  • फिलहाल इसकी functionality काफ़ी सरल है:
    • यह searches चला सकता है या आपकी जगह emails भेज सकता है
    • email classification और email writing style सीखने के लिए full training runs कर सकता है
    • Claude Code और ChatGPT दोनों emails तक पहुँच सकते हैं, लेकिन अक्सर वे सिर्फ एक-दो email ही लाते हैं
    • यह सिस्टम files में लिख सकता है और कई तरह की तरकीबें इस्तेमाल कर सकता है, इसलिए यह “inbox की सभी travel-related emails ढूँढो, travel habits का profile बनाओ, और उसे ऐसे prompt के रूप में इस्तेमाल करो जिसे ChatGPT/Claude असली preferences के अनुसार travel research में उपयोग कर सके” जैसे काम कर सकता है
  • अगर आप इसे test करना चाहते हैं, तो अपना GitHub username भेजें; जैसे ही यह testing के लिए तैयार होगा, इसे साझा किया जाएगा

मुख्य सीख

  • आमतौर पर मैं निष्कर्ष देने से बचता हूँ, लेकिन यहाँ कुछ बातें ऐसी हैं जिन्हें दोहराना ज़रूरी है:
  • 1. filesystem, LLM की memory और state की कमी को हल करने का शानदार tool है और इसका ज़्यादा इस्तेमाल होना चाहिए
  • 2. tool calling को प्रभावी बनाने के लिए Unix philosophy का पालन करने पर ध्यान देना चाहिए
  • 3. Claude Code भविष्य के agent systems का blueprint पेश करता है
    • filesystem + Unix philosophy आज के जटिल multi-agent systems की तुलना में ज़्यादा reliable और debuggable AI agents बनाने का template होना चाहिए
    • व्यवहारिक रूप से, अपने project में tool calling बनाते समय चीज़ों को सरल रखना और main model thread को उन्हें “pipe” करने देना सबसे महत्वपूर्ण है
    • हर agent/chatbot के लिए हल किया जाना वाला बड़ा मुद्दा: context window से गुज़रे बिना pipe करने की क्षमता
  • 4. जो लोग LLM के use cases नहीं खोज पा रहे, वे शायद पर्याप्त कोशिश ही नहीं कर रहे

1 टिप्पणियां

 
GN⁺ 2025-10-02
Hacker News की राय
  • मुझे Claude Code का Unix तरीके से काम करना सच में बहुत पसंद है। दूसरे Unix-स्टाइल टूल आसानी से बनाए जा सकते हैं और Claude उन्हें बिना किसी अतिरिक्त integration काम के तुरंत इस्तेमाल कर सकता है। बस टूल का man page दे दीजिए, Claude उसे दक्षता से इस्तेमाल कर लेता है। MCP या जटिल tool definition की ज़रूरत नहीं पड़ती। मेरे खुद के बनाए browser access टूल के साथ भी यह बिना समस्या काम करता है।

    • हाल ही में LLM युग को देखते हुए मैंने एक ऐसा टूल अपडेट किया जो manpage को बेहतर तरीके से खोजने में मदद करता है: Mansnip। मुझे लगता है इसे STDIO MCP में wrap करना भी अच्छा तरीका होगा। इस कोड पर API जोड़कर server को pip में डालना भी अच्छा रहेगा। यह इतना मुश्किल नहीं लगता।

    • मैं जानना चाहता हूँ कि Claude Code मेरे scripts या tools में browser का इस्तेमाल कैसे करता है। मैं मौजूदा Safari session windows को सीधे नियंत्रित करना चाहता हूँ, लेकिन ज़्यादातर चीज़ें सिर्फ Chrome या अलग नई instance को ही संभालती हैं।

    • एक समय मुझे एहसास हुआ कि Claude से सीधे समस्या ढूँढने को कहने से बेहतर है उसे linter इस्तेमाल करना सिखाना। यह कहीं ज़्यादा प्रभावी है। कौन-सा linter इस्तेमाल करना है, यह तक बताने की ज़रूरत नहीं पड़ी; मैंने बस सूची दी और install किया, तो उसने तुरंत उपयोग शुरू कर दिया। ChatGPT के साथ coding की कोशिश में उपयोगी नतीजे पाने के लिए बहुत ज़्यादा मेहनत करनी पड़ती थी, इसलिए मेरी अपेक्षा कम थी, लेकिन Claude Code में यह सचमुच चौंकाने वाला अनुभव रहा।

  • हर GUI app अलग होता है और अपने-अपने ऊँचे किले जैसा होता है। जैसे OS के भीतर अलग-थलग पड़े छोटे-छोटे राज्य हों। इसके उलट CLI सबके मिलने वाला साझा चौक है, जहाँ data और signal का आदान-प्रदान होता है, एक तरह का information bazaar। इस चौक में आने के लिए किसी विशेष पहचान की भी ज़रूरत नहीं होती। GUI की दुनिया में इसके सबसे करीब Smalltalk आता है, लेकिन वहाँ भी पहले निष्ठा की शपथ लेनी पड़ती है।

    • वास्तव में GUI में भी काफ़ी interoperable और composable systems मौजूद हैं। NextSTEP या dbus इसके उदाहरण हैं। अगर चाहें तो GUI भी खुले API के आधार पर बन सकता है, जिसमें ऊपर सिर्फ graphics जोड़े जाएँ। यह आम नहीं है, लेकिन तकनीकी रूप से संभव है।

    • भले ही वे OS में बंद किलों जैसे लगें, लेकिन आम उपयोगकर्ताओं के लिए GUI apps, CLI apps की तुलना में कहीं अधिक पसंदीदा हैं। अगर सिर्फ CLI होता, तो कंप्यूटर का प्रसार बहुत धीमा होता।

  • सिर्फ इसलिए कि कोई नया उभरता टूल terminal में चलता है, इसका मतलब यह नहीं कि वह अपने आप “सच्चे UNIX philosophy” का implementation बन जाता है। यह तुलना ही समझ से बाहर है। मैं भी Hacker News-स्टाइल clickbait में फँस गया।

    • यहाँ UNIX philosophy का मतलब सिर्फ terminal app नहीं है; असली बात यह है कि आधुनिक LLM shell commands को सीधे चला सकते हैं। इसकी वजह से LLM अब लगभग वे सभी काम कर सकते हैं जो इंसान shell में कर सकता है।

    • UNIX philosophy के मूल में देखें तो, 1) छोटे programs जो एक ही काम करते हैं, 2) वे मिलकर अधिक जटिल काम कर सकते हैं, 3) text stream को universal interface की तरह उपयोग किया जाता है। ये बातें LLM के साथ बहुत अच्छी तरह मेल खाती हैं। exec() जैसे एकल text interface की वजह से हर टूल files पर काम करता है और text के रूप में input/output देता है, इसलिए LLM उसे तुरंत इस्तेमाल कर सकता है। software को इस तरह बनना अनिवार्य नहीं था, लेकिन यह जो संरचना बनी, वह LLM के लिए बिल्कुल उपयुक्त है।

    • ऊपर के तीनों comments भी ऐसे लगते हैं जैसे LLM ने खुद की publicity कराने के लिए लिखवाए हों।

  • एक समय बहुत लोग कहते थे कि CLI खत्म हो चुका है, लेकिन हाल में claude code जैसे tools की वजह से उल्टा CLI एक बेहतर interface बन गया है। मैं इसे लेकर किसी से टकराव नहीं बनाना चाहता, लेकिन यह बदलता परिदृश्य काफ़ी रोचक है।

    • वास्तव में developers समेत skilled users के नज़रिए से “CLI is dead” जैसी बात कभी सुनने को नहीं मिली। आम उपयोगकर्ताओं को GUI आने के बाद CLI गायब सा लग सकता है, लेकिन असल में CLI हमेशा background में मौजूद रहा है। OS X ने एक असली Unix shell दिया, Windows के पास PowerShell है, और Linux तो server market पर पहले से ही छाया हुआ है।

    • मैं खुद custom GUI interfaces भी बना रहा हूँ। कंप्यूटर इस्तेमाल करने के अपने तरीके के मुताबिक पूरा desktop environment तैयार कर रहा हूँ। पहले मुख्यधारा के GUI tools असुविधाजनक लगते थे, इसलिए terminal का बहुत उपयोग करता था, लेकिन अब मेरा अपना UI environment लगातार बेहतर हो रहा है।

  • Claude और Obsidian का संयोजन बहुत अच्छा workflow बनाता है। दोहराए जाने वाले note management के सारे काम मैं AI को सौंप देता हूँ। मैं daily notes को stream of consciousness के रूप में जमा करता हूँ, और वहीं से नए ideas, projects और materials निकालता हूँ। Gemini भी काफ़ी अच्छी तरह काम करता है।

  • LLM और Obsidian integration में एक चीज़ ज़रूर उल्लेखनीय है: plugin। Obsidian plugins को आसानी से customize किया जा सकता है, और JavaScript scripts को local folder से चलाया जा सकता है। Claude Code ऐसे plugins लिखने और संशोधित करने में बहुत अच्छा है। उदाहरण के लिए, मैंने एक custom program बनाया है जो Obsidian files को publish flag के आधार पर Github repo में अपने आप sync करता है, और इसकी वजह से notes अपडेट होते ही Netlify पर मेरी website तुरंत अपडेट हो जाती है।

  • लेखक के लिए omnara.com जैसी, SSH के बिना फोन से सीधे access की जा सकने वाली service अधिक उपयुक्त हो सकती है। मैं Obsidian और Claude Code को headless मोड में लगातार चालू रखकर फोन app से सीधे पहुँचने वाला ऐसा ही environment उपयोग कर रहा हूँ।

  • मैं Claude Code इस्तेमाल करना चाहता हूँ, लेकिन यह ठीक-ठीक नहीं जानता कि local data और files का कितना हिस्सा network पर भेजा जाता है, इसलिए कुछ स्थितियों में इसे अपनाना मुश्किल है।

  • मैंने खुद MCP से निम्नलिखित सुविधा implement की है
    { "name": "unshare_exec", "description": "unshare ke saath Linux namespace mein binary ko chalana", "inputSchema": { "type": "object", "properties": { "binary": {"type": "string"}, "args": {"type": "array", "items": {"type": "string"}} }, "required": ["binary"], "additionalProperties": false } }
    शुरुआत में मैंने सिर्फ unshare का उपयोग किया था और बीच में काफ़ी yak shaving भी हुआ, लेकिन अंत में मैं local पर gemma3 चलाते हुए debian-आधारित utilities को स्वतंत्र रूप से चला पाया, और नतीजे आश्चर्यजनक रहे।

    • क्या आप उस yak का ऊन, यानी तैयार की गई सामग्री, साझा कर सकते हैं? मैंने local LLM के साथ जो अनुभव किए, वे ज़्यादा संतोषजनक नहीं थे।
  • मैं पूरी तरह local आधारित Obsidian, local LLM, और ऐसा environment चाहता हूँ जहाँ सब कुछ open source हो। मैं ऐसे भविष्य की आशा करता हूँ।

    • LLM की वजह से open source programs की उपयोगिता और मूल्य और बढ़ गया है। पहले open source होने के बावजूद code structure समझना मुश्किल होता था, इसलिए खुद बदलाव करना आसान नहीं था। अब LLM की मदद से छोटे patches या नए features जोड़ना कहीं आसान हो गया है। यानी program का open source होना ज़रूरी है ताकि मैं उसे अपनी ज़रूरत के हिसाब से बदल सकूँ, और यह बात अब पहले से कहीं ज़्यादा महत्वपूर्ण है।

    • सिर्फ open-weights काफ़ी नहीं हैं; datasets और training pipeline तक को भी खुद संभाल पाना चाहिए, तभी बात का असली मतलब है। बेशक आम लोगों के पास training pipeline खुद चलाने का infrastructure नहीं होगा, लेकिन data के उपयोग और model training process को पारदर्शी तरीके से समझना ज़रूरी है, तभी असली ownership और bias का मूल्यांकन संभव है।

    • local Org mode, local LLM, सब कुछ Emacs से orchestrate हो, और पूरा environment free software पर चले — यह कमाल होगा। अगर रिटायर होकर मेरे पास बहुत समय हुआ, तो यह वह सपना है जिसे मैं ज़रूर आज़माना चाहूँगा।

    • अगर रुचि हो तो यह लेख सुझाऊँगा: https://laurentcazanove.com/blog/obsidian-rag-api

    • क्या व्यावहारिक आकार के models को local पर चलाना वास्तव में संभव है? खासकर 64GB RAM और single GPU setup वाले development machine के हिसाब से यह मुश्किल लगता है।