Stash - AI एजेंट्स के लिए persistent memory layer

 (alash3al.github.io)
2 पॉइंट द्वारा GN⁺ 3 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक persistent memory layer है जो session बदलने पर भी बातचीत और काम का context जारी रखती है; raw observations को episodes के रूप में स्टोर करने के बाद उन्हें structured knowledge में जमा करती है
  • model-agnostic architecture का उपयोग करके Claude, GPT, local LLM और custom agents तक को उसी memory layer से जोड़ा जा सकता है, और storage PostgreSQL व pgvector पर आधारित है
  • यह RAG से अलग भूमिका निभाता है; केवल document retrieval तक सीमित नहीं रहता, बल्कि बातचीत से नए facts, relationships, goals, failures और hypotheses तक जमा करता है, और RAG के साथ मिलकर भी इस्तेमाल किया जा सकता है
  • namespace और hierarchical paths से user, project और agent self-knowledge को अलग रखता है, और consolidation pipeline के ज़रिए facts, relationships, causal links, patterns, contradictions को लगातार synthesize करता है
  • MCP native integration, /self आधारित self-model, और iterative research loop तक शामिल हैं, ताकि बिना memory वाले session-based agents को long-term continuity वाले working agents में बदला जा सके

Stash का अवलोकन

  • यह एक persistent memory layer है जो AI agents और बाहरी दुनिया के बीच रहती है, और session बदलने पर भी पहले का context जारी रखती है
  • raw observations को episodes के रूप में स्टोर करती है, और उन्हें facts, relationships, patterns, goals, failures, hypotheses जैसे structured knowledge में जमा करती है
  • यह model को replace नहीं करती, बल्कि continuity को मजबूत करती है, और Claude, GPT, local models जैसे किसी भी agent से जोड़े जाने के लिए डिज़ाइन की गई है
  • storage backend के रूप में PostgreSQL + pgvector का उपयोग करती है
  • GitHub

मेमोरी की संरचना कैसे होती है

  • namespace के माध्यम से user, project और agent self-knowledge जैसी memories को अलग किया जाता है
  • हर namespace hierarchical paths से बना होता है, और /projects पढ़ने पर /projects/stash, /projects/cartona जैसे subpaths भी साथ शामिल होते हैं
  • write केवल एक exact namespace में रिकॉर्ड होती है, जिससे memory pollution रोका जाता है
  • user-related memory, project memory और /self के नीचे की self-knowledge आपस में मिश्रित नहीं होती
  • उदाहरण संरचना में /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences शामिल हैं

RAG से अंतर

  • RAG अधिकतर documents से संबंधित सामग्री खोजकर लाने वाली retrieval layer के करीब है, और बातचीत को खुद याद नहीं रखती या उससे सीखती नहीं है
  • RAG केवल वही संभाल सकती है जो documents में पहले से मौजूद हो, और बातचीत से नया knowledge नहीं बना सकती
  • goal tracking, intent understanding, समय के साथ contradictions की पहचान, और cause-effect reasoning को RAG की सीमा के बाहर बताया गया है
  • Stash बातचीत, decisions, success और failure से अपने-आप सीखती है और knowledge graph बनाती जाती है
  • document retrieval और experiential memory अलग-अलग समस्याएँ हैं, इसलिए RAG और Stash को साथ में इस्तेमाल किया जा सकता है

मौजूदा AI memory से क्या अलग है

  • Claude.ai और ChatGPT में memory है, लेकिन यह सुविधा उनके अपने platform और अपने model से बंधी हुई है
  • Stash model-agnostic तरीके से काम करती है, और local या private models से भी जोड़ी जा सकती है
  • data ownership user के पास रखती है, और open source के रूप में उपलब्ध है
  • इसमें background consolidation, goals और intent tracking, failures से learning, causal reasoning, और agent self-model जैसी क्षमताएँ शामिल हैं
  • तुलना तालिका के अनुसार ChatGPT Memory और Claude.ai Memory को “notepad”, जबकि Stash को “mind” के रूप में दिखाया गया है

यह किस समस्या को हल करना चाहती है

  • आज के AI models reasoning में अच्छे हैं, लेकिन sessions के बीच memory न होने के कारण user को हर बार अपने बारे में और project background फिर से समझाना पड़ता है
  • हर बार लंबे conversation logs को prompt में डालना धीमा और महंगा है, और context window की सीमा भी बनी रहती है
  • failed attempts को अगली session में दोहराने से रोकने के लिए lessons transfer mechanism की कमी है
  • memory feature कुछ platforms की proprietary सुविधा तक सीमित है, इसलिए custom agents और local LLM शुरुआत से बिना context के शुरू होते हैं

