Stop Letting Your Agents Write Markdown. - CourtneyR.dev's 2nd Brain

Stop Letting Your Agents Write Markdown. ![rw-book-cover](https://img.youtube.com/vi/S9EGx6ik-18/maxresdefault.jpg) 🔗 **Source:** [Stop Letting Your Agents Write Markdown.](https://www.youtube.com/watch?v=S9EGx6ik-18) > [!note]+ Document Notes > tags: #html #markdown #agents #ai-tools #user-interface #web-development #claude #output-formats > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=S9EGx6ik-18 > date created: 2024-12-19 08:30 > > # 🏷️ Title: Stop letting your agents write Markdown. >  ## 🧰 Action Inbox - [H1] Test HTML output with Claude for complex specs and planning documents — 00:00 #html #agents - [H2] Build custom editing interfaces for one-off data manipulation tasks — 37:45 #html #prototyping - [H3] Create weekly HTML reports from Jira/Slack for leadership visibility — 29:30 #automation #career ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [The Unreasonable Effectiveness of HTML](https://github.com/thoricsson/html-effectiveness) - [Copilot Kit](https://copilotkit.ai) ## 📝 Summary - Developers are increasingly switching from Markdown to HTML as output format for AI agents - HTML provides richer visualizations, better interactivity, and higher information density than Markdown - The shift improves engagement with AI-generated content and enables novel use cases like custom interfaces - Industry leaders like Andrej Karpathy predict progression toward more visual, interactive AI outputs - HTML's expressiveness makes specs, reports, and documentation more likely to be read and acted upon ## 📖 Main Content This video examines a growing trend where developers are abandoning Markdown in favor of HTML for AI agent outputs. Thor from the Claude Code team published influential articles arguing that HTML's superior expressiveness, visual clarity, and interactive capabilities make it more effective for agent communication. The core argument centers on HTML's ability to convey richer information through tables, CSS styling, SVG illustrations, JavaScript interactions, and embedded media - capabilities that Markdown fundamentally lacks. For complex specs and planning documents, HTML enables better organization with tabs, collapsible sections, and visual hierarchies that improve readability. Karpathy's perspective adds weight to this movement, suggesting we're progressing toward increasingly visual AI outputs that leverage human visual processing capabilities. He envisions a future of interactive neural videos and simulations, with HTML representing an intermediate step in this evolution. Practical applications include automated reporting systems that synthesize data from multiple sources (Slack, Jira, Git) into executive-friendly HTML dashboards, custom editing interfaces for one-off data manipulation tasks, and enhanced code review documents with inline annotations and hierarchical organization. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/S9EGx6ik-18?t=0) — [H1] Introduction to the HTML vs Markdown debate - Key idea: Growing industry shift from Markdown to HTML for AI agent outputs - Evidence: Thor from Claude Code team published "The Unreasonable Effectiveness of HTML" #### ⏱️ [02:15](https://youtu.be/S9EGx6ik-18?t=135) — [H2] Copilot Kit sponsorship demonstration - Key idea: Building AI apps requires specialized tools for streaming, dynamic UI, and thread persistence - Evidence: "Building AI apps with AI is surprisingly hard... all the weird things like persisting threads, streaming chats" #### ⏱️ [05:30](https://youtu.be/S9EGx6ik-18?t=330) — [H1] Thor's article: Information density advantages - Key idea: HTML carries vastly more information types than Markdown - Evidence: "Tables, design, illustrations, code, images, spatial workflows, and interactions" #### ⏱️ [08:45](https://youtu.be/S9EGx6ik-18?t=525) — [H3] Visual clarity and readability improvements - Key idea: HTML documents are easier to read than long Markdown files - Evidence: "I tend to not actually read more than a 100-line markdown file" #### ⏱️ [12:20](https://youtu.be/S9EGx6ik-18?t=740) — [H2] Ease of sharing HTML files - Key idea: HTML files can be shared as simple links vs Markdown attachments - Evidence: "Upload the file to S3, you can share the link easily" #### ⏱️ [15:10](https://youtu.be/S9EGx6ik-18?t=910) — [H1] Interactive capabilities of HTML - Key idea: HTML enables two-way interactions with sliders, knobs, and form elements - Evidence: "Allow you to copy these changes into a prompt to paste back into cloud code" #### ⏱️ [18:30](https://youtu.be/S9EGx6ik-18?t=1110) — [H2] Code review and understanding use cases - Key idea: HTML can render diffs, annotations, and flowcharts better than Markdown - Evidence: "I attach an HTML code explainer to every PR I make now" #### ⏱️ [22:45](https://youtu.be/S9EGx6ik-18?t=1365) — [H3] Design and prototype applications - Key idea: HTML serves as expressive design medium for mockups and interactions - Evidence: "Claude design is based on HTML because HTML is incredibly expressive at design" #### ⏱️ [26:15](https://youtu.be/S9EGx6ik-18?t=1575) — [H1] Reports, research, and learning applications - Key idea: HTML synthesis of multiple data sources creates readable reports for leadership - Evidence: "Give an agent access to your Jira and ask it to make a nice looking HTML page" #### ⏱️ [29:30](https://youtu.be/S9EGx6ik-18?t=1770) — [H2] Career growth hack with automated reporting - Key idea: HTML reports from company data make developers look good to management - Evidence: "Management will go crazy over this... simple way to like look cool to your team" #### ⏱️ [32:20](https://youtu.be/S9EGx6ik-18?t=1940) — [H3] Prompting from different perspectives - Key idea: Pretending to be less knowledgeable steers agents toward better explanations - Evidence: "Almost half of my prompts are me pretending to be dumber than I am" #### ⏱️ [35:40](https://youtu.be/S9EGx6ik-18?t=2140) — [H1] Custom editing interfaces for one-off tasks - Key idea: Building throwaway HTML tools for specific data manipulation tasks - Evidence: "Single HTML file purpose-built for this one piece of data" #### ⏱️ [37:45](https://youtu.be/S9EGx6ik-18?t=2265) — [H2] Philosophy of disposable code - Key idea: Writing code for single use is valuable when code generation is cheap - Evidence: "About 70 plus percent of code gets thrown out after I run it one time" #### ⏱️ [42:10](https://youtu.be/S9EGx6ik-18?t=2530) — [H1] Karpathy's vision for visual AI outputs - Key idea: Human brains prefer visual input, progression toward interactive neural videos - Evidence: "Around a third of our brains are massively parallel processors dedicated to vision" #### ⏱️ [45:30](https://youtu.be/S9EGx6ik-18?t=2730) — [H3] Future of human-AI interfaces - Key idea: Need for pointing, gesturing, and spatial interaction beyond text/voice - Evidence: "Need to point and gesture to things on the screen... physically next to you" ## 📚 References - [Thor's HTML Effectiveness GitHub](https://github.com/thoricsson/html-effectiveness) - [Copilot Kit](https://copilotkit.ai) - [Devon Review](https://devonreview.com) - [T3 Code](https://github.com/t3-oss/create-t3-app) ## 🗣️ Paraphrase - HTML enables AI agents to create richer, more interactive outputs than Markdown's limited formatting capabilities - The visual nature of HTML documents increases engagement and readability compared to lengthy text-based specifications - Practical applications include automated reporting, custom data interfaces, and enhanced code documentation that leverages HTML's expressiveness ## 📰 Newsletter **HTML Takes Center Stage in AI Agent Workflows** Developers are discovering that HTML outputs from AI agents create more engaging, actionable results than traditional Markdown. This shift enables richer visualizations, interactive elements, and better organization of complex information. Key benefits include automated reporting dashboards that synthesize multiple data sources, custom editing interfaces for one-off tasks, and enhanced documentation that teams actually read. The visual nature of HTML leverages human cognitive strengths while enabling novel interaction patterns. Try asking your AI tools to generate HTML artifacts for your next planning document or data analysis task. The improved engagement might surprise you. Resources: [Claude Code](https://claude.ai), [HTML Examples](https://github.com/thoricsson/html-effectiveness), [Web Development Docs](https://developer.mozilla.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create HTML-based demos showcasing agent capabilities and interactive documentation - Education: Develop workshops on prompt engineering for visual outputs and HTML generation best practices - Developer experience: Build tools that convert Markdown docs to interactive HTML experiences - Developer marketing: Campaign highlighting visual AI outputs and developer productivity gains - Community management: Moderate discussions on output format preferences, gather feedback on HTML vs Markdown #### OSPO - Policy & Governance: Guidelines for HTML output security, sanitization requirements for agent-generated content - License Compliance: Review implications of HTML generation tools and embedded JavaScript libraries - Security Management: Assess XSS risks in agent-generated HTML, establish sanitization protocols - Software Inventory: Track HTML generation dependencies, document third-party visualization libraries - Developer Support: Training on secure HTML generation, tooling for content validation - Community Engagement: Engage with HTML/CSS standards bodies on agent-generated content - Strategic Alignment: KPIs around developer engagement with visual vs text outputs #### Community - Maintainers: HTML templates for project documentation, interactive roadmaps and issue visualization - Contributors: Onboarding guides using interactive HTML, visual contribution flow diagrams - Sponsors: Impact reports with interactive charts, funding transparency dashboards - Ecosystem: Cross-project visualization tools, dependency mapping in HTML format #### WordPress - Core: Interactive performance budget dashboards, visual component documentation - Core Performance: HTML profiling reports, interactive metrics visualization - Core AI: Visual model evaluation interfaces, interactive prompt testing tools - Documentation: Convert static docs to interactive HTML guides, visual API explorers - Design: HTML-based design system demos, interactive component galleries - Marketing: Visual campaign dashboards, interactive WordPress statistics - Training: Interactive learning modules, visual progress tracking for courses ## 🧪 Hypotheses - HTML outputs from AI agents increase user engagement by 40-60% compared to equivalent Markdown content - Visual documentation reduces onboarding time for new developers by leveraging spatial memory and visual processing - Interactive HTML interfaces for data manipulation reduce errors compared to manual CSV/JSON editing - Teams using HTML reports show improved decision-making speed due to better information visualization ### 📊 Methodology - A/B test engagement metrics between Markdown and HTML documentation formats - Time-to-comprehension studies comparing visual vs text-based technical specifications - Error rate analysis for data manipulation tasks using custom HTML interfaces vs traditional methods - Decision latency measurement in teams using visual dashboards vs text reports ### ❓ Questions - How do we balance HTML's expressiveness against version control complexity and diff readability? - What security protocols are needed for safely rendering agent-generated HTML in enterprise environments? - How might HTML generation capabilities change developer workflow patterns and collaboration methods? ### 🔮 Future Research - Investigation into optimal HTML structure patterns for different types of technical documentation - Development of hybrid formats combining Markdown's simplicity with HTML's visual capabilities - Research into accessibility implications of agent-generated visual content and screen reader compatibility ### 💡 Implications - Practice: Shift toward visual-first documentation and reporting workflows in development teams - Policy: Need for HTML sanitization and security guidelines in enterprise AI tool adoption - Security: XSS prevention and content validation requirements for agent-generated HTML - Education: Training programs on visual prompt engineering and HTML generation best practices - Funding: Investment in tools that bridge Markdown simplicity with HTML expressiveness ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical content with domain-specific terminology) #### 👀 Visual learners - Present: Code examples, screenshot comparisons, HTML rendering demonstrations - Improve: Side-by-side visual comparisons of Markdown vs HTML outputs, workflow diagrams #### 🔊 Aural learners - Present: Video format with verbal explanations and commentary - Improve: Audio-only version with descriptions of visual elements, podcast-style summary #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, analogies comparing formats - Improve: Glossary of HTML/agent terminology, story-driven examples of format evolution #### 🧩 Kinesthetic learners - Present: Step-by-step prompting examples, hands-on demonstrations - Improve: Interactive playground for testing HTML vs Markdown outputs, practice exercises #### 🧠 Logical learners - Present: Structured comparison tables, decision trees for format selection - Improve: Flowcharts for choosing output formats, quantified benefits analysis #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion references, team collaboration examples - Improve: Discussion prompts for team format adoption, collaborative decision frameworks #### 🧘‍♀️ Solitary learners - Present: Individual experimentation suggestions, self-assessment opportunities - Improve: Personal workflow evaluation checklists, reflective prompts on format preferences #### 🌿 Naturalistic learners - Present: Evolution metaphors for format development, ecosystem thinking - Improve: Analogies to natural information processing, environmental impact considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video transcript available, structured headings - Improve: Alt text for code examples, ARIA labels for interactive elements discussion #### Keyboard navigation - Present: Standard video player controls, logical content flow - Improve: Keyboard shortcuts for video sections, skip links for content sections #### Contrast and readability - Present: Clear visual distinction between code and commentary - Improve: High contrast mode options, adjustable text sizing #### Text resizing and reflow - Present: Responsive video player, scalable text content - Improve: Reflow support at 200% zoom, text-only version availability #### Media and captions - Present: Full transcript provided, clear audio quality - Improve: Synchronized captions, audio descriptions for visual demos #### Forms and interactions - Present: Standard video interaction patterns - Improve: Accessible video controls, keyboard navigation support ### 🌍 DEIB Assessment #### Cultural breadth - Present: Generic technical examples applicable across contexts - Improve: Examples from diverse technical environments, international use cases #### Inclusive language - Present: Gender-neutral technical terminology, defined jargon - Improve: Plain language summaries, cultural context for workflow examples #### Neurodiversity support - Present: Clear structure, consistent formatting - Improve: Content warnings for rapid visual changes, alternative consumption formats #### Representation - Present: Focus on technical content over personal characteristics - Improve: Diverse example scenarios, inclusive team collaboration examples #### Psychological safety - Present: Respectful tone toward different preferences - Improve: Acknowledgment of valid concerns about format changes, non-judgmental language ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from HTML capabilities to practical benefits - Inductive strength: Good use of specific examples to support general claims about format effectiveness - Causal reasoning: Clear connections between visual processing and improved engagement - Analogical strength: Effective comparison between human visual processing and AI output optimization #### Fallacies - Appeal to authority: Over --- ## Full Transcript [00:00] I recently published a video about all [00:01] the flaws in Markdown. And you all [00:03] really loved that one. Uh, kind of. You [00:06] definitely weren't super rude to me in [00:07] the comments about how I'm click baiting [00:08] and terrible and then watch the video [00:10] and realize I actually had things to say [00:12] about Markdown. But yeah, it seems like [00:14] Markdown's a sensitive topic for a lot [00:16] of people because it does have a lot of [00:17] strengths. I mean, I've been a Markdown [00:19] fan for the better part of two decades [00:20] now. I understand. But I feel like we're [00:23] overusing it. And it seems like I'm no [00:24] longer the only one who feels this way. [00:26] Thoric from the cloud code team just [00:28] published an article using claude code [00:30] the unreasonable effectiveness of HTML. [00:33] He then followed up with HTML is the new [00:36] markdown. I've stopped writing markdown [00:38] files for almost everything and switched [00:39] to using cloud code to generate HTML for [00:41] me instead. This article is why I have [00:44] seen some fun hacks around using HTML [00:47] with tools like claude code. I actually [00:49] learned a bunch of these from Simon [00:50] Willis way back when we were doing GBT [00:52] testing together. I have been amazed at [00:54] some of the clever things people figure [00:56] out with HTML and how they use it to be [00:58] more effective working with agents. And [01:00] Thor and I aren't the only ones who feel [01:01] this way. Carpathy actually came out and [01:03] said that this works really well, just [01:05] asking it to structure responses as [01:06] HTML. He had a lot to say as well. We're [01:09] going to go into all of this and more. [01:11] Agents clearly like Markdown and HTML, [01:13] but there's one more important thing [01:14] that agents love. Today's sponsor. [01:16] Building most things with AI is pretty [01:18] easy, but there's one that's [01:19] surprisingly hard. Building AI apps with [01:21] AI. It turns out all the weird things [01:23] like persisting threads, streaming [01:25] chats, getting UI to render dynamically [01:27] on the fly and more just kind of is hard [01:29] to do. Believe me, I've tried a lot. E3 [01:32] chat and T3 code show just how hard it [01:34] is to get this right. And if Copilot was [01:36] there when we started, it would have [01:37] made my life much easier. They call [01:39] themselves the enterprise ready [01:40] front-end stack for agents, but I would [01:41] go further than that because it's not [01:43] just front end. It's a real full stack [01:45] solution. Here's a simple app we built [01:46] with Copilot Kit. We're going to ask it [01:48] to compare the latest models from OpenAI [01:50] and Anthropic. You probably expected to [01:51] just render a really bad markdown table, [01:53] right? Nope. You can write custom [01:56] components in whatever framework or tool [01:58] system you want. Obviously, we're big [02:00] React guys here and their React stuff is [02:01] great. So here it just rendered a custom [02:03] component listing all of the different [02:05] models and their prices. But more [02:06] importantly, it rendered a comparison [02:08] option here where I as the user can [02:11] interact, make changes, hit submit, and [02:14] now it's going to do another pass where [02:15] the model gets all of the information [02:17] back and renders another dynamic UI all [02:20] based on components that we wrote. The [02:21] code couldn't be simpler. They provide a [02:23] use component hook that you give a name, [02:24] description, and parameters, which are [02:26] just the things it needs to pass. You [02:28] know, classical Zod schema here. you've [02:30] been around for a while, you're already [02:31] familiar with all this. And then you [02:32] give it the custom component that [02:33] actually renders the results. They also [02:35] have a hook for interactive components [02:37] right here, which is just as easy to [02:38] use. Getting the front end and the back [02:40] end to interact properly in systems like [02:42] this is incredibly complex. Copilot kit [02:44] couldn't make it easier, even if you [02:46] don't want to use their components. I [02:47] know Ben's already building his own [02:48] wrappers around it in spelt. Build [02:50] better interactive experiences with [02:51] agents at soyb.v.link/copilotkit. [02:54] Let's see what Thor has to say about the [02:56] unreasonable effectiveness of HTML for [02:58] agents. Markdowns become the dominant [03:01] file format used by agents to [03:02] communicate with us. It's simple, [03:04] portable, has some rich text capability, [03:06] and it's easy for you to edit. Glad has [03:08] even got surprisingly good at using AI [03:10] to make diagrams inside of markdown [03:12] files. I would disagree. I can't tell [03:14] you how many times I see it miss pad and [03:16] have like certain layers just like push [03:18] out too far on the borders. It is what [03:20] it is. As agents have gotten more and [03:22] more powerful, I have felt that markdown [03:24] has become a restricting format. I've [03:26] had a difficult to read a markdown file [03:27] of more than 100 lines. I want richer [03:29] visualizations, color, and diagrams, and [03:31] I want to be able to share them easily. [03:33] I'm also increasingly not editing these [03:35] files myself, but using them as specs, [03:38] reference files, brainstorming outputs, [03:39] etc. When I do make edits, I'm usually [03:42] prompting Claude to edit them, which [03:43] removes one of Markdown's largest [03:45] benefits. I've started preferring HTML [03:47] as an output format instead of Markdown, [03:49] and increasingly see this being used by [03:51] others on the Claude Code team. This is [03:53] why you want to start with some [03:55] examples. You can see a bunch here. This [03:57] HTML effectiveness GitHub page. Just be [03:59] sure to come back and read more after. [04:01] We will do just that. Oh, yep. I can [04:04] already smell the Claude code design [04:06] skill all over this one. Something I've [04:08] been meaning to do for a bit. I am [04:10] finally tired of the front-end design [04:12] skill. And as such, [04:16] away it goes. [04:18] I have now removed the front-end design [04:20] skill because I am so tired of this [04:23] stale copy paste design format that [04:25] everything ends up with. Cool. The [04:28] unreasonable effectiveness of HTML. 20 [04:31] self-contained HTML files and agent [04:33] produced instead of a wall of markdown. [04:35] Each one trades a document you'd skim [04:36] for one that you'd actually read. Open [04:38] any of them directly in a browser. Group [04:40] by the kind of work that they replace. I [04:42] can tell from this copy that this was [04:43] written by an agent. I recently got [04:46] gifted a sub to Panggram Labs from [04:48] Slasher and it apparently is really good [04:51] at detecting AI generated text. From my [04:54] brief experimentation, it was. So, we're [04:57] going to start with this article and [04:59] take a look to see if we are reading AI [05:01] slop or not. Okay, the site's super [05:03] broken, but apparently 100% of the text [05:05] is human written. Good start. But if we [05:08] switch over to this site, [05:13] I'll just grab different sections of the [05:15] text. Yep, just as expected, the HTML is [05:20] entirely AI generated. People are [05:23] already asking, so I'll make it clear. [05:24] This wasn't an ad. I just have a friend [05:26] that works at the company now and was [05:28] skeptical of how good Pangram was at AI [05:30] text detection. And thus far, it's had a [05:32] pretty close to 100% hit rate for my [05:34] test experience. I don't know if the [05:36] product's any good. I don't know [05:37] anything about it beyond it being sent [05:39] to me by a friend. And yeah, it seems [05:42] cool and it's fun to quickly check if [05:43] something's AI generated or not cuz I [05:45] can usually tell. But now I have [05:46] confirmation some amount. It's all [05:48] lossy. It is what it is. Just wanted to [05:50] see. So we're not reading AI slop when [05:51] we read his article, but we're [05:53] absolutely reading AI slop when we read [05:54] these HTML files. Let's go back to [05:56] reading these HTML files. He shows some [05:59] examples with exploration in planning. [06:01] When you're not sure what you want yet, [06:02] ask the agent to fan out across several [06:04] directions and lay them next to each [06:05] other so you can point at one instead of [06:07] reading three sequential walls of text [06:09] and trying to hold them all in your [06:10] head. Once you've picked, turn the pick [06:12] into a plan that the implementer can [06:13] actually read. So here it made HTML for [06:16] three ways to implement debounced [06:18] search. It generated an inline use [06:20] effective set timeout, a custom use [06:22] debounce hook with pros and cons under [06:25] each as well as a tiny external library [06:27] that it could use. It had a [06:29] recommendation at the bottom. I'm okay [06:31] with this just being in the chat, but I [06:33] can see why in certain cases this would [06:34] be worth breaking out into an HTML file. [06:37] Visual design directions [06:41] for the no tasks yet state. So, this is [06:44] it mocking four potential directions for [06:47] the UI. This I could see being useful. [06:49] I've already done a trick similar to [06:50] this before, and I've shared this in [06:51] many videos where when I want different [06:53] design renditions for something, I don't [06:56] ask the model to do one and then ask [06:57] again for it to do another. I ask you [06:59] for four distinct options that it will [07:01] put on different routes so I can take a [07:03] look at all of them just because I want [07:05] to see them all. And if you ask it to [07:07] generate them all at once, you'll get [07:08] more variety than asking one after [07:10] another because it's going to just go [07:12] down a similar path otherwise. Another [07:14] fun example that he has here is [07:16] implementation plan, a full road map [07:17] with a nice little UI for it. It's fine. [07:22] I think there's a little too much going [07:24] on to counteract the markdown. I might [07:27] just be crazy here. I personally like [07:30] just reading markdown. So, this I don't [07:33] necessarily love, but I could see why it [07:36] would be valuable in certain places. How [07:38] about the PR writeups? [07:43] I like the idea of basically anything [07:45] that gives you a better hierarchy for [07:46] PRs. I also like the idea of being able [07:49] to like open and close parts of this to [07:51] make it easier for me to visualize [07:52] things. Like, I see some of the [07:54] potential here. I'm not in love with [07:55] this yet. So, I'm going to skip back to [07:57] the article and see how I can be [07:59] convinced by Lurk's words instead of his [08:02] examples. So, why HTML? We start with [08:05] information density. Here's a set of [08:08] different types of information. A single [08:09] HTML file can carry. Tables, design, [08:12] illustrations, code, images, spatial [08:13] workflows, and interactions. Good luck [08:15] getting it to include images, especially [08:17] if it can't generate them. I I cannot [08:19] tell you how many times I've seen models [08:21] hallucinate B 64 encodings or URLs even [08:24] to this day for images. It's actually [08:26] insane. Actually, on that note, I had a [08:28] funny one recently where I was asking [08:30] GPT 5.5 to find me images of a specific [08:34] thing that we were talking about. I [08:36] think it was like literally for some I [08:38] was installing in one of my doors, like [08:40] a carpentry task. I watched in its [08:42] reasoning trace. The user asked for us [08:45] to find images on the internet, but it's [08:48] in our system prompt that we must [08:50] generate an image whenever the user [08:51] asks. So, we're going to generate [08:53] images. And then it went and generated a [08:56] shitty image instead of finding the one [08:57] that I was looking for. So, these models [08:59] still suck at outputting images. They're [09:01] better at recognizing the contents of [09:02] them, but actually finding an image and [09:04] putting them somewhere, good luck. Have [09:06] fun. Back to the article. HTML can [09:08] convey much richer information compared [09:10] to markdown. It can of course do simple [09:13] document structure like headers and [09:14] formatting. But it can also represent [09:16] all sorts of other information like [09:18] tabular data using tables, design data [09:20] with CSS, illustrations with SVGs, code [09:23] snippets with script tags, interactive [09:25] using HTML elements with JavaScript and [09:27] CSS, workflows using SVG and HTML, [09:30] spatial data using absolute positions [09:32] and canvases, and images using image [09:34] tags. I'd go so far as to say that [09:36] there's almost no set of information [09:38] that Claude can read that you cannot [09:40] fairly efficiently represent with HTML. [09:42] This makes it a highly efficient way for [09:44] the model to communicate in-depth [09:46] information to you and for you to revy [09:48] it. I found that in the absence of being [09:51] able to do this, the model may do more [09:53] inefficient things in markdown like as [09:55] diagrams or my favorite estimating [09:57] colors with Unicode characters like in [09:59] this screenshot from Cloud Code. Also [10:01] notice the uh padding issue I mentioned [10:04] before where it just [ __ ] up the rows [10:06] and doesn't have the right number of [10:08] spaces. So the actual border is just [10:10] offset slightly. I see this all the [10:12] time. The next section is visual clarity [10:15] and ease of reading. As Claude is able [10:17] to do more complex work, it's also [10:19] writing larger and larger specs and [10:20] plans. In practice, I found I tend to [10:23] not actually read more than a 100line [10:24] markdown file and I'm certainly not able [10:26] to get anyone else in my org to read it. [10:28] But HTML documents are much easier to [10:30] read. Quad can organize the structure [10:32] visually to be ideal to navigate with [10:34] tabs, illustrations, links, etc. It can [10:36] even be mobile responsive so that you [10:38] can read it differently based on your [10:40] form factor. There's also the ease of [10:42] sharing. Markdown files are fairly hard [10:44] to share since most browsers do not [10:45] render them natively well. You often [10:47] have to add them as attachments to [10:49] emails or messages. With HTML, as long [10:51] as you upload the file, for example, to [10:53] S3, you can share the link easily. Your [10:56] colleagues can open it wherever they [10:58] wish and easily reference it. I have a [11:00] feeling those examples do not work well [11:02] on mobile. [11:06] Yeah. So, wherever they want is not [11:08] necessarily true as you see here. So, [11:12] not everywhere they want. They say it [11:15] can be mobile responsive. So, you read [11:17] it differently based on your form [11:18] factor, but the examples that were [11:19] shared here weren't. And the more of [11:21] those things you address, the more [11:23] bloated the HTML gets. and at some point [11:25] you're just burning output tokens. He [11:27] does also say that the chance of someone [11:29] actually reading your spec report or PR [11:30] write up is much higher if it's in HTML. [11:33] The idea I have to reconcile here is how [11:36] much of that is because the markdown is [11:38] too bloated and the HTML makes it more [11:40] readable versus how much of that is that [11:42] the HTML is novel enough that it's [11:46] easier to jump on and read because [11:48] there's less things like that that [11:50] you're being handed. Like if everyone [11:52] who is spamming us with giant markdown [11:53] files was to switch over to spamming us [11:55] with HTML links, how much more of that [11:58] would we be reading, I think it would be [12:00] better, but I don't think it's as much [12:01] better as it is now. The novelty of HTML [12:05] is a big portion of the value right now. [12:08] The interaction part is really strong, [12:09] too, though. I will give him that. HTML [12:12] can allow you to interact with the [12:13] document. For example, you might want to [12:14] ask it to add sliders or knobs to adjust [12:17] the design or allow you to tweak [12:18] different options in the algorithm to [12:20] see what happens. You can also ask it to [12:22] let you copy these changes into a prompt [12:24] to paste back into cloud code. He has a [12:26] bunch of examples of these types of [12:27] playgrounds and two-way interactions [12:28] that he's built. There's also data [12:30] ingestion. Why use cla code to make HTML [12:33] files instead of cla or claude design, [12:35] for example? One of the biggest reasons [12:37] is all the context that cla code can [12:39] get. For example, when writing this [12:41] article, I ask Claude Code to read [12:42] through my code folder and find all the [12:44] HTML files that I've generated, group [12:46] and categorize them, and then make an [12:48] HTML file with all the diagrams [12:50] representing each type. The diagrams you [12:52] see in this article are a direct result [12:53] of that. Besides the file system, cloud [12:56] code can find additional context using [12:58] your MCPS like Slack, linear, etc. Your [13:00] web browser with Claude and Chrome, your [13:02] git history, etc. Actually, a valuable [13:05] point here. I have done a lot of this [13:06] type of thing where I have like a bunch [13:08] of data on my computer or in some folder [13:10] somewhere and I just ask an agent to go [13:13] through it and visualize it to make [13:15] something more useful. I've done this [13:17] many times. I'm beginning to think that, [13:19] especially when he mentions the HTML [13:21] files that he has just scattered across [13:23] his computer, that something we might [13:25] need here is a better skill that [13:27] describes the shape of the HTML, tells [13:29] it can use Tailwind or whatever, gives [13:31] it a structure for what directories to [13:33] leave it in so you don't clog up your [13:34] git history. I'm going to think through [13:36] what a good skill for this would look [13:38] like, and play with that in the future. [13:41] I'll report back for sure. The next [13:43] point he has is that it's joyful. Making [13:45] HTML documents with Claude is just more [13:47] fun and it makes me feel more involved [13:48] and invested in the creation and that [13:50] itself is enough. Honestly, that's the [13:53] biggest point here. If this makes you [13:55] engage more with the output of your [13:56] agent so that you get better results and [13:59] are more involved in the process of [14:00] steering it, there's a lot of value [14:02] there. It's silly to say it that way, [14:04] but if the thing makes you more excited [14:06] to build and focus and iterate, that is [14:09] good. It's the same reason I've been in [14:11] favor of things like Vim. If setting up [14:12] Neo Vim makes you want to code more and [14:15] build more, awesome, do it. I'm all in [14:18] favor of things that get developers [14:19] excited to be more involved in the [14:21] process and to create more things. That [14:23] is always what I push for. So, how do [14:25] you get started? I'm a little bit afraid [14:26] that people will read this article and [14:27] turn it into a/HTML skill or something. [14:30] Look, I I didn't pre-eread. I am going [14:33] to do this to be clear, but I'm not [14:35] going to do just SL HTML. I'm going to [14:36] do something very different here. I have [14:38] plans. We'll get to those plans later. [14:40] probably not in this video, but make [14:42] sure you're subbed if you're not. By the [14:43] way, I'm amazed half y'all still haven't [14:44] hit that button. If you want to see my [14:46] future HTML skill video, or honestly [14:50] more exciting, the video I'm going to do [14:52] trying all of Matt Poc's skills, [14:54] definitely make sure you're subscribed [14:55] because there's a lot of fun content in [14:57] the pipeline. While there might be some [14:59] value in a skill like that, I want to [15:00] emphasize that you don't need to do much [15:02] to get Claude to do this. You can just [15:04] ask it to make an HTML file or make an [15:06] HTML artifact. The trick is knowing what [15:08] you want the artifact to do and how you [15:10] might use it. You may over time make a [15:12] skill, but for now, I suggest that you [15:14] just prompt from scratch to get the hang [15:15] of how to use it in different cases. I [15:18] absolutely agree. In general with [15:19] skills, you should always start by [15:21] asking the model to do the thing. See [15:23] what it gets right and wrong. Figure out [15:25] what parts you have to include every [15:26] time, what parts you don't, and then [15:28] slowly figure out what those are so you [15:30] can build a skill to do it right. And [15:33] also on that same note, one of the best [15:34] ways to test a skill is to just go copy [15:37] the text for said skill, paste it into [15:40] your input box, and hit enter and see [15:41] what happens. Like it's the same thing. [15:43] The first use case he has is for specs, [15:45] planning, and exploration. HTML is a [15:47] rich canvas for Claude to dive into a [15:48] problem. When I start working on a [15:50] problem, instead of a simple markdown [15:51] plan, I expect to make a web of HTML [15:54] files. For example, I might start with [15:56] asking Claude code to brainstorm and [15:57] create some explorations of different [15:59] options. I would then ask it to expand [16:01] more into one, maybe make mockups or [16:03] code snippets. Finally, when I'm feeling [16:05] good, I'll ask it to write an [16:06] implementation plan. When I have a plan, [16:08] I'll create a new session and pass in [16:09] all of those files for it to implement. [16:12] Notice that he says he'll create a new [16:13] session instead of compaction. [16:15] Definitely not cuz the compaction is [16:16] kind of garbage in cloud code. Or to be [16:19] fair, it got really bad at GBD55. I hate [16:22] the compaction now and I used to trust [16:23] it dearly with 53 and 54. So yeah, I'm [16:27] starting more sessions than I ever did. [16:28] Even a simple thing like I just a few [16:30] days ago did the uh Azure bench thing a [16:33] very simple benchmark just measuring [16:35] inference speeds on Azure. I did like 30 [16:38] plus threads to make this obviously all [16:41] in T3 code. I wonder why but yeah I [16:44] realized it's better to just make a [16:46] shitload of branches and a shitload of [16:48] threads instead of trying to massage an [16:50] existing long thread into the shape you [16:52] want. I just copy paste the parts I like [16:54] into a new thread and start from [16:56] scratch. But it is cool that the HTML [16:58] files are a good thing to hand to an [17:00] agent. I bet you could just take one of [17:02] these HTML files, give it to the agent [17:04] with no additional context, and it'll [17:06] usually figure out what you want. Makes [17:08] sense. Also useful for verification. [17:10] When he's verifying the results of the [17:12] work, he'll ask a verification agent to [17:14] read the HTML files, and it will have a [17:16] much broader context on what it actually [17:17] needs to verify. That's a really useful [17:19] point. He gives some example prompts [17:20] here, too. I'm not sure what direction [17:22] to take the onboarding screen. generate [17:24] six distinctly different approaches, [17:26] varying layout, tone, and density, and [17:28] lay them out as a single HTML file in a [17:30] grid so I can compare them side by side, [17:32] label each with the trade-off it's [17:34] making. I like this a lot. Again, having [17:36] the model generate distinctly different [17:38] options in one pass gets you a much [17:40] better variety than you might otherwise [17:42] get. The next example he has is, create [17:43] a thorough implementation plan in an [17:45] HTML file. Be sure to make some mockups, [17:47] show data flows, and add important code [17:49] snippets that I might want to review. [17:51] Make it easy to read and digest. Again, [17:53] just getting used to prompting the model [17:55] and seeing how it responds to these [17:56] different scenarios. There is no one [17:58] guide. And even if there was, as model [18:00] updates happen, things change so fast. [18:02] You got to just feel it out with these [18:04] things. The next section he has is for [18:06] code review and understanding. Code [18:07] could be difficult to read in a markdown [18:09] file. Eh, if you have a good like [18:11] markdown parser, even one in like VS [18:13] Code, and I'll just demo this quick. [18:15] Let's uh check the skillmd file. Okay, [18:18] cool. This file is a markdown file. It's [18:21] actually already quite readable in my [18:22] opinion. If I make the font bigger, it's [18:24] even more so. Watch this. [18:27] Typescript const x equals sub nerds [18:31] please sub. It does syntax highlighting [18:34] in code blocks as long as you label it [18:36] with the language. If I delete that, it [18:37] stops. I'm amazed how people don't know [18:39] this. In most markdown parsers, when you [18:41] do the triple back tick, you can put the [18:43] file extension for the language and it [18:46] will do syntax highlighting for that [18:48] language. If you include this in the [18:50] browser via HTML, it now has to figure [18:53] out how to render the diffs and how to [18:56] render the code blocks. The process of [18:58] it figuring out how to do this, much [19:01] less doing it properly, is as if not [19:03] more expensive, both mentally for me as [19:06] the person consuming it, but more so for [19:08] the agent generating this and generating [19:09] the tokens, that this is actually just [19:12] as good. To each their own, but I don't [19:15] necessarily agree with that piece. I [19:17] will say rendering diffs sucks in [19:19] markdown. Code can be difficult to read [19:22] in a markdown file. Don't agree there. [19:23] As I just established with HTML, we can [19:26] render diffs, annotations, flowcharts, [19:28] modules, etc. I don't really want these [19:31] things in my code snippets that I'm [19:33] reading outside of like a comment. I do [19:35] want diffs though, so not having diff [19:37] sucks. Use this to understand code that [19:39] the agent has written to get code review [19:41] or to explain a PR to somebody reviewing [19:43] your code. I find this often works [19:45] better than a default GitHub diff view. [19:47] And I attach an HTML code explainer to [19:49] every PR I make now. Interesting. I see [19:52] potential for this part. One of my [19:55] favorite things a sponsor built [19:57] recently, and this is not something [19:58] they're paying me to say. This is just a [20:00] thing I genuinely think is cool. It's [20:02] Devon Review. So, if you take github.com [20:04] and change that to devonreview.com for a [20:06] given PR, it will do an analysis of this [20:10] poll request. But the coolest parts are [20:12] that it will actually change the view to [20:15] be organized based on the importance and [20:18] grouped based on the related changes. So [20:20] instead of it just having all of the [20:22] files in order, it'll create its own [20:25] hierarchy where things are. Apparently I [20:27] am out of credits on my original comped [20:30] account. I'll have to deal with that [20:31] later. Julius has been abusing all of [20:33] these tools. Clearly, I'm not using it [20:35] that much if it's broken right now, but [20:36] the couple times I did, I actually found [20:37] it really nice and I'm going to go reup [20:39] because I've enjoyed it a lot. The idea [20:41] of changing how we review code to be [20:44] better shaped based on the sheer volume [20:45] of code that we're reviewing is a good [20:47] idea and it's one I like because going [20:49] through all of your code in alphabetical [20:51] order depending on where it is in your [20:53] project has always been [ __ ] stupid [20:55] and it's more stupid than ever now. [20:57] doing this yourself as a developer by [20:59] telling the model to generate HTML, [21:02] summarizing the code, showing the [21:03] changes, and making a better hierarchy. [21:05] That's a good idea. I like this. The [21:08] other cool thing is that you can steer [21:09] the model towards the parts you want the [21:11] reviewers to focus on. So, in this [21:13] example prompt he has, he says, "Help me [21:15] review this PR by creating an HTML [21:16] artifact that describes it. I'm not very [21:18] familiar with the streaming and back [21:20] pressure logic, so focus on that. render [21:22] the actual diff with inline margin [21:24] annotations, color code findings by [21:26] severity, and whatever else might be [21:28] needed to convey the concepts. Well, I [21:29] like this idea a lot. Then we have the [21:31] designs and prototypes. Claude design is [21:33] based on HTML because HTML is incredibly [21:35] expressive at design. Even if your end [21:37] surface isn't HTML, Claude can sketch [21:39] out a design in HTML and then write it [21:41] in your language of choice, be it React, [21:43] Swift, etc. I love that React's a [21:45] language here. Long debate from the [21:47] olden days of webdev, but React is kind [21:49] of a language. You can also prototype [21:51] interactions like animations, actions, [21:52] etc. Consider asking Claude to make [21:54] sliders, knobs, etc. to tune in exactly [21:57] what you're looking for. Yeah, this is a [22:00] little much for a simple checkout [22:01] button, but I I get why you would want [22:04] to care this much. This section is one [22:06] of my personal favorites, using this for [22:08] reports, research, and learning. Cloud [22:10] Code's incredibly good at synthesizing [22:11] information across multiple data sources [22:13] and converting it into a report for [22:15] readability. You can prompt Claude to [22:16] search your Slack, your codebase, Git [22:18] history, the internet, etc., and use it [22:20] to generate extremely readable reports [22:22] for yourself, for your leadership, for [22:24] your team, etc. This is actually a crazy [22:27] hack for those who are looking for ways [22:28] to like stand out using AI at your [22:30] company. Give an agent access to your [22:32] Jira and ask it to make a nicel looking [22:34] HTML page over what got done every week [22:36] and then present that during your [22:38] standup. Like, give people a resource to [22:40] look at that makes the leaders feel like [22:42] they understand what's going on. It's [22:43] stupid, but this is a really simple way [22:45] to like look cool to your team and to [22:47] your leadership. Making them feel more [22:49] informed by running a simple prompt. [22:52] Really powerful. Yeah, chat's already [22:54] understanding. Wait, I don't think my [22:56] manager allows me to use the Jira API [22:58] yet, but I can do this. Management will [22:59] go crazy over this. Yeah, you guys get [23:01] the idea. Always happy to sneak in these [23:04] hacks for career growth where I can. [23:06] There's a lot of fun ones here if you [23:08] know where to look. You can assemble [23:09] things like this in long- form HTML [23:11] documents, an interactive explainer, or [23:13] even a slideshow or deck. Ask Claude to [23:15] use SVG for diagrams to help visualize [23:17] it. I have not seen these models get [23:19] super good at SVGs just yet, so might [23:22] not have the best luck there, but maybe. [23:24] Somebody just said that they got Cloud [23:26] Code access at work last week. Thanks [23:27] for the idea. Anytime. Yeah, you can do [23:29] this without having one of those either. [23:30] You can spin a pretty simple API calls [23:32] to DIY this, too. If you're curious how [23:34] you would do this without cloud code, [23:36] maybe watch my video on how harnesses [23:38] work. I have a whole dedicated video on [23:40] how cloud code works. That's more [23:41] generic. How to get AI to write code and [23:44] do real stuff. You can build your own [23:46] solution internally that doesn't require [23:48] cloud code that has all of these same [23:50] powers. So definitely worth considering [23:51] if you haven't done stuff like that yet. [23:53] An example that he has here is he made a [23:55] post on prompt caching. In order to do [23:57] that, he asked Claude to prepare an [23:58] in-depth research file in HTML for him [24:00] to read on all of their changes to [24:02] prompt caching after reading the git [24:04] history. That's actually really cool. [24:06] And again, like your prompt doesn't [24:08] always need to be honest about who you [24:10] are. Sometimes it's useful to take a [24:12] different perspective to steer the model [24:14] the right way. Even if you are fully [24:15] aware of how the rate limiter works, [24:17] telling the model that you don't [24:19] actually understand it is a really [24:20] powerful way to get it to write and [24:22] create artifacts for an audience that [24:24] isn't you. I find a lot of devs actually [24:26] get hung up on this. They don't know how [24:28] to talk to the agent outside of their [24:30] own voice. They only know how to tell it [24:33] what they specifically want and know and [24:35] do, not how to move past their own [24:38] knowledge to get the model steered [24:40] towards something that isn't for them. [24:42] It's easy to make an agent create things [24:44] for yourself. It is a very different way [24:47] to think to steer agents to make things [24:49] for others. And this is a silly but [24:51] really good example here. just saying I [24:53] don't understand how a rate limiter [24:55] works. Read the relevant code and [24:56] produce a single HTML explainer page, a [24:59] diagram of the token bucket flow, the [25:01] three to four key snippets annotated, [25:02] and a gotcha section at the bottom. [25:04] Optimize it for someone reading it once. [25:06] I do this all the time. I would argue [25:08] almost half of my prompts are me [25:10] pretending to be dumber than I am so [25:12] that the model will steer in the right [25:14] direction for my users and then I take [25:15] the reins back whenever it goes where I [25:17] don't want it. Here's another fun one, [25:18] and I've actually done this a few times [25:20] before. using HTML to create custom [25:22] editing interfaces. Sometimes it's hard [25:24] to describe what you want purely in a [25:26] text box. In this case, I'll ask Cloud [25:28] to build me a throwaway editor for the [25:29] exact thing that I'm working on. Not a [25:31] product or reusable tool, but a single [25:33] HTML file purpose-built for this one [25:35] piece of data. Yep. A lot of devs still [25:38] aren't over the fact that like code is [25:40] expensive, so you only should write it [25:41] for reused things. Code is cheap now. [25:43] Writing a bunch of code just to play [25:45] around with some data to make a good [25:47] decision about other code you're writing [25:48] is absolutely worth it. of the code I [25:50] write right now write obviously in [25:52] quotes I would say about 70 plus percent [25:55] of it immediately gets thrown out after [25:57] I run it one time if even more devs need [25:59] to internalize this way of thinking [26:01] because you can make much better stuff [26:03] for your end users if you build custom [26:06] tools to get there that are only ever [26:08] used once and thrown away. The trick [26:10] here is to always end with an export a [26:12] copy as JSON or copy as prompt button [26:14] that turns whatever I did into the the [26:16] UI back into something that I can paste [26:18] into cloud code. Ready for a silly [26:20] example of this? When I was trying to [26:22] waste as much of GitHub's money as [26:24] possible with my abuse of Copilot, I [26:26] wanted a good way to visualize that. And [26:29] uh yeah, Anthropic makes a really shitty [26:32] broken site, so I can't show you [26:33] apparently right now, even though it [26:35] generated me a nice little web app that [26:37] I could use inside of Claude to [26:39] calculate how much money I had spent and [26:41] then import and export a CSV that just [26:44] took upwards of a minute and a half to [26:45] [ __ ] load despite being a single [26:47] JavaScript file. God, the I've been so [26:50] nice this whole video. I I will take [26:52] this brief tangent to emphasize just how [26:55] [ __ ] terrible the engineering at [26:57] Anthropic is. It is genuinely [ __ ] [27:00] hilarious how bad these guys are at [27:02] code. That was insultingly bad. It makes [27:04] sense that he only mentions artifacts [27:07] once in this article because they're [27:08] [ __ ] useless and no one should use [27:10] them because the actual implementation [27:12] on the anthropic site is [ __ ] [27:13] garbage. Which is why I tried it for [27:14] this cuz I wanted to once again see if [27:16] it's made any progress. The answer is it [27:18] [ __ ] hasn't. The models can make a [27:20] nice little artifact that lets me have [27:21] this fancy interface for putting in [27:23] values. I can import from the table. I [27:26] can export the table to this view and [27:28] very easily copy paste the CSV. I made [27:31] this so I could quickly blast through [27:33] all of the data for all the agent runs I [27:34] had to see how much money I was able to [27:36] waste of GitHubs. But god damn, [27:38] Anthropic cannot code for [ __ ] You get [27:40] the idea though. The creating of a UI to [27:43] play with these things and an export [27:46] format that you can paste other places [27:47] be it is a state that you want to reuse [27:49] later or values that you want to pass to [27:51] your agent. Very powerful. Thinking in [27:53] this way will be beneficial. And that's [27:55] really what I want to like make this [27:56] video for and push you guys towards [27:59] thinking in terms of inputs and outputs [28:01] beyond just the flows of your code. How [28:04] do you use new code for one-off problems [28:07] that lets you import and export data [28:10] that is valuable to your agents? You can [28:12] build much more effectively as a result [28:14] of thinking this way. It has [28:16] fundamentally changed how I build what I [28:18] build and how I manage my team, how I [28:20] process data, all of these things. [28:22] realizing that every time you have a [28:24] database, a CSV, a JSON blob, that's [28:27] your data from something that you did, [28:29] or even just a prompt with some complex [28:31] values in it, generating code to help [28:34] smooth out the edges and give you the [28:37] info you're looking for is super [28:39] valuable. He has an FAQ section here, [28:41] and I'm sure a lot of you guys have the [28:42] same questions. The first is the big [28:45] question. I've seen this a lot. Isn't [28:46] this less token efficient? I've even [28:48] seen people going as far as saying that [28:50] Thor's only writing this in order to get [28:52] people to waste more tokens to make [28:53] anthropic more money. I think those [28:55] people are dumb. It's a funny joke, but [28:57] it's not very real. While Markdown does [28:59] often use fewer tokens, I found that the [29:00] added expressiveness of HTML and the [29:02] much higher likelihood of me reading it [29:04] means that I get overall better outputs. [29:06] With the 1 million token context window [29:08] in Opus 47, the increased token usage is [29:10] not really noticeable in the context [29:12] window. That's a silly point to make. [29:14] Next, he has when do you use markdown [29:16] for now? I've honestly stopped using [29:17] markdown altogether for almost [29:19] everything, but I'm probably far on the [29:20] HTML maximalist side of things. That's a [29:23] little insane to me. Moving out of [29:25] Markdown entirely is crazy. How do you [29:27] view the HTML files? He doesn't just [29:29] open them in a browser locally. You can [29:30] even ask Claude to open it or upload to [29:32] S3 if you want a sharable link. Fine. [29:35] There's evidently an opportunity for a [29:36] micros service for this, by the way. [29:38] Wink. What about version control? This [29:40] is honestly one of the biggest downsides [29:42] of HTML. HTML diffs are noisy and hard [29:44] to review when compared to markdown. How [29:46] do I get Claude to match my taste and [29:48] not make it all ugly? The front-end [29:50] design plugin helps Claude make good [29:52] HTML files, but to match your own [29:54] company's style, you can create a single [29:56] design system HTML file by pointing [29:57] Claude at your codebase. You then use [29:59] that design system file as a reference [30:01] to other HTML files. [30:04] How they didn't call out the skill for [30:06] this, but there there's a direction here [30:08] where you could make a better primitive [30:10] that is still HTML, but lets the agent [30:12] make things look better, more portable, [30:14] have better version control, have better [30:16] hosting, better context on what else is [30:18] going on. There are ways to adjust this, [30:21] but until we move from claude MD to cla [30:23] HTML, this is just an experiment as far [30:26] as I'm concerned. I do like Thor's [30:27] endpoint, which I'll get to in a sec [30:29] because I want to remind you guys we [30:30] still have to read Karpathy's thoughts [30:31] as well. So don't skip just because I'm [30:33] at the end of this. He ends with stay in [30:35] the loop. All of the above is to say [30:37] that I think the real reason that I use [30:38] HTML is that I feel much more in the [30:40] loop with Claude. I'd begun to fear that [30:42] because I'd stopped reading plans in [30:43] depth, I would simply have to leave [30:45] Claude to make its choice. But I'm happy [30:47] to say instead that I feel more in the [30:49] loop than ever before when I use HTML. I [30:52] hope that you do, too. I'm going to try [30:53] this a bunch and report back on how I [30:55] feel. So keep an eye on my channel if [30:57] you want to see that. But Carpathy's [30:59] already made the move and I want to hear [31:00] what he has to say. This works really [31:02] well, by the way. At the end of your [31:03] query, ask your LM to structure your [31:05] response as HTML, then view the [31:07] generated file in your browser. I've [31:08] also had some success asking the LLM to [31:10] present its output as slideshows, etc. [31:13] More generally, in my opinion, audio is [31:15] the human preferred input to AIS, but [31:17] vision like images, animations, and [31:19] video are the preferred output from [31:20] them. I think I agree. I am always [31:23] surrounded with my team, so I don't get [31:24] to use audio in as much as others do. [31:27] And I'm not like Prim. I don't walk [31:28] around talking to my phone to send [31:30] texts. I I respect the balls he has to [31:32] do that. The number of times I've been [31:33] hanging with Prime and he like just [31:34] pulls out his phone and like voice to [31:36] text something to his wife or to his [31:38] kids is adorable and I respect it. I'm [31:41] too insecure to do that myself. But [31:43] there are some people who will just [31:44] prompt all day who will speak to their [31:46] phone to talk to their family to send [31:48] prompts whatever else and all power to [31:50] them. Around a third of our brains are [31:52] massively parallel processors dedicated [31:54] to vision. It's the 10 lane superighway [31:56] of information into the brain. As AI [31:58] improves, I think we'll see a [31:59] progression that takes advantage of [32:01] that. I totally agree. I think vision is [32:04] how people like to process info, and [32:06] it's really nice to be able to like [32:07] listen to music and watch something that [32:09] my computer did at the same time. Text [32:11] is a little more process heavy, but [32:14] yeah, you get the idea. He lists these [32:16] examples of things. Raw text, which is [32:18] hard and effortful to read. Markdown, [32:20] which is a bit easier to read once you [32:22] have bold, italic, headings, tables, all [32:23] of those types of things to the current [32:25] default. Then you have HTML which is [32:27] still procedural with the underlying [32:28] code but it's a lot more flexible on the [32:30] graphics and layout even interactivity [32:32] side early but it's a forming new good [32:34] default and eventually we get further [32:36] and further until we have interactive [32:38] neural videos and simulations. [32:40] Interesting hypothesis he has here where [32:42] he thinks we're going to progress to [32:44] more and more visual interactive outputs [32:47] for models. Very curious to see where [32:49] this goes. IMO the extrapolation though [32:52] the technology doesn't exist just yet [32:53] ends in some kind of interactive videos [32:55] generated directly by a diffusion neural [32:57] net many open questions as to how exact [33:00] and procedural software 1.0 show [33:02] artifacts like interactive simulations [33:04] may be woven together with neural [33:05] artifacts like diffusion grids but [33:08] generally something in this direction of [33:09] the recently viral uh what is this that [33:11] he's linking interesting imagine every [33:13] pixel on your screen streamed live [33:15] directly from a model no HTML no layout [33:18] engines no code just creating this UI [33:20] dynamically very interesting there are [33:23] also improvements necessary and pending [33:25] at the input audio nor text nor video [33:27] alone is enough I feel a need to point [33:30] and gesture to things on the screen [33:31] similar to all the things you would do [33:33] with a person physically next to you and [33:35] your computer screen. Okay, I cannot [33:36] tell you guys how often I've done [33:38] exactly this. I'm going to just show [33:40] screenshot edit. I use Shotterter. [33:43] There's lots of other screenshot [33:44] utilities. I'm going to just highlight [33:46] this section, copy this, paste it to [33:50] codeex. Cool. What are your thoughts on [33:54] this paste image? Actually, I can't see [33:57] the image here because I'm using a [33:58] terminal. No one should use terminals [34:00] for these types of things. So I will [34:02] just hop over here instead. Paste the [34:03] image. What are your thoughts on this? [34:07] And now I can actually see the image I [34:09] just pasted because using gooies is [34:10] nice. Shout out T3 code. Fully open [34:13] source. Works with all of your [34:14] terminals. This is just a different view [34:16] for the same thing. Yeah, I can't [34:18] believe we're all just living with [34:19] pasting images in a UI where we can't [34:21] even see them. The amount of cope and [34:23] like copy pasting is broken too because [34:25] it has to handle all the formatting and [34:27] the ter. Why are we still using [ __ ] [34:29] terminals? Yeah. And here we get a much [34:32] better formatted output in a UI that is [34:33] much less bad. Something I'm now [34:36] thinking about is what would it look [34:37] like if in T3 code we asked the HTML [34:40] output thing similarly and it could [34:42] actually output custom UI in body here. [34:46] I might play with this idea in the near [34:47] future, but part of T3 code being open [34:49] source is that you can go add this [34:51] yourself. If you're interested in what [34:53] it would look like to let agents respond [34:55] with HTML inside of your agent to coding [34:57] experience, you have to leave here to [34:59] see it. And maybe you can click a share [35:00] button to send it to somebody else. [35:02] There you go. Fun opportunity. Play with [35:04] it. Carpathy closes with the following. [35:06] The input and output mind meld between [35:08] humans and AIs is ongoing and there's a [35:10] lot of work to do and significant [35:12] progress to be made way before jumping [35:14] all the way into neural linkes brain [35:16] computer interfaces and all of that. For [35:18] what's worth exploring at the current [35:20] stage, hot tip, try asking for HTML. We [35:23] have a shitload of exploration to do as [35:24] an industry here still. We are still [35:27] figuring out the output formats that [35:28] make sense. We're not even close to [35:30] figuring out the interfaces. The fact [35:32] that we're still so attached to our [35:33] terminals shows how far we are from [35:36] getting this all right. And in a world [35:38] where we can make better output formats [35:40] in better UIs with better control and [35:42] customizability, we can make better [35:44] software as a result. That said, HTML is [35:48] just the starting point. And while [35:50] Karpathy seems to think that the [35:51] direction we're going in is interactive [35:53] videos and simulations, I think we have [35:55] some important steps to go through [35:57] first. in chat has correctly identified. [35:59] I think MDX is an untapped market. All [36:02] roads lead to React.  📄 **Full text:** ![[Full Document Contents/Articles/Stop Letting Your Agents Write Markdown..md|Stop Letting Your Agents Write Markdown. by YouTube]] ## Highlights - the unreasonable effectiveness of HTML. He then followed up with HTML is the new markdown. I've stopped writing markdown files for almost everything and switched to using cloud code to generate HTML for me instead. This article is why I have seen some fun hacks around using HTML with tools like claude code. I actually learned a bunch of these from Simon Willis way back when we were doing GBT testing together. I have been amazed at some of the clever things people figure out with HTML and how they use it to be more effective working with agents. And ([View Highlight](https://read.readwise.io/read/01krgq98fv08ksjfnzc965j9s6)) - Tags: 👻 ai highlighted - Thor and I aren't the only ones who feel this way. Carpathy actually came out and said that this works really well, just asking it to structure responses as HTML. He had a lot to say as well. We're going to go into all of this and more. Agents clearly like Markdown and HTML, but there's one more important thing that agents love. Today's sponsor. Building most things with AI is pretty easy, but there's one that's surprisingly hard. Building AI apps with AI. It turns out all the weird things like persisting threads, streaming chats, getting UI to render dynamically on the fly and more just kind of is hard to do. Believe me, I've tried a lot. E3 ([View Highlight](https://read.readwise.io/read/01krgq98g1yzynsa28rygfmzsq)) - Tags: 👻 ai highlighted - been around for a while, you're already familiar with all this. And then you give it the custom component that actually renders the results. They also have a hook for interactive components right here, which is just as easy to use. Getting the front end and the back end to interact properly in systems like this is incredibly complex. Copilot kit couldn't make it easier, even if you don't want to use their components. I know Ben's already building his own wrappers around it in spelt. Build better interactive experiences with agents at soyb.v.link/copilotkit. Let's see what Thor has to say about the unreasonable effectiveness of HTML for agents. Markdowns become the dominant ([View Highlight](https://read.readwise.io/read/01krgq98ga7d1079snzb83d8ps)) - Tags: 👻 ai highlighted - I want to be able to share them easily. I'm also increasingly not editing these files myself, but using them as specs, reference files, brainstorming outputs, etc. When I do make edits, I'm usually prompting Claude to edit them, which removes one of Markdown's largest benefits. I've started preferring HTML as an output format instead of Markdown, and increasingly see this being used by others on the Claude Code team. This is why you want to start with some examples. You can see a bunch here. This HTML effectiveness GitHub page. Just be sure to come back and read more after. ([View Highlight](https://read.readwise.io/read/01krgq98gtrhnrfp5xyyqdnhxj)) - Tags: 👻 ai highlighted - better, but I don't think it's as much better as it is now. The novelty of HTML is a big portion of the value right now. The interaction part is really strong, too, though. I will give him that. HTML can allow you to interact with the document. For example, you might want to ask it to add sliders or knobs to adjust the design or allow you to tweak different options in the algorithm to see what happens. You can also ask it to let you copy these changes into a prompt to paste back into cloud code. He has a bunch of examples of these types of playgrounds and two-way interactions that he's built. There's also data ([View Highlight](https://read.readwise.io/read/01krgq98j7g50f891sgwn9dvrx)) - Tags: 👻 ai highlighted - web browser with Claude and Chrome, your git history, etc. Actually, a valuable point here. I have done a lot of this type of thing where I have like a bunch of data on my computer or in some folder somewhere and I just ask an agent to go through it and visualize it to make something more useful. I've done this many times. I'm beginning to think that, especially when he mentions the HTML files that he has just scattered across his computer, that something we might need here is a better skill that describes the shape of the HTML, tells it can use Tailwind or whatever, gives ([View Highlight](https://read.readwise.io/read/01krgq98kxv76pzz4pc9ppys5p)) - Tags: 👻 ai highlighted - to other HTML files. How they didn't call out the skill for this, but there there's a direction here where you could make a better primitive that is still HTML, but lets the agent make things look better, more portable, have better version control, have better hosting, better context on what else is going on. There are ways to adjust this, but until we move from claude MD to cla HTML, this is just an experiment as far as I'm concerned. I do like Thor's endpoint, which I'll get to in a sec because I want to remind you guys we ([View Highlight](https://read.readwise.io/read/01krgq98yecwadw1y9ch8kbew4)) - Tags: 👻 ai highlighted