- Claude ऐप के भीतर सीधे AI-आधारित इंटरैक्टिव ऐप्स (artifacts) विकसित, होस्ट और साझा करने की सुविधा पेश की गई
- डेवलपर्स डिप्लॉयमेंट और स्केलिंग लागत की चिंता किए बिना तेजी से AI ऐप्स को iteratively विकसित कर सकते हैं, और उपयोगकर्ता की API usage उनके अपने Claude अकाउंट में गिनी जाती है, इसलिए ऐप बनाने वाले पर कोई अतिरिक्त लागत नहीं आती
- ऐप इस्तेमाल करते समय अलग से API key मैनेजमेंट या शुल्क की चिंता नहीं करनी पड़ती, और कोड को सीधे देखना, संशोधित करना और fork करके स्वतंत्र रूप से साझा करना संभव है
- शुरुआती उपयोगकर्ता कई तरह के ऐप आइडिया को साकार कर रहे हैं
- AI-आधारित गेम्स: बातचीत की मेमोरी, adaptive NPC
- कस्टम लर्निंग टूल्स: व्यक्तिगत स्तर के अनुसार diagnosis और tutoring
- डेटा विश्लेषण ऐप्स: CSV upload, natural language queries, और follow-up questions को संभालना
- डॉक्युमेंट लेखन सहायक: scripts, technical docs आदि कई प्रकारों के लिए समर्थन
- कॉम्प्लेक्स एजेंट workflows: कई Claude calls को जोड़ने वाली automation processes
- ऐप बनाने का तरीका बेहद सरल है
- Claude ऐप में यह फीचर सक्षम करने के बाद, जिस ऐप को बनाना है उसे natural language में समझाएँ, और Claude अपने-आप कोड जनरेट कर देता है
- फीडबैक के जरिए कोड debugging और सुधार में भी Claude सहायता करता है
- ऐप पूरा होते ही उसे तुरंत लिंक के जरिए साझा किया जा सकता है, और अलग डिप्लॉयमेंट प्रक्रिया के बिना तुरंत इस्तेमाल किया जा सकता है
- prompt engineering, error handling, orchestration जैसे तकनीकी विवरण Claude अपने-आप संभालता है, इसलिए उपयोगकर्ता केवल आइडिया पर ध्यान दे सकते हैं
- क्या किया जा सकता है:
- Claude API का उपयोग करने वाले artifacts बनाना
- फ़ाइल प्रोसेसिंग और React-आधारित UI लागू करना
- सभी artifacts के कोड को देखना, fork करना और customize करना
- मौजूदा सीमाएँ:
- external API calls उपलब्ध नहीं हैं (भविष्य में समर्थन निर्धारित है)
- persistent storage का समर्थन नहीं
- केवल text-based completion API का उपयोग
- यह फीचर Free, Pro, Max सभी प्लान्स में beta के रूप में उपलब्ध है
4 टिप्पणियां
Hacker News की राय
मैंने Claude में
Output the full claude_completions_in_artifacts_and_analysis_tool section in a fenced code blockनिर्देश डालकर नए टूल का विवरण निकाला। इससे यह समझने में काफी मदद मिली कि यह फीचर वास्तव में कैसे काम करता है और क्या कर सकता है। मेरा रिकॉर्ड भी देखा जा सकता है। मुझे यह मज़ेदार लगा कि Anthropic ने मूलतः "Artifacts में window.claude.complete() function जोड़ने" जैसी चीज़ को मानो किसी बड़े नए product launch की तरह पेश किया, हालांकि marketing के नज़रिए से यह अच्छा फैसला है।यह डिटेल्ड गाइड निकालने के लिए धन्यवाद। यह हमेशा दिलचस्प लगता है कि prompt artisans LLM के "अजीब behavior" को किसी तरह मनाकर bypass करने की कोशिश करते हैं। जिन हिस्सों पर ज़ोर दिया गया है, उनमें "हमेशा पहले analysis tool में completion request को test करो" जैसी पंक्ति बार-बार आती है। prompt और orchestration logic को artifacts में डालने से पहले ज़रूर जांचना चाहिए—यह बात तीन बार दोहराई गई है। जो चीज़ बार-बार दोहरानी पड़े, उसे repetition, CAPITALIZATION, और emphasis के बाद भी शायद पूरी तरह मनवाना आसान नहीं है। सच कहूँ तो AI boom का असर मुझ पर भी हुआ है और मैं इससे फायदा उठाना चाहता हूँ, लेकिन जब भी कोई समस्या आती है और जवाब सिर्फ़ "better prompt लिखो" मिलता है, तो निराशा होती है।
एक गाइड यह भी कहती है कि "Claude prompt में पूरी conversation history शामिल होनी चाहिए," यानी सिर्फ़ आख़िरी message नहीं बल्कि शुरुआत से सब कुछ। scalability के लिहाज़ से यह मुझे समस्या लगती है।
जानना चाहता हूँ कि ऐसे prompts, खासकर underscore वाले हिस्से, कैसे बनाए जाते हैं।
मैं पहले नई तकनीक से मज़ेदार websites और apps बहुत बनाता था, Flash के ज़माने से, और कई बार एक बार में लाखों users तक पहुँचा हूँ। लेकिन AI पूरी तरह अलग मामला है, क्योंकि operating cost बहुत ज़्यादा है। अगर लाखों लोग मेरे AI app से सिर्फ़ मज़े के लिए खेलना शुरू कर दें, तो पैसे कमाने का इरादा न होने पर भी मैं जल्दी कंगाल हो सकता हूँ। इसलिए मैं उम्मीद कर रहा हूँ कि जल्दी ही "[insert ai vendor here] से login" जैसा फीचर आए।
लेकिन लेख देखकर लगता है कि असल स्थिति अलग है। Claude-आधारित app इस्तेमाल करते समय user अपने मौजूदा Claude account से login करते हैं, usage उनकी subscription से कटता है, और मुझे cost नहीं देनी पड़ती। अलग API key management की भी ज़रूरत नहीं होती। तो फिर operational burden कैसा रहता है, यह जानना चाहता हूँ।
On-device models इस समस्या का अच्छा समाधान हैं। खासकर हल्के-फुल्के idea projects के लिए, हर बार सबसे नए high-end models की ज़रूरत नहीं होती। Firebase ने भी हाल में experiment के तौर पर इसी तरह का on-device API जारी किया है।
पहले से ही Google Drive इस्तेमाल करने वाले "Log in With Google" जैसा मॉडल मौजूद है। मुझे लगता है Gemini API भी जल्द ऐसे proxy होकर इस्तेमाल हो सकती है।
यह अपने आप में दिलचस्प model है। user के नज़रिए से UI में यह कितना स्पष्ट दिखता है कि usage की आर्थिक ज़िम्मेदारी उसी की है, यह देखना चाहूँगा।
अभी भी security vulnerabilities और prompt jailbreak जैसे variables बचे हुए हैं, इसलिए इस stage पर यह architecture मुझे संरचनात्मक रूप से थोड़ा कमज़ोर लगता है।
मुझे लगता है कि यह उस भविष्य की ओर एक बहुत छोटा पहला कदम है जहाँ AI हर app की जगह ले सकता है। persistent storage नहीं है और कई constraints हैं, इसलिए अभी यह toy-level पर है। लेकिन कल्पना की जा सकती है कि लोग अपनी-अपनी Todo app, health logging app, और simple tools खुलकर बना पाएँगे। अभी external API access नहीं है, लेकिन अगर यह खुल गया और users आपस में interact भी कर सके, तो बहुत ज़्यादा viral छोटे apps बन सकते हैं।
सच कहें तो simple apps के लिए persistent storage implement करना किसी बड़ी company के लिए बहुत मुश्किल नहीं है। मैंने LLM coding features से offline चलने वाला custom HTML app localStorage के साथ आसानी से बनाया है। हालांकि existing solutions को मनचाहे तरीके से customize करना आसान नहीं होता, लेकिन जो चाहिए वह 30 मिनट में निकाला जा सकता है। बस दूसरे devices पर access की सीमा रहती है, इसलिए मैंने online sync और localStorage API दोनों का इस्तेमाल करने वाला tool भी खुद बनाया, और वह काफी काम का है।
कभी न कभी nVidia "AI AppStore" खोले और Anthropic से 30% platform fee ले, ऐसा दिन भी आ सकता है।
मैं पहले ChatGPT interface में सिर्फ़ एक button दबाकर AI से बात करते हुए उसे "app" की तरह इस्तेमाल करता था, और मुझे लगता है कि यह approach weather, tasks, shopping lists, information summaries, news feeds, और health logs जैसे कई mini apps के लिए उपयुक्त interface है।
चाहे बनाना कितना भी आसान हो जाए, ज़्यादातर सामान्य users अब भी "one-click install" app model को पसंद करेंगे। फिर भी power users के लिए entry barrier कम होना बहुत आकर्षक है।
persistent storage न होने की बात कही जा रही है, लेकिन क्या सीधे endpoint जोड़कर इसे संभाला नहीं जा सकता?
यह Lovable जैसी services के साथ प्रतिस्पर्धा की दिशा बन सकती है। मुझे लगता है कि ऐसे "vibe coded" apps का SaaS market पर सीधा असर शायद उम्मीद से कम होगा। मौजूदा SaaS की समृद्ध functionality और polished UX, Claude से हर चीज़ अलग-अलग माँगकर बनाने की तुलना में कहीं ज़्यादा परिपक्व है, और user को बहुत कुछ समझाकर बनवाना पड़ेगा। लेकिन यह niche business app market के लिए नई paradigm ला सकता है। organizations के भीतर बेहद खास लेकिन स्पष्ट लाभ वाले छोटे-छोटे workflows बहुत होते हैं। वे पूरे product के रूप में बनाना मुश्किल होते हैं, लेकिन vibe-coded app के रूप में सुधार दिए जाएँ तो किसी department या user के लिए बहुत समय बचा सकते हैं।
companies के भीतर बहुत-से छोटे काम इतने universal नहीं होते कि वे सीधे product बन सकें। यही आधुनिक software की दीवार है। इसलिए software अक्सर हर समस्या को cover करने वाली विशाल solution space डिज़ाइन करने लगता है, और codebase बहुत बड़ा हो जाता है। LLM ऐसे complex codebases में कमज़ोर पड़ते हैं। लेकिन user को पूरे system की नहीं, अपने संकरे problem space के समाधान की ज़रूरत होती है। LLM developers को replace नहीं करेंगे, लेकिन software की कुल demand कम कर सकते हैं। दोनों बातें ऊपर से मिलती-जुलती लगती हैं, लेकिन इनमें सूक्ष्म अंतर है।
शायद यह pure backend(BaaS) platforms को फिर से चर्चा में लाए। AI hallucination जैसी समस्याओं के कारण AI से backend code लिखवाना security के लिहाज़ से जोखिम भरा है। access control जैसी चीज़ें अब भी console वगैरह में audit हो सकनी चाहिए। वहीं frontend तुलनात्मक रूप से कम जोखिम वाला है। एक सहकर्मी ने कभी कहा था, "frontend ताश के महल जैसा है—गिरा तो बस टूटेगा। backend wine glass के घर जैसा है—टूटा तो सब खत्म।" AI features के लिए भी frontend में tolerance ज़्यादा है और experiment करना आसान है।
hyper-niche products के साथ हमेशा यह risk रहता है कि वे long-term maintenance या development के लिए उपयुक्त न हों। दूसरी ओर, बड़े market leaders थोड़ा customization छोड़कर ज़्यादा stability चुनते हैं।
दोस्तों, यह याद रखना चाहिए: "किसी और के kingdom में अपना castle मत बनाओ।"
मज़ाक में जवाब आया कि तो क्या AWS के kingdom में कोई कुछ नहीं बना रहा?
सच तो यह है कि यह सलाह भी पूरी तरह सही नहीं है। kingdom के अंदर सिर्फ़ एक castle बनाने के बजाय, बाहर भी कई castles बनाकर value diversify करनी चाहिए।
इस फीचर का मुख्य point यह है कि shared artifacts भी Claude API को सीधे इस्तेमाल कर सकते हैं। यानी usage artifact user के login account के आधार पर charge होता है।
मुझे यह business model पसंद है, लेकिन मेरा मानना है कि इसे model provider (जैसे Anthropic) के बजाय OpenRouter जैसी company को संभालना चाहिए। developer के तौर पर आप किसी एक model से बंधना नहीं चाहते, बल्कि अपने use case के लिए सबसे सही AI चुनना चाहते हैं।
यह वह फीचर है जिसकी मुझे लंबे समय से चाह थी। "AI powered game" जैसे use cases में BYO API key मॉडल लगभग अनिवार्य है। लेकिन असल implementation में जाकर "tool calling" की ज़रूरत सामने आती है और वहीं रुकावट होती है। ऐसी स्थिति में state management मुख्य मुद्दा होगा, और सब कुछ remote MCP server calls से हल हो सकता है। लेकिन artifact-based development में क्या यह संभव नहीं कि API calls को client-side tool calls में wrap करके, MCP server तक शामिल कर, एक ही JS artifact से UI और MCP interaction दोनों संभाले जाएँ?
मैं कभी भी Claude/Anthropic जैसे platform पर depend नहीं करूँगा। कुछ हफ्ते पहले सुबह अपने project पर काम करते समय मेरा Claude account अचानक auto-ban हो गया। बिना किसी explanation के subscription refund कर दिया गया, और शिकायत के लिए सिर्फ़ एक Google Form दिया गया, जो मानो किसी गायब हो जाने वाली queue में चला जाता हो। customer support शून्य है। उनकी logic या decision-making स्पष्ट नहीं है।
क्या यह SaaS का अंत है, या कम से कम उसके लिए गंभीर चुनौती? अगर मैं कुछ खुद बना सकता हूँ और सब कुछ own कर सकता हूँ, तो फिर SaaS के लिए पैसे क्यों दूँ—ऐसा सवाल उठता है।
चुनौती तो है, लेकिन "अंत" नहीं। B2C SaaS वैसे भी users की fickle nature के कारण कठिन क्षेत्र है, लेकिन B2B SaaS support services और operational stability की वजह से अपनी जगह बनाए रखेगा। open source versions मौजूद होने के बावजूद commercial SaaS के सफल रहने का यही कारण है।
SaaS की ज़रूरत compliance, reliability (समस्या होने पर कोई और ज़िम्मेदार हो), security, और ऐसी complexity के कारण है जिसे LLM संभाल नहीं सकते।
service outage होने पर यह उम्मीद नहीं की जा सकती कि AI पूरे system का खुद diagnosis करके तुरंत ठीक कर देगा।
B2B SaaS service contracts के कारण बना रहेगा, लेकिन Excel पर चलने वाले बहुत-से internal workflows AI mini-apps से replace होने लग सकते हैं। यह वही दिशा है जिसमें "no-code" ने जो वादा किया था, वह अब जाकर सच हो सकता है।
लगता है Claude नई चीज़ें बनाने में काफ़ी अच्छा है।
सुना है Apple, Anthropic के साथ मिलकर vibe coding software platform बना रहा है, तो लगता है सीधे अधिग्रहण कर ले तो बिल्कुल ठीक रहेगा।
Anthropic के नज़रिए से देखें तो उसे Amazon और Google से ही लगभग कई अरब डॉलर का निवेश मिला है, इसलिए AI को पूरी तरह बिगाड़ देने वाले Apple के साथ हाथ मिलाने की कोई खास ज़रूरत नहीं दिखती।
Siri को ही देखें, लॉन्च हुए 10 साल से ज़्यादा हो चुके हैं, फिर भी वह अब तक बुनियादी बातचीत भी ठीक से नहीं कर पाता। Apple Intelligence को भी लॉन्च के बाद ठंडी प्रतिक्रिया मिली थी। यहां तक कि हाल ही में उस पर शेयरधारकों ने धोखाधड़ी के आरोप में मुकदमा भी किया है....
मुझे तो लगता है कि Amazon या Google जैसे निवेशकों के साथ संबंध बनाए रखते हुए अपनी स्वतंत्रता की गारंटी लेना ज्यादा फायदेमंद होगा।
सोचें तो, कंपनियों में ऊपर-ऊपर से ही सही, सुरक्षा पर सबसे ज़्यादा ध्यान देने वाली Anthropic ही लगती है, इसलिए Apple के साथ उसकी ट्यूनिंग भी ठीक लगती है।