consolidation pipeline

  • background process अनुभवों को लगातार synthesize करके raw memory को structured knowledge में बदलती है
  • Episodes चरण में observations को append-only रूप में स्टोर किया जाता है
  • Facts चरण में episode groups को LLM की मदद से synthesize किया जाता है
  • Relationships चरण में facts के बीच entity relationships निकाली जाती हैं
  • Causal Links चरण में facts के बीच cause-effect pairs जोड़े जाते हैं
  • Patterns चरण में उच्च-स्तरीय abstract patterns निकाले जाते हैं
  • Contradictions चरण में self-correction और confidence decay किया जाता है
  • Goal Inference active goals से संबंधित facts को अपने-आप track करता है और progress व conflicts को सामने लाता है
  • Failure Patterns दोहराई जाने वाली गलतियों का पता लगाकर उन्हें नए facts के रूप में निकालता है, ताकि वही failure फिर न दोहराया जाए
  • Hypothesis Scan नए evidence के आधार पर open hypotheses को बिना manual intervention के verify या reject करने देता है

MCP integration

  • यह MCP native है और Claude Desktop, Cursor, OpenCode, custom agents, local LLM और अन्य MCP clients से जोड़ा जा सकता है
  • SDK के बिना connect किया जा सकता है, और vendor lock-in के बिना कहीं से भी उसी memory layer का उपयोग कराया जा सकता है
  • कुल 28 tools दिए गए हैं, जिनमें remember, recall, forget, init से लेकर causal links, contradictions, hypotheses तक शामिल हैं
  • ./stash mcp execute --with-consolidation के जरिए stdio MCP server और consolidation को साथ शुरू किया जा सकता है
  • ./stash mcp serve --port 8080 --with-consolidation से remote agents के लिए SSE server चलाया जा सकता है

agent self-model

  • init call के समय /self namespace का skeleton बनाकर self-model तैयार करना शुरू किया जाता है
  • /self/capabilities में agent किन कामों में अच्छा है, यह याद रखा जाता है ताकि task planning में उपयोग हो सके
  • /self/limits में failure history और कमजोरियाँ रखी जाती हैं, ताकि वही गलती दोहराने से बचा जा सके
  • /self/preferences में सबसे अच्छा काम करने वाले operating styles सीखे जाते हैं, जो लंबे समय में कार्य-शैली बनाते हैं

autonomous learning loop

  • 5 मिनट का research loop चलाने पर यह past memory से current context पकड़ता है, खुद topic चुनकर research करता है, नए connections बनाता है, फिर consolidate करके रुक जाता है
  • Orient चरण में past context, active goals, open hypotheses और past failures को लाया जाता है
  • Research चरण में agent खुद चुने गए topic पर web search करता है
  • Think चरण में अभी जो जाना गया है उसके भीतर tensions, gaps और contradictions सामने लाए जाते हैं
  • Invent चरण में hypotheses, patterns और discoveries जैसे नए outputs बनाए जाते हैं
  • Consolidate चरण में pipeline चलाकर raw episodes को structured knowledge में synthesize किया जाता है
  • Reflect + Sleep चरण में session summary छोड़ी जाती है और अगली run के लिए context सेट करने के बाद यह रुक जाता है
  • लूप प्रॉम्प्ट देखें

model और infrastructure compatibility

  • embedding और reasoning दोनों के लिए OpenAI-compatible API का उपयोग करने वाली एक provider configuration को आधार माना गया है
  • cloud, local और self-hosted setups सभी को support किया जाता है, और vendor lock-in न होने का दावा किया गया है
  • लिखा है कि OpenRouter को local रूप से जोड़कर इस्तेमाल किया जा रहा है, जिससे सैकड़ों models तक एक ही API key से पहुँचा जा सकता है
  • Ollama के साथ भी यह सीधे काम करता है, और Qwen, Llama, Mistral जैसे local models के साथ offline memory setup संभव है
  • vLLM, LM Studio, llama.cpp server, Together AI, Groq जैसे OpenAI API format इस्तेमाल करने वाले backends भी supported targets में शामिल हैं
  • default embedding model openai/text-embedding-3-small है, और उस संयोजन में STASH_VECTOR_DIM=1536 उपयोग होता है
  • STASH_VECTOR_DIM को पहली run से पहले ही सेट किया जा सकता है; initialization के बाद इसे बदलने पर पूरा database reset करना पड़ता है

