Claude Code का उपयोग: HTML की चौंकाने वाली प्रभावशीलता

 (twitter.com/trq212)
2 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code में Markdown की जगह HTML को output format के रूप में इस्तेमाल करने पर visualization, रंग, diagram और interactivity को अधिक समृद्ध तरीके से शामिल किया जा सकता है, जिससे इंसानों के लिए पढ़ना और review करना आसान परिणाम मिलते हैं
  • HTML tables, CSS, SVG, script, JavaScript interactivity, images, canvas और absolute positioning का उपयोग करके Claude द्वारा पढ़ी जा सकने वाली अधिकांश जानकारी को प्रभावी ढंग से व्यक्त कर सकता है
  • Claude Code file system, MCP, browser और Git history जैसे context को पढ़कर उन्हें HTML परिणामों में पिरो सकता है, और शुरुआत सिर्फ “HTML file बना दो” कहने से की जा सकती है
  • मुख्य उपयोग के तरीके हैं spec·plan·exploration, code review और code understanding, design और prototype, report·research·learning, और customized one-off editing interface
  • HTML को Markdown की तुलना में generate होने में 2~4 गुना अधिक समय लगता है और उसका diff ज़्यादा noisy होता है, इसलिए version control कठिन हो जाता है, लेकिन expressiveness, shareability और वास्तव में पढ़े जाने की संभावना इसके बड़े फ़ायदे माने जाते हैं

Markdown की जगह HTML को पसंद करने की वजह

  • Markdown agents के लिए इंसानों से संवाद करने का प्रमुख file format बन गया है; यह सरल है, portable है, थोड़ा formatting व्यक्त कर सकता है और इंसान इसे सीधे edit भी आसानी से कर सकते हैं
  • Claude Markdown के भीतर ASCII diagrams भी अच्छी तरह बनाता है, लेकिन जैसे-जैसे agents अधिक शक्तिशाली होते गए, Markdown एक सीमित format जैसा लगने लगा
  • 100 से अधिक lines वाली Markdown files पढ़ना कठिन होता है, और अधिक समृद्ध visualization, रंग और diagrams को आसानी से share करने की इच्छा होती है
  • जब सीधे file edit करने की बजाय Claude से edit करवाने के मामले बढ़ते हैं, तब Markdown का बड़ा फ़ायदा—सीधा manual editing—कम मूल्यवान हो जाता है
  • Claude Code टीम के भीतर भी output format के रूप में HTML का उपयोग बढ़ रहा है, और उदाहरण html-effectiveness में देखे जा सकते हैं

HTML की अभिव्यक्ति क्षमता और shareability

  • HTML सिर्फ headings और formatting जैसी document structure ही नहीं, बल्कि Markdown की तुलना में कहीं अधिक प्रकार की जानकारी व्यक्त कर सकता है
  • व्यक्त की जा सकने वाली जानकारी में tables के ज़रिए tabular data, CSS के ज़रिए design data, SVG illustrations, script tag के ज़रिए code snippets, और JavaScript तथा CSS के साथ interactivity शामिल हैं
  • SVG और HTML से workflows दिखाए जा सकते हैं, absolute positioning और canvas से spatial data व्यक्त किया जा सकता है, और img tag से images जोड़ी जा सकती हैं
  • Claude द्वारा पढ़ी जा सकने वाली अधिकांश जानकारी को HTML में काफ़ी प्रभावी ढंग से व्यक्त किया जा सकता है, इसलिए यह model के लिए गहन जानकारी पहुँचाने और इंसानों के लिए review करने, दोनों के लिए एक प्रभावी format बनता है
  • यदि HTML का उपयोग न किया जाए, तो Claude को Markdown में ASCII diagrams बनाने पड़ सकते हैं या Unicode characters के ज़रिए रंगों का अनुमान लगाना पड़ सकता है, जो कम प्रभावी अभिव्यक्ति है
  • Claude जैसे-जैसे अधिक जटिल काम करने लगा, उसने बड़े specs और plans लिखने शुरू किए, और वास्तव में 100 से अधिक lines वाली Markdown files अच्छी तरह पढ़ी नहीं जातीं
  • HTML documents tabs, illustrations और links के माध्यम से संरचना को दृश्य रूप में व्यवस्थित कर सकते हैं, जिससे navigation आसान हो जाता है, और इन्हें screen size के अनुसार अलग तरह से पढ़े जाने लायक mobile responsive भी बनाया जा सकता है
  • Markdown files को browser डिफ़ॉल्ट रूप से अच्छी तरह render नहीं करते, इसलिए उन्हें अक्सर email या message में attach करना पड़ता है, जबकि HTML को S3 जैसी जगह पर upload कर दिया जाए तो link के रूप में आसानी से share किया जा सकता है
  • HTML में बने specs, reports और PR explanations साथियों के लिए खोलकर देखना और reference करना आसान बनाते हैं, इसलिए उनके वास्तव में पढ़े जाने की संभावना बहुत अधिक बढ़ जाती है
  • HTML documents sliders या knobs जोड़कर design को adjust करने या algorithm options बदलकर परिणाम देखने जैसी bidirectional interactivity को support कर सकते हैं
  • ऐसा फीचर भी बनाया जा सकता है जो किए गए adjustments को Claude Code में दोबारा paste करने लायक prompt के रूप में copy करे; संबंधित उदाहरण playgrounds post में है