deployment और usage जानकारी

  • Docker Compose के जरिए Postgres, pgvector, Stash को साथ चलाने वाली configuration दी गई है
  • setup प्रक्रिया को 3 चरणों में बताया गया है: repository clone करना, .env.example को .env में copy करना, फिर API key और model सेट करके docker compose up चलाना
  • पहली run के बाद postgres + pgvector तैयार होना, migration apply होना, MCP server wait state में होना, और background consolidation चलना अपेक्षित है
  • project Apache 2.0 license के तहत उपलब्ध है
  • GitHub Repository
  • alash3al.com

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 일 전
Hacker News की राय

  • मैंने यह सोचकर क्लिक किया था कि आखिरकार Claude.ai memory system जैसी चीज़ को portable बना दिया गया है, लेकिन ऐसा बिल्कुल नहीं था
    यहाँ बस store/remember वाला तरीका है, और मुझे जो बेहतर लगा वह यह है कि background model chat history को summarize करके memory बनाता है
    उस तरीके में model को खुद memory लिखनी नहीं पड़ती, इसलिए वह कहीं बेहतर काम करता है, और इसी वजह से इसे Claude.ai के स्तर का बताना थोड़ा misleading लगता है
    मैं भी LibreChat जैसी किसी चीज़ पर जाने के लिए इसी तरह का memory system ढूँढता रहा हूँ, लेकिन अभी तक नहीं मिला, और फिलहाल Claude.ai पर बने रहने की लगभग यही एकमात्र वजह है
    वैसे, वह system सिर्फ Claude.ai में है, Claude Code में नहीं

    • हाल की Claude Code leak के अनुसार autoDream नाम की कोई चीज़ थी, जिसे यहाँ background memory consolidation engine कहा गया है: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
    • मैं सच में यह approach इस्तेमाल करके देखना चाहता हूँ
      मेरा अनुभव तो बिल्कुल उल्टा रहा है; मैंने https://github.com/flippyhead/ai-brain मुख्यतः अपने लिए बनाया था, और कुछ दोस्त भी इसे इस्तेमाल करते हैं
      अभी तक CLAUDE.md के ज़रिए AI से relevant memory ढूँढने और यह सोचने को कहना कि कब और कैसे उसे save करना है, काफ़ी अच्छा काम कर रहा है
      इस तरीके में priority के हिसाब से structure बनाया जा सकता है और भविष्य के लिए notes भी छोड़े जा सकते हैं, इसलिए यह सब कुछ बस summarize कर देने से काफ़ी अलग लगता है
    • मैं पसंद करता हूँ कि automatic recall agent को दिखे बिना काम करे
      memory generation tool call से भी काफ़ी अच्छी तरह हो जाती है, और context compression के समय अपने-आप memory बनाना भी ठीक लगता है
      लेकिन अगर generation automatic है, तो asynchronous consolidation ज़रूरी है, और उसे dreaming कहना मुझे थोड़ा बढ़ा-चढ़ाकर कहना लगता है
      मेरा implementation Elroy.bot में है, और अलग-अलग approaches मैंने यहाँ लिखी हैं: https://tombedor.dev/approaches-to-agent-memory/
    • मुझे जिज्ञासा है कि इसे कैसे benchmark किया जाता है
      अगर background में memories निकाली जाएँ, तो उन्हें prefix cache के साथ ठीक से फिट करना मुश्किल हो जाता है
      एक साधारण 2-stage LOG.md (काम और सीखे गए सबक की detailed log) + MEMORY.md (log truncate होने पर promote की गई entries का रिकॉर्ड) + turn के अंत में चलने वाला stop hook भी काफ़ी दूर तक ले जा सकता है
    • यह concept काफ़ी दिलचस्प है
      ऐसा लगता है जैसे user से बात कर रहे agent के पीछे कुछ सहायक लोग बातचीत सुन रहे हों, महत्वपूर्ण तथ्य लिख रहे हों, या DB से संबंधित बातें ढूँढ रहे हों और बीच में बोल पड़ें कि यह memory X शायद relevant है
      अगर token मुफ़्त होते तो यह आसान लगता, लेकिन इसे efficiently बनाना काफ़ी मज़ेदार समस्या है

  • जो project implementation के बारे में लगभग कुछ नहीं बताता और बस वादे करता है, वह हमेशा बड़ा red flag लगता है
    थोड़ा और देखें तो यह लगभग pg_vector पर mcp और recall/remember दो functions जोड़ देने जैसा है
    आखिरकार यह RAG के ज़्यादा क़रीब है, और आप कह सकते हैं कि data structure महत्वपूर्ण है, लेकिन अब तक ऐसे memory systems लगभग सब एक जैसे ही काम करते रहे हैं
    अभी तक मैंने ऐसा कोई उदाहरण नहीं देखा जो साबित करे कि search साधारण vector DB search से बेहतर हो गई है

    • site अच्छी दिखती है, उस पर memory लिखा है, और यह दिखाया जाता है कि LLM भले ख़राब हो लेकिन यह product जादू की तरह सब ठीक कर देगा
      अगर यह सच में ऐसा करता है, तो आखिरकार यह बस vectordb को अच्छी packaging में पेश करने जैसा भी हो सकता है

  • इसका review पहले से मौजूद है: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
    कई दूसरे LLM memory systems भी यहाँ इकट्ठा किए गए हैं: https://zby.github.io/commonplace/agent-memory-systems/
    और ऐसी systems से क्या अपेक्षा होनी चाहिए, वह भी यहाँ लिखा है: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

  • ऐसे agent memory systems एक साथ overengineered भी लगते हैं और underdesigned भी, और काफ़ी हद तक dead end जैसे दिखते हैं
    यह कल्पना करना मुश्किल है कि जो चीज़ आज के models को चाहिए, उससे ये जल्दी ही mismatch होकर सड़ न जाएँ
    उदाहरण के लिए, आपने एक बार payments feature बनाया और don't use stripe जैसी memory रह गई, तो बाद की कई sessions अनावश्यक रूप से payments की दिशा में झुक सकती हैं

    • इससे भी बुरा यह है कि लेखक ने खुद इसे इस्तेमाल किया हो, ऐसा कोई ठोस संकेत भी बहुत कम दिखता है
      यह पूरी तरह unproven memory layer लगता है, बिना किसी real screenshots के बस चमकदार marketing site और बढ़ा-चढ़ाकर किए गए दावे
    • मैं इसे information problem की तरह देखता हूँ, और मैंने एक छोटा utility बनाया है जो जानबूझकर ज़्यादातर चीज़ें save नहीं करता: https://github.com/skorokithakis/gnosis
      मूल विचार सरल है। जो बातें LLM पहले से जानता है, वह तो जानता ही रहेगा, इसलिए LLM ने जो कहा उसे save नहीं करना चाहिए, और code से जुड़ी बातें code और comments में रहनी चाहिए
      लेकिन कुछ चीज़ें ऐसी होती हैं जो इन दोनों में नहीं आतीं और फिर भी कभी capture नहीं होतीं
      कुछ बनाते समय अक्सर आपने वास्तव में क्या किया उससे ज़्यादा महत्वपूर्ण यह होता है कि क्या न करने का फैसला किया
      यह utility session के अंत में reject किए गए alternatives और उनके कारण पकड़कर उन्हें system knowledge के रूप में save करती है
      असल में मैं ऐसी जानकारी बचाकर रखना चाहता हूँ जो code grep से नहीं मिलेगी और जो सिर्फ teammates के दिमाग़ में होती है, और अभी तक यह काफ़ी अच्छा काम कर रही है, हालाँकि अभी शुरुआती दौर है
    • मैं अपना बनाया हुआ bespoke memory system इस्तेमाल करता हूँ, जिसमें हर memory को context-specific search space में रखा जाता है ताकि यह समस्या न आए
      don't use stripe जैसी memory तभी context में आएगी जब model को payment processing से जुड़ा काम करने का prompt दिया जाए

  • मैं ऐसी चीज़ लगातार ढूँढ रहा था, और यह देखकर अच्छा लगा कि यह account LLM boom से पहले से software publish करता आ रहा है
    लेकिन अच्छा होता अगर हर project के साथ LLM usage history जैसी कोई चीज़ भी जुड़ी होती
    क्या यह LLM से generate किया गया था, अगर हाँ तो कितना, किस चरण में LLM का उपयोग हुआ, output को कितनी सावधानी से review किया गया, और क्या quality अकेले बनाने जितनी या उससे बेहतर लगी — ऐसी जानकारी उपयोगी होती
    मेरा मकसद किसी एक व्यक्ति पर शक करना नहीं है; मैं चाहता हूँ कि यह हर project में सामान्य रूप से हो, और मैं खुद भी ऐसा करने का सोच रहा हूँ

    • ईमानदारी से कहूँ तो यह थोड़ा entitled लगता है
      कोई किसी पर यह project इस्तेमाल करने के लिए ज़ोर नहीं डाल रहा; आप code खुद पढ़िए, review कीजिए, फिर तय कीजिए कि इस्तेमाल करना है या नहीं
    • सवाल वाजिब है, लेकिन मुझे नहीं लगता कि इसका जवाब सिर्फ संबंधित व्यक्ति की self-reporting पर छोड़ा जा सकता है
      बहुत कम लोग ईमानदारी से मानेंगे कि उन्होंने ठीक से design या testing नहीं की और code quality भी अच्छी नहीं है
      शायद ऐसे सवालों का जवाब देने के लिए किसी third-party system की ज़रूरत पड़े, हालाँकि अगर वह भी LLM-based हो तो वह भी काफ़ी subjective हो सकता है
    • LLM के साथ software बनाने के तरीके सच में बहुत अलग-अलग हो सकते हैं
      मैं इन दिनों ज़्यादातर projects को कई Markdown files के इर्द-गिर्द चलाता हूँ, जहाँ AI से पहले research, planning और implementation progress tracking कराता हूँ
      implementation plan के अनुसार step-by-step होती है और हर step पर review भी जारी रहता है
      अगर मुझसे मेरा workflow document करने को कहें, तो वही files असल में उसका दस्तावेज़ हैं
      code का 99% generate होता है, लेकिन मैं इस बात का ध्यान रखता हूँ कि वह मेरी पसंद के तरीके से generate हो, और अक्सर नतीजा अकेले बनाने से भी बेहतर लगता है
    • मुझे समझ नहीं आता कि यह इतना महत्वपूर्ण क्यों है
      अच्छा software और ख़राब software, दोनों LLM के बिना भी बन सकते हैं और LLM के साथ भी
      आप किसी बढ़ई से यह नहीं पूछते कि उसने हथौड़ा इस्तेमाल किया या nail gun, या roof और deck पर किसका इस्तेमाल किया
      अगर trust की बुनियाद नहीं है, तो अंत में आपको quality खुद verify करनी होगी या फिर खुद बनाना होगा; इसके अलावा बाकी सब कुछ बस उम्मीद पर टिका रहता है

  • मुझे अभी तक कोई उपयोगी memory नहीं मिली
    एक तरीका agents.md जैसी high-level summary छोड़ता है, लेकिन वह ठोस details में मदद नहीं करता, जैसे अगर इस element को बदलो तो उस element को draft mark करना होगा
    दूसरी ओर, बहुत detailed approaches इतनी बारीकियों से भर जाती हैं कि या तो उन्हें नज़रअंदाज़ कर दिया जाता है, या एक feature area की detail दूसरे area के बदलावों को दूषित करने लगती है
    अब तक मेरे लिए सबसे अच्छा तरीका memory के बिना काम करना रहा है, यानी हर session/prompt के लिए सिर्फ वही context हाथ से चुनना जो वास्तव में महत्वपूर्ण हो

    • मुझे memory में काफ़ी दिलचस्पी है, लेकिन कम से कम coding tools के लिए यह बहुत उपयोगी नहीं लगती
      repository क्या करती है और क्या करना चाहिए, इसका source of truth आखिरकार repo itself ही है
      जो आप बता रहे हैं वह memory से ज़्यादा code review guidelines जैसा लगता है, और ऐसी चीज़ें बदलाव के समय explicitly context में डाल देनी चाहिए
      memory systems इसके मुक़ाबले बहुत ज़्यादा complex हैं और accuracy भी कम है
    • ऐसे systems के लिए wishlist यहाँ है: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    • मेरा अनुभव भी कुछ ऐसा ही है
      मैं सोचता हूँ कि क्या कभी ये models continual learning हासिल करेंगे
      ये पहले से काफ़ी smart हैं, लेकिन असली memory न होने से इनके साथ काम करना झंझट भरा लगता है
    • Claude ने जो memories बनाई थीं, उनमें लगभग सब remember-to-not-forget तरह की थीं, इसलिए मैंने अंततः वह feature बंद कर दिया

  • मेरे लिए कुछ सरल चीज़ें काफ़ी अच्छी तरह काम करती हैं, tool Codex है

    1. हमेशा up-to-date रहने वाली detailed functional specification
    2. कई projects में structured codebase
    3. अच्छे naming और documentation वाला code। class, variable, और function names चाहे कितने लंबे या अजीब क्यों न लगें, उनका उद्देश्य साफ़ होना चाहिए, और ऐसे नियम मैंने Agent.md की coding guidelines में रखे हैं
      मेरी functional spec agent के लिए Project.md का काम करती है
      और हर बार agentic code review से पहले मैं project directory tree बनाता हूँ, उसे codebase के साथ मिलाकर एक single file में बदलता हूँ, और filename में timestamp जोड़ देता हूँ
      यह हैरानी की बात है कि यह कितना महत्वपूर्ण साबित हुआ; इससे LLM के पुराने versions refer करने की संभावना कम होती है, और git भेजे बिना भी जल्दी diff देखना आसान हो जाता है
      अब तक बड़े और जटिल codebases में भी यह simple workflow काफ़ी अच्छा चला है
      token efficiency अच्छी नहीं है, लेकिन यह बस काम करता है
      हर बार पूरे codebase को merge करना ज़रूरी नहीं; जो projects पहले ही पूरे हो चुके हैं, test हो चुके हैं, या मौजूदा काम से संबंधित नहीं हैं, उन्हें छोड़ा जा सकता है
      फिर भी उन्हें printed directory tree में रखा जाता है, ताकि agent कम से कम उनके अस्तित्व से परिचित रहे और ज़रूरत होने पर specific files माँग सके
    • दिलचस्प approach है
      वह merge process आप कैसे करते हैं, यह जानने की जिज्ञासा है
      क्या वह manual है, सिर्फ changed files को merge करते हैं, या hybrid तरीका है?

  • LLM memory सिद्धांत में अच्छी लगती है, लेकिन व्यवहार में जैसे-जैसे वह बड़ी होती है, memory न होने की स्थिति जितनी ही गंदी हो जाती है
    पहले स्क्रीन वाले उदाहरण की तरह मेरे project पर काम जारी रखो कहना अच्छा लगता है, लेकिन असल दुनिया में लोग अक्सर सिर्फ एक project पर काम नहीं करते
    5 या 10 projects तक memory में हो सकते हैं, और save करते समय उन सबका मतलब रहा होगा
    अंत में फिर आपको sass project पर काम जारी रखो जैसा कुछ निर्दिष्ट करना पड़ता है, और थोड़ी-बहुत detail context मिलने की कीमत पर LLM context भर जाता है और अतिरिक्त MCP calls का खर्च भी उठाना पड़ता है

    • बात सही है, लेकिन यह बहुत naive implementation है
      अगर implementation सही तरह से बनाई जाए, तो शायद इन सीमाओं से आगे निकला जा सकता है
    • अंत में जब आप साफ़-साफ़ बताने लगते हैं कि क्या याद रखा जाए, तो यह लगभग AI से files में write/read करवाने जैसा ही हो जाता है

  • मुझे लगता है कि क्या यह सिर्फ अकेले काम करने वाले vibecoder के लिए है
    जब आप असली लोगों और असली projects के साथ काम करते हैं, तो इस system के पास पूरे project की memory हो ही नहीं सकती, और मेरे पास भी नहीं होती
    जैसे ही कोई दूसरी PR merge होती है, मेरी अपनी जानकारी पुरानी हो जाती है, और मैं तो बस अपने ticket की ही परवाह करता हूँ
    इसलिए मुझे धीरे-धीरे लगने लगा है कि शायद यह उस तरह के collaborative काम के लिए tool ही नहीं है

  • अब जबकि software बनाना लगभग शून्य लागत के क़रीब पहुँच गया है, तब भी किसी का इसे vibe-coded marketing site के ज़रिए बेचना चौंकाता है
    कौन ऐसी चीज़ को इस्तेमाल करके कई हफ़्तों या महीनों तक इंतज़ार करेगा यह देखने के लिए कि यह सच में काम करती भी है या नहीं
    site पर कहीं भी यह प्रमाण नहीं है कि यह RAG से बेहतर है, या memory files के folder और grep से बेहतर है
    फिर भी उस पर बस शानदार दावे किए गए हैं, और scroll भी 14fps पर अटकती है
    यह 24 घंटे पहले बनाया गया लगता है, और सच कहूँ तो बहुत आलसी-सा महसूस होता है