Claude Code के साथ HTML का उपयोग क्यों

  • Claude Code file system, MCP, browser, Git history आदि जैसे विविध context को पढ़कर HTML output में पिरो सकता है
  • उदाहरण के लिए, code folder में generated सभी HTML files ढूँढकर, उन्हें group और classify करने के बाद, हर प्रकार का प्रतिनिधित्व करने वाले diagrams के साथ एक HTML file बनाई जा सकती है
  • file system के अलावा Slack, Linear जैसे MCP, Claude in Chrome के माध्यम से web browser, और Git history जैसी जगहों से भी अतिरिक्त context खोजा जा सकता है
  • Claude के साथ HTML documents बनाने की प्रक्रिया अधिक मज़ेदार लगती है, और यह एहसास देती है कि आप output में अधिक शामिल और invested हैं
  • अलग से /html skill बनाने की ज़रूरत नहीं; शुरुआत सिर्फ “HTML file बना दो” या “HTML artifact बना दो” कहकर की जा सकती है
  • महत्वपूर्ण बात यह समझना है कि artifact को क्या करना चाहिए और उसका उपयोग कैसे होगा; शुरुआत में हर बार नया prompt लिखकर अलग-अलग उपयोग सीखना बेहतर है

मुख्य उपयोग के तरीके

  • spec, plan, exploration

    • HTML Claude के लिए समस्या में गहराई से उतरने का एक समृद्ध canvas बन सकता है, और एक single Markdown plan की बजाय कई HTML files के bundle के रूप में काम शुरू किया जा सकता है
    • पहले कई दिशाओं में brainstorming की जा सकती है, फिर एक दिशा को विस्तार देकर mockups या code snippets बनाए जा सकते हैं, और अंत में implementation plan लिखा जा सकता है
    • जब plan संतोषजनक लगे, तो नया session बनाकर इन files को सौंपकर implementation कराया जा सकता है; validation agent भी वही files पढ़कर ज़रूरी context को और व्यापक रूप से समझ सकता है
    • onboarding screen के लिए layout, tone और density में अलग-अलग 6 approaches को एक HTML grid में बनवाकर, हर विकल्प के trade-offs दिखाए जा सकते हैं
    • mockups, data flow और review के लिए code snippets सहित पढ़ने में आसान HTML implementation plan भी बनवाया जा सकता है
    • इसका उपयोग code implementation approaches तलाशने और कई visual designs की तुलना करने में किया जा सकता है

  • code review और code understanding

    • code को Markdown file में पढ़ना कठिन हो सकता है, लेकिन HTML में diff, comments, flowcharts और module structure render किए जा सकते हैं
    • इसका उपयोग agent द्वारा लिखे गए code को समझने, code review लेने, या PR की समीक्षा करने वाले व्यक्ति को changes समझाने के लिए किया जा सकता है
    • कुछ मामलों में यह GitHub के default diff view से बेहतर काम कर सकता है, और हर PR के साथ HTML code explanation file attach करने जैसा workflow भी संभव है
    • PR review के लिए HTML artifact बनवाकर, अपरिचित streaming/backpressure logic पर focus कराया जा सकता है, और वास्तविक diff पर margin comments व severity के हिसाब से रंग जोड़वाए जा सकते हैं
    • इसका उपयोग PR writing, PR review और code topics समझने में किया जा सकता है

  • design और prototype

    • Claude Design HTML पर आधारित है, और HTML की design expressiveness तब भी ऊँची रहती है जब अंतिम surface HTML न हो
    • Claude HTML में design sketch करके बाद में React, Swift या किसी भी इच्छित भाषा में लिख सकता है
    • animation और actions जैसी interactivity को prototype किया जा सकता है, और sliders या knobs के साथ मनचाहे values adjust किए जा सकते हैं
    • क्लिक करने पर play animation चलाकर जल्दी purple हो जाने वाला checkout button बनवाया जा सकता है, जिसमें कई sliders, options और उपयुक्त parameters copy करने का button भी हो
    • इसका उपयोग design system artifact generation, component adjustment, component library visualization और आनंददायक animation prototypes में किया जा सकता है

  • report, research, learning

    • Claude Code कई data sources की जानकारी को synthesize करके पढ़ने में आसान reports में बदलने में मज़बूत है
    • इससे Slack, codebase, Git history, internet आदि में खोज करवाकर, अपने लिए, leadership के लिए या team के लिए पढ़ने में आसान reports generate कराई जा सकती हैं
    • output लंबे HTML documents, interactive explainers, slides या deck के रूप में हो सकता है
    • SVG से diagrams बनवाने पर visualization में मदद मिलती है
    • prompt caching पर लेख तैयार करते समय Git history पढ़वाकर prompt caching changes को समग्र रूप से कवर करने वाली गहन HTML research file बनवाने जैसी विधि का उपयोग किया गया
    • rate limiter के संबंधित code को पढ़वाकर token-bucket flow diagram, annotated key code snippets 3~4, और नीचे gotchas section के साथ एक single HTML explainer page बनवाया जा सकता है
    • इसका उपयोग feature behavior summary, concept explanation, weekly status reports, incident reports, और SVG illustrations·flowcharts·technical diagrams में किया जा सकता है

  • customized editing interface

    • जब सिर्फ text box से मनचाही बात समझाना मुश्किल हो, तब मौजूदा data के अनुसार एक one-off HTML editor बनाया जा सकता है
    • यह किसी product या reusable tool की बजाय, किसी एक विशेष data piece के लिए उद्देश्य-विशेष से बनाया गया single HTML file होता है
    • मुख्य बात यह है कि अंत में “copy as JSON” या “copy as prompt” जैसा export दिया जाए, ताकि UI में की गई manipulations का परिणाम Claude Code में paste किया जा सके
    • 30 Linear tickets को Now / Next / Later / Cut columns में drag किए जा सकने वाले cards में बदलकर, अंतिम क्रम को हर bucket के लिए एक-पंक्ति rationale सहित Markdown के रूप में copy कराया जा सकता है
    • feature flag settings के लिए form-based editor बनाकर, उन्हें domain के अनुसार group कराया जा सकता है, dependencies दिखाए जा सकते हैं, prerequisite flag बंद होने पर किसी flag को enable करने पर warning दी जा सकती है, और सिर्फ बदली हुई keys को diff के रूप में copy कराया जा सकता है
    • system prompt को adjust करते समय बाईं ओर editable prompt और highlighted variable slots रखे जा सकते हैं, और दाईं ओर तीन sample inputs का real-time rendering, character·token counter और copy button दिए जा सकते हैं
    • इसका उपयोग tickets·test cases·feedback reorder करने, structured settings edit करने, prompts·templates·copy adjust करने, dataset curation, documents·transcripts·diff annotation, और color·easing curve·crop region·cron schedule·regex जैसे text में व्यक्त करना कठिन values चुनने में किया जा सकता है

अक्सर पूछे जाने वाले सवाल और सीमाएँ

  • Markdown आम तौर पर कम tokens इस्तेमाल करता है, लेकिन HTML की expressiveness और वास्तव में पढ़े जाने की अधिक संभावना पूरे output को बेहतर बना देती है
  • Opus 4.7 की 1MM context window में token उपयोग की बढ़ी हुई मात्रा context window में बहुत ज़्यादा प्रमुख नहीं लगती
  • लगभग सभी उपयोगों में Markdown का इस्तेमाल बंद कर दिया गया है, लेकिन यह HTML को अधिकतम प्राथमिकता देने वाली usage style के काफ़ी क़रीब है
  • HTML files को local browser में खोला जा सकता है, Claude से भी उन्हें खोलने को कहा जा सकता है, और shareable link चाहिए तो S3 पर upload किया जा सकता है
  • HTML generation में Markdown की तुलना में अधिक समय लगता है, 2~4 गुना तक, लेकिन परिणाम को इतना मूल्यवान माना गया कि यह समय उचित लगता है
  • सबसे बड़े नुकसानों में से एक version control है, क्योंकि HTML diff, Markdown की तुलना में अधिक noisy और review करने में कठिन होता है
  • Claude से अपनी पसंद का HTML बनवाने के लिए frontend design plugin मददगार हो सकता है
  • कंपनी की style के अनुसार ढालने के लिए Claude को codebase दिखाकर एक single design system HTML file बनवाई जा सकती है, जिसे बाद में दूसरी HTML files के reference material के रूप में उपयोग किया जा सकता है
  • HTML का उपयोग करने से यह डर कम हो जाता है कि Claude द्वारा लिखी गई plans को गहराई से नहीं पढ़ा जाएगा और फैसले उसी पर छोड़ने पड़ेंगे; इसके बजाय Claude के साथ काम करने की प्रक्रिया में अधिक flow में बने रहना संभव होता है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News की टिप्पणियाँ

  • चिंता यह है कि HTML की ओर झुकने पर लोग और LLM दस्तावेज़ों को मिलकर लिखने और संशोधित करने की आसानी खो देंगे
    अगर सिर्फ़ साधारण विवरणात्मक लेखन हो तो ठीक है, लेकिन अधिक जटिल स्पेसिफिकेशन में generated output के अंदर सीधे जाकर उसे ठीक करने की क्षमता बहुत महत्वपूर्ण होती है। HTML दस्तावेज़ों में यह Markdown की तुलना में काफ़ी मुश्किल है, और आप LLM से फिर से HTML ठीक करने को कह सकते हैं, लेकिन जब आपके दिमाग़ में पहले से साफ़ हो कि क्या कहना है, तब वह अपने-आप में एक और बाधा बन जाता है। अगर यह पैटर्न आम हो गया, तो इंसान/LLM सह-रचना और कम हो जाएगी, और लेखन शैली, टोन, यहाँ तक कि सामग्री का चुनाव भी LLM को सौंपने की दिशा में जा सकता है। हैरानी हुई कि ब्लॉग FAQ में इस चिंता का ज़िक्र नहीं था

    • Markdown इंटरैक्टिव तत्वों के लिए inline HTML को सपोर्ट करता है, इसलिए किसी ज्ञात HTML template और सरल build process के साथ Markdown दस्तावेज़ एक दिलचस्प विकल्प हो सकते हैं
      जैसे एक single-line pandoc command
    • मुझे लगता है इससे भी एक कदम आगे की बात है। HTML से ज़्यादातर काम हो जाता है, लेकिन LLM को अपनी खुद की भाषा परिभाषित करने देना भी अजीब तरह से प्रभावी रहा है
      अभी मैं isometric view और sound वाले एक छोटे mobile game पर काम कर रहा हूँ। मैंने Codex से कहा कि तैयार three.js docs में blocks रखने और Chromium developer tools से screenshots लेने वाला tool बनाए, तो उसने blocks, colors और effects को define करने वाला एक छोटा JSON structure बनाया और 2.5D tileset output किया। फिर मैंने उससे uv Python script के ज़रिए sound और music define करने को कहा, तो उसने noise generate कर सकने वाला YAML format बना दिया। SVG pelican test तो यह बहुत पीछे छोड़ चुका है, और Codex ने soldier, knight और priest के लिए काफ़ी prototype art और prototype soundtrack तक बना दी
    • हम दशकों से HTML हाथ से आसानी से लिखते आए हैं। text editors HTML लिखने के लिए बहुत अच्छे हैं, और auto-wrap, auto-close जैसे commands की वजह से पढ़ना और लिखना सरल है
    • यह बात शायद तभी सही लगती है जब आप खुद को किसी आदिम teletype emulator तक सीमित रखें। एक ठीक-ठाक coding environment में HTML editing बहुत आसान होनी चाहिए, और अगर प्रवाह rich model outputs की ओर जा रहा है, तो built-in WYSIWYG editor भी एक विकल्प हो सकता है
    • मैंने हाल ही में reports के लिए HTML का इस्तेमाल शुरू किया है, लेकिन हमेशा Markdown file को intermediate format के रूप में रखता हूँ और LLM से कहता हूँ कि Markdown की tables के आधार पर SVG graphs और images वाला एक ज़्यादा polished version बनाए

  • विडंबना यह है कि यह कोई interactive HTML page नहीं, बल्कि HTML render की हुई image वाला Twitter post है
    Markdown से भी कम semantic structure वाले platform पर HTML की वकालत करना आख़िरकार काफ़ी मज़ेदार है

    • https://thariqs.github.io/html-effectiveness/
      लगता है दोनों ही हैं
    • Twitter Articles के “templates” की बात तो शुरू ही न करें। वह Markdown तक को support नहीं करता

  • नए ideas या tools को explore करते समय मैं अक्सर यह prompt इस्तेमाल करता हूँ

    In a single index.html, no dependencies, sparse styling, create an app that

    AI से पहले भी मैं छोटे tools ऐसे ही बनाता था, और अच्छा लगता है कि आप किसी दोस्त को email से tool भेजकर कह सकते हैं, “अगर बदलना हो तो इसे LLM में डालकर देखो”

    • यही सही तरीका है
      dashboards, छोटे apps, API के साथ interact करने वाली या कहीं से data लाने वाली utilities के लिए, styling और JS सहित single HTML file में कितना कुछ समा सकता है, यह हैरान करने वाला है। इसे company shared server के personal ~ folder में डाल दो, और हर कोई तुरंत देख और इस्तेमाल कर सकता है
    • मैं नए client के design पर iterate करते समय भी एक साधारण index.html में inline CSS डालकर बनाता हूँ, और जब result पसंद आ जाए तो उस file को project template files के पास रखकर LLM से कहता हूँ कि index.html के design को template files में समाहित कर दे
    • मैंने पहले इस use case के बारे में ठीक से सोचा ही नहीं था, इसलिए थोड़ा मूर्ख जैसा महसूस हुआ। यह उपयोगी होगा, यह तो बहुत स्पष्ट है
      अभी तक LLM का इस्तेमाल करते समय मेरा फ़ोकस “app” पर था, उसके आसपास के सहायक tools पर नहीं। ऐसे helper tools को polished होने या हर edge case संभालने की ज़रूरत नहीं होती; बस इतना काफ़ी है कि वे उपयोगी बन जाएँ। काम हो जाए तो फेंको और कल नया बना लो
    • मैंने पहले यह trick समझकर analog electronic circuits के लिए ढेर सारे calculators बनाए थे: https://cofree.coffee/~solomon/calculators/
      इस तरह के tools को जल्दी जोड़कर static site पर डाल पाना बहुत सुविधाजनक है
    • Claude web में भी जब HTML माँगते हैं, तो यह यही करता है। वह इसे artifact के रूप में बनाता है, इसलिए संभव है कि model इस pattern पर अच्छी तरह trained हो

  • web technologies ने सचमुच बहुत कुछ सही किया है। लोग बहुत शिकायत करते हैं, लेकिन यह प्रभावशाली है
    पिछली नौकरी में मैं vibe-coded apps से जूझता था और आख़िरकार उसी वजह से नौकरी छोड़ दी। वहाँ Next.js single-page frontend और अलग API backend वाला ढाँचा था, इसलिए user-facing URLs backend endpoints से मेल नहीं खाते थे। AI हर चीज़ में React hooks इस्तेमाल कर रहा था, इसलिए state memory में रहती थी, और URL-based routing तब तक नहीं होती जब तक उसे जानबूझकर design न किया जाए। नतीजतन links अपने-आप नहीं मिलते, और users के पास top-level entry point के अलावा किसी और चीज़ को link करने का तरीका नहीं था। Links। खासकर internal tools में हर चीज़ linkable होनी चाहिए ताकि collaboration और troubleshooting आसान हो। unified resource locations और verbs की ज़रूरत वाला design 30–40 साल पहले भी वाकई बहुत अच्छी तरह सोचा गया था

    • क्या मतलब यह है कि दूसरे page या tab पर जाने पर भी URL update नहीं होता था?

  • HTML और Markdown के बीच कुछ trade-offs यहाँ छूट गए हैं। HTML token efficiency में काफ़ी कमज़ोर है, और HTML plan पर सटीक feedback देना Markdown की तुलना में कठिन है
    ये दोनों trade-offs Anthropic के पक्ष में जाते हैं। अगर medium के रूप में HTML इस्तेमाल हो, तो token usage बढ़ता है, और संभव है कि वे Claude Design के हिस्से के रूप में HTML पर annotate या mark up करने वाले tools में निवेश कर रहे हों, जिससे lock-in भी मज़बूत हो सकता है। यह या तो संयोग है, या शानदार रणनीति

    • यह थोड़ा कम efficient ज़रूर है, लेकिन अगर structure या visual elements बहुत ज़्यादा न हों, तो फ़र्क बहुत बड़ा नहीं होता
      और मुझे ठीक से समझ नहीं आता कि सटीक feedback देना Markdown से ज़्यादा मुश्किल क्यों होगा। tags के साथ id, sections वगैरह रखे जा सकते हैं
    • HTML में code execution vulnerabilities की गुंजाइश भी अधिक है। plain text नुकसान नहीं पहुँचाता

  • दशकों तक HTML के साथ काम करने के बावजूद, साधारण दस्तावेज़ों के लिए Markdown अब भी तेज़ है। कोई मध्य मार्ग अच्छा होगा, और वास्तव में GitHub Markdown जैसी अधिक सक्षम चीज़ें पहले से मौजूद हैं
    आप Mermaid embed कर सकते हैं, और ज़रूरत पड़ने पर components मिलाने के लिए MDX जैसी चीज़ें भी इस्तेमाल कर सकते हैं। मेरी जानकारी में readme.com भी अंदरूनी तौर पर MDX इस्तेमाल करता है। अगर cards या layouts चाहिए हों, तो Bootstrap जैसी चीज़ों पर आधारित components जोड़े जा सकते हैं। अब जो कमी बचती है, वह interface support की है। pure HTML तो render हो ही सकता है, इसलिए ज़्यादा शक्तिशाली Markdown जोड़ना भी शायद बहुत कठिन नहीं होगा

    • MDX मुझे बिल्कुल सही middle ground लगता है। इस comment की वजह से मैं साधारण Markdown की जगह MDX इस्तेमाल करना शुरू करने वाला हूँ

  • मूल Markdown spec [1] और CommonMark [2] दोनों inline HTML support को स्पष्ट रूप से परिभाषित करते हैं। इसलिए use case के हिसाब से दोनों तरफ़ के फ़ायदों का कुछ हिस्सा लिया जा सकता है
    ज़्यादातर हिस्सों में आप सामान्य Markdown headers और paragraphs लिखते हैं, और images व tables जोड़ते हैं, तो HTML tags के बिना भी मूल रूप में पढ़ना आसान रहता है। अगर लेखक के उदाहरण जैसे SVG जैसी चीज़ें डालनी हों, तो SVG को सीधे embed किया जा सकता है, और देखने वाला अपनी पसंद के viewer में Markdown render कर सकता है। VS Code में raw Markdown file देखते हुए अगर HTML tag मिले, तो बस Cmd+Shift+V से preview खोल लो। बेशक, interactive buttons और पूरी तरह custom styling वाला असली web page बनाना मुश्किल है, लेकिन अगर मुख्य रूप से text, images और tables हों और इधर-उधर कुछ अतिरिक्त तत्व जोड़ने हों, तो यह काफ़ी आगे तक जा सकता है
    [1] https://daringfireball.net/projects/markdown/syntax#html
    [2] https://spec.commonmark.org/0.31.2/#html-blocks

    • मेरा मानना है कि Markdown document को preview की ज़रूरत नहीं होनी चाहिए। अगर ज़रूरत है, तो फिर सीधे HTML document ही बना लेना चाहिए

  • जनवरी से मैं non-coding उपयोगों के लिए इस तरीके को ज़ोर-शोर से बढ़ावा दे रहा हूँ। इसकी मुख्य विशेषता यह है कि यह editable, LLM और इंसान दोनों के लिए समझने योग्य, renderable, और क्रमिक रूप से संशोधित किया जा सकने वाला single source of truth है
    मैं आम लोगों से AI workflows पर अक्सर बात करता हूँ, और कभी सड़क पर AI की बातचीत सुन लूँ तो anthropologist की तरह बीच में कूद पड़ता हूँ। HTML artifacts नए browser URL bar जैसे हैं। जैसे कुछ users समझते हैं कि वही URL bar असल में Google है। आजकल बहुत से लोग “spreadsheet”, “presentation”, “marketing one-pager”, “slide show”, “competitive analysis”, “HVAC system diagram” जैसी चीज़ों के बारे में बताते हैं और कहते हैं कि ChatGPT या Claude web में यह काम करना ख़ास नहीं था, लेकिन Claude Code या OpenClaw से नया document बनाना किसी चमत्कार जैसा लगा।
    जब मैं पूछता हूँ कि असली document क्या था और अनुभव का फ़र्क कहाँ था, तो computing vocabulary की कमी के कारण काफ़ी पूछताछ करनी पड़ती है या सीधे दिखाने को कहना पड़ता है, लेकिन नतीजा हमेशा यही निकलता है कि artifact HTML था। अच्छा अनुभव filesystem में मौजूद HTML file (+CSS+images) पर high-quality instant rendering के साथ iterate करने से आता है, और ज़रूरत पड़ने पर थोड़ा JavaScript भी छिड़का जा सकता है। अगर git system हो, तो अनजाने में version control भी हो सकता है। अगर न हो, तो मैं checkpoints बनाने की सलाह देता हूँ। आम लोगों के लिए version control शायद अगला सीखने वाला कदम है
    इसके उलट, web में फँसा अनुभव कई बार context window के अंदर रह जाने वाले DOCX/PPTX/XLSX को बार-बार कुरेदने और local storage की धुंधली-सी अवधारणा से जूझने जैसा है। दिलचस्प बात यह है कि sidebar में render तो HTML के रूप में ही होता है। HTML workflow दूसरे media को भी कहीं ज़्यादा आसानी से integrate करने देता है। आख़िरकार ऐसी presentation-type चीज़ें आम जनता की vibe coding ही हैं, और नीचे रखे सारे turtles को जानना ज़रूरी नहीं। फिर भी चाहें तो खोलकर ठीक कर सकते हैं, या आसानी से किसी दूसरे agent को सौंप सकते हैं। collaborative multimedia communication के लिए बनाया गया system अब machine intelligence को हमारी communication में मदद करने के लिए उपयोगी साबित हो रहा है

  • पहले हम (https://www.definite.app/) अपने agent से reports और dashboards को frontend framework द्वारा render की जाने वाली YAML spec के रूप में लिखवाते थे
    उदाहरण के लिए, अगर user कहता, “मासिक revenue और order count दिखाने वाली report बनाओ और हाल के 100 orders दिखाओ,” तो agent frontend में render होने वाली spec लिखता था। यह तरीका तेज़ था, लेकिन हम framework जिन features को render कर सकता था, उनसे जुड़ी requests में दब गए। जैसे “यहाँ label हटाना है”, “वहाँ label चाहिए”, “क्या इस chart को heatmap बनाया जा सकता है” जैसी बातें। कुछ महीने पहले हमने agent से बस HTML लिखवाना शुरू किया, और generation में ज़्यादा समय लगता है, लेकिन customization पर अब कोई सीमा नहीं रही। नए तरीके में भी समस्याएँ हैं, जैसे non-technical users को अपने बनाए हुए monster-like apps को debug करना पड़ना, लेकिन कुल मिलाकर customers इसे कहीं ज़्यादा पसंद करते हैं

    • इस मामले में prompt injection को कैसे रोकते हैं?

  • लंबे agent outputs को पढ़ने के लिए मैं VIM और macOS Quick Look (Markdown rendering extension सहित) का उपयोग करता हूँ, या preview panel वाले MarkEdit में paste कर देता हूँ
    सबसे बुरी स्थिति में agent से Markdown को interpret और render करने वाला एक साधारण local web page बनवा लो। Markdown का आविष्कार web syntax के shorthand रूप के रूप में हुआ था [0], और यह ठीक उसी काम के लिए है। agent से basic Markdown को HTML में बदलवाने में जो tokens और समय लगेगा, वह शायद इन तरीकों से ज़्यादा होगा
    0. https://daringfireball.net/projects/markdown/

    • ज़्यादा tokens खर्च होंगे, यह शायद सही है, लेकिन लेखक Anthropic में काम करता है, इसलिए संभव है कि उसने token cost कभी सीधे चुकाई ही न हो
    • अगर आप vibe को अंत तक ले जाना चाहते हैं, तो लंबे outputs का summary भी bot से ही क्यों न बनवा लें?
      bots का इस्तेमाल सचमुच बहुत अव्यवस्थित और self-referential होता जा रहा है
    • कौन-सा Quick Look extension? मैं एक अच्छा विकल्प ढूँढ रहा था