Stop Letting Your Agents Write Markdown.  🔗 **Source:** [Stop Letting Your Agents Write Markdown.](https://www.youtube.com/watch?v=S9EGx6ik-18) I recently published a video about allthe flaws in Markdown. And you allreally loved that one. Uh, kind of. Youdefinitely weren't super rude to me inthe comments about how I'm click baitingand terrible and then watch the videoand realize I actually had things to sayabout Markdown. But yeah, it seems likeMarkdown's a sensitive topic for a lotof people because it does have a lot ofstrengths. I mean, I've been a Markdownfan for the better part of two decadesnow. I understand. But I feel like we'reoverusing it. And it seems like I'm nolonger the only one who feels this way. Thoric from the cloud code team justpublished an article using Claude code,the unreasonable effectiveness of HTML.He then followed up with, "HTML is the newMarkdown." I've stopped writing markdownfiles for almost everything and switchedto using Cloud Code to generate HTML forme instead. This article is why I haveseen some fun hacks around using HTMLwith tools like Cloud Code. I actuallyLearned a bunch of these from SimonWillis way back when we were doing GBTtesting together. I have been amazed atsome of the clever things people figureout with HTML and how they use it to bemore effective working with agents. AndThor and I aren't the only ones who feelthis way. Carpathy actually came out andsaid that this works really well, justasking it to structure responses asHTML. He had a lot to say as well. We'regoing to go into all of this and more. Agents clearly like Markdown and HTML,but there's one more important thingthat agents love. Today's sponsor.Building most things with AI is prettyeasy, but there's one that'ssurprisingly hard. Building AI apps withAI. It turns out all the weird thingslike persisting threads, streamingchats, getting UI to render dynamicallyon the fly and more just kind of is hardto do. Believe me, I've tried a lot. E3chat and T3 code show just how hard itis to get this right. And if Copilot wasThere, when we started, it would havemade my life much easier. They callthemselves the enterprise-ready front-end stack for agents, but I wouldgo further than that because it's notjust front end. It's a real full stacksolution. Here's a simple app we builtwith Copilot Kit. We're going to ask itto compare the latest models from OpenAIand Anthropic. You probably expected tojust render a really bad markdown table,right? Nope. You can write customcomponents in whatever framework or toolsystem you want. Obviously, we're bigReact guys here, and their React stuff isgreat. So here it just rendered a customcomponent listing all of the different models and their prices. But moreimportantly, it rendered a comparisonoption here where I, as the user, caninteract, make changes, hit submit, andnow it's going to do another pass wherethe model gets all of the informationback and renders another dynamic UI, allbased on components that we wrote. TheCode couldn't be simpler. They provide ause component hook that you give a name,description, and parameters, which arejust the things it needs to pass. Youknow, classical Zod schema here. You'vebeen around for a while, you're alreadyfamiliar with all this. And then you give it the custom component thatactually renders the results. They alsohave a hook for interactive componentsright here, which is just as easy touse. Getting the front end and the backend to interact properly in systems likethis is incredibly complex. Copilot kitcouldn't make it easier, even if youdon't want to use their components. Iknow Ben's already building his ownwrappers around it in spelt. Buildbetter interactive experiences withagents at soyb.v.link/copilotkit. Let's see what Thor has to say about theunreasonable effectiveness of HTML foragents. Markdowns become the dominantfile format used by agents tocommunicate with us. It's simple,Portable, has some rich text capability,and it's easy for you to edit. Glad haseven got surprisingly good at using AIto make diagrams inside of markdownfiles. I would disagree. I can't tellyou how many times I see it miss pad andhave like certain layers just like pushout too far on the borders. It is whatit is. As agents have gotten more andmore powerful, I have felt that markdownhas become a restricting format. I'vehad difficulty reading a markdown fileof more than 100 lines. I want richervisualizations, color, and diagrams, andI want to be able to share them easily. I'm also increasingly not editing thesefiles myself, but using them as specs,reference files, brainstorming outputs,etc. When I do make edits, I'm usuallyprompting Claude to edit them, whichremoves one of Markdown's largestbenefits. I’ve started preferring HTMLas an output format instead of Markdown,and increasingly see this being used byothers on the Claude Code team. Why you want to start with someexamples. You can see a bunch here. ThisHTML effectiveness GitHub page. Just besure to come back and read more after.We will do just that. Oh, yep. I canalready smell the Claude code designskill all over this one. Something I'vebeen meaning to do for a bit. I amfinally tired of the front-end designskill. And as such,away it goes.I have now removed the front-end designskill because I am so tired of thisstale copy-paste design format thateverything ends up with. Cool. Theunreasonable effectiveness of HTML. 20self-contained HTML files and agentproduced instead of a wall of markdown. Each one trades a document you'd skimfor one that you'd actually read. Openany of them directly in a browser. Groupby the kind of work that they replace. Ican tell from this copy that this waswritten by an agent. I recently gotgifted a sub to Pangram Labs fromSlasher, and it apparently is really goodat detecting AI-generated text. From mybrief experimentation, it was. So, we'regoing to start with this article andtake a look to see if we are reading AIslop or not. Okay, the site's superbroken, but apparently 100% of the textis human written. Good start. But if weswitch over to this site,I'll just grab different sections of thetext. Yep, just as expected, the HTML isentirely AI-generated. People arealready asking, so I'll make it clear. This wasn't an ad. I just have a friendthat works at the company now and wasskeptical of how good Pangram was at AItext detection. And thus far, it's had apretty close to 100% hit rate for mytest experience. I don't know if theproduct's any good. I don't knowanything about it beyond it being sentto me by a friend. And yeah, it seemscool, and it's fun to quickly check ifsomething's AI-generated or not because IConfirmation, some amount. It's all lossy. It is what it is. Just wanted tosee. So we're not reading AI slop whenwe read his article, but we'reabsolutely reading AI slop when we readthese HTML files. Let's go back toreading these HTML files. He shows someexamples with exploration in planning. When you're not sure what you want yet,ask the agent to fan out across severaldirections and lay them next to eachother so you can point at one instead ofreading three sequential walls of textand trying to hold them all in yourhead. Once you've picked, turn the pickinto a plan that the implementer canactually read. So here it made HTML forthree ways to implement debouncedsearch. It generated an inline useeffective set timeout, a custom usedebounce hook with pros and cons undereach as well as a tiny external librarythat it could use. It had arecommendation at the bottom. I'm okaywith this just being in the chat, but ICan see why in certain cases this wouldbe worth breaking out into an HTML file. Visual design directionsfor the no tasks yet state. So, this isit mocking four potential directions forthe UI. This I could see being useful. I've already done a trick similar tothis before, and I've shared this inmany videos where when I want differentdesign renditions for something, I don'task the model to do one and then askagain for it to do another. I ask youfor four distinct options that it willput on different routes so I can take alook at all of them just because I wantto see them all. And if you ask it togenerate them all at once, you'll getmore variety than asking one afteranother because it's going to just godown a similar path otherwise. Anotherfun example that he has here isimplementation plan, a full road mapwith a nice little UI for it. It's fine. I think there's a little too much goingon to counteract the markdown. I mightJust be crazy here. I personally likejust reading markdown. So, this I don'tnecessarily love, but I could see why itwould be valuable in certain places. Howabout the PR writeups? I like the idea of basically anythingthat gives you a better hierarchy forPRs. I also like the idea of being ableto like open and close parts of this tomake it easier for me to visualizethings. Like, I see some of thepotential here. I'm not in love withthis yet. So, I'm going to skip back tothe article and see how I can beconvinced by Lurk's words instead of hisexamples. So, why HTML? We start withinformation density. Here's a set ofdifferent types of information. A singleHTML file can carry. Tables, design,illustrations, code, images, spatialworkflows, and interactions. Good luckgetting it to include images, especiallyif it can't generate them. I cannottell you how many times I've seen modelshallucinate B 64 encodings or URLs even. To this day, for images, it's actuallyinsane. Actually, on that note, I had afunny one recently where I was askingGPT 5.5 to find me images of a specificthing that we were talking about. Ithink it was like literally for some, Iwas installing in one of my doors, likea carpentry task. I watched in itsreasoning trace. The user asked for usto find images on the internet, but it'sin our system prompt that we mustgenerate an image whenever the userasks. So, we're going to generateimages. And then it went and generated ashitty image instead of finding the onethat I was looking for. So, these modelsstill suck at outputting images. They'rebetter at recognizing the contents ofthem, but actually finding an image and putting them somewhere, good luck. Havefun. Back to the article. HTML canconvey much richer information comparedto markdown. It can, of course, do simpledocument structure like headers andformatting. But it can also representAll sorts of other information liketabular data using tables, design datawith CSS, illustrations with SVGs, codesnippets with script tags, interactiveusing HTML elements with JavaScript andCSS, workflows using SVG and HTML,spatial data using absolute positionsand canvases, and images using imagetags. I’d go so far as to say thatthere’s almost no set of informationthat Claude can read that you cannotfairly efficiently represent with HTML. This makes it a highly efficient way forthe model to communicate in-depthinformation to you and for you to revyit. I found that in the absence of beingable to do this, the model may do moreinefficient things in markdown like asdiagrams or my favorite estimatingcolors with Unicode characters like inthis screenshot from Cloud Code. Alsonotice the uh padding issue I mentionedbefore, where it just [ \_\_ ] up the rowsand doesn’t have the right number ofspaces. So, the actual border is justOffset slightly. I see this all thetime. The next section is visual clarityand ease of reading. As Claude is ableto do more complex work, it's alsowriting larger and larger specs andplans. In practice, I found I tend tonot actually read more than a 100-linemarkdown file, and I'm certainly not ableto get anyone else in my org to read it. But HTML documents are much easier toread. Quad can organize the structurevisually to be ideal to navigate withtabs, illustrations, links, etc. It caneven be mobile responsive so that youcan read it differently based on yourform factor. There's also the ease ofsharing. Markdown files are fairly hardto share since most browsers do notrender them natively well. You oftenhave to add them as attachments toemails or messages. With HTML, as longas you upload the file, for example, toS3, you can share the link easily. Yourcolleagues can open it wherever theywish and easily reference it. I have aFeeling, those examples, do not work wellon mobile. Yeah. So, wherever they want is notnecessarily true, as you see here. So,not everywhere they want. They say itcan be mobile responsive. So, you readit differently based on your formfactor, but the examples that wereshared here weren't. And the more ofthose things you address, the morebloated the HTML gets, and at some pointyou're just burning output tokens. Hedoes also say that the chance of someoneactually reading your spec report or PRwrite-up is much higher if it's in HTML. The idea I have to reconcile here is howmuch of that is because the markdown istoo bloated and the HTML makes it morereadable versus how much of that is thatthe HTML is novel enough that it'seasier to jump on and read becausethere's less things like that thatyou're being handed. Like if everyonewho is spamming us with giant markdownfiles was to switch over to spamming usWith HTML links, how much more of thatwould we be reading? I think it would bebetter, but I don't think it's as muchbetter as it is now. The novelty of HTMLis a big portion of the value right now. The interaction part is really strong,too, though. I will give him that. HTMLcan allow you to interact with thedocument. For example, you might want toask it to add sliders or knobs to adjustthe design or allow you to tweakdifferent options in the algorithm tosee what happens. You can also ask it tolet you copy these changes into a promptto paste back into cloud code. He has abunch of examples of these types ofplaygrounds and two-way interactionsthat he's built. There's also dataingestion. Why use cla code to make HTMLfiles instead of cla or claude design,for example? One of the biggest reasonsis all the context that cla code canget. For example, when writing thisarticle, I ask Claude Code to readthrough my code folder and find all theHTML files that I've generated, groupand categorize them, and then make anHTML file with all the diagramsrepresenting each type. The diagrams yousee in this article are a direct result of that. Besides the file system, cloudcode can find additional context usingyour MCPS like Slack, linear, etc. Yourweb browser with Claude and Chrome, yourgit history, etc. Actually, a valuablepoint here. I have done a lot of thistype of thing where I have like a bunchof data on my computer or in some foldersomewhere, and I just ask an agent to gothrough it and visualize it to makesomething more useful. I've done thismany times. I'm beginning to think that,especially when he mentions the HTMLfiles that he has just scattered acrosshis computer, that something we mightneed here is a better skill thatdescribes the shape of the HTML, tellsit can use Tailwind or whatever, givesit a structure for what directories toleave it in so you don't clog up yourgit history. I'm going to think throughwhat a good skill for this would looklike, and play with that in the future. I'll report back for sure. The nextpoint he has is that it's joyful. MakingHTML documents with Claude is just morefun and it makes me feel more involvedand invested in the creation, and thatitself is enough. Honestly, that's thebiggest point here. If this makes youengage more with the output of youragent so that you get better results andare more involved in the process ofsteering it, there's a lot of valuethere. It's silly to say it that way,but if the thing makes you more excitedto build and focus and iterate, that isgood. It's the same reason I've been infavor of things like Vim. If setting upNeoVim makes you want to code more andbuild more, awesome, do it. I'm all infavor of things that get developersexcited to be more involved in theprocess and to create more things. Thatis always what I push for. So, how doYou get started? I'm a little bit afraid that people will read this article andturn it into a/HTML skill or something. Look, I didn't pre-read. I am going to do this, to be clear, but I'm notgoing to do just SL HTML. I'm going todo something very different here. I haveplans. We'll get to those plans later.Probably not in this video, but makesure you're subbed if you're not. By theway, I'm amazed half y'all still haven'thit that button. If you want to see myfuture HTML skill video, or honestlymore exciting, the video I'm going to dotrying all of Matt Poc's skills,definitely make sure you're subscribedbecause there's a lot of fun content inthe pipeline. While there might be somevalue in a skill like that, I want toemphasize that you don't need to do muchto get Claude to do this. You can justask it to make an HTML file or make anHTML artifact. The trick is knowing what you want the artifact to do and how youmight use it. You may over time make aSkill, but for now, I suggest that youjust prompt from scratch to get the hangof how to use it in different cases. Iabsolutely agree. In general withskills, you should always start byasking the model to do the thing. Seewhat it gets right and wrong. Figure outwhat parts you have to include everytime, what parts you don't, and thenslowly figure out what those are so youcan build a skill to do it right. Andalso, on that same note, one of the bestways to test a skill is to just go copythe text for said skill, paste it intoyour input box, and hit enter and seewhat happens. Like it's the same thing. The first use case he has is for specs,planning, and exploration. HTML is arich canvas for Claude to dive into aproblem. When I start working on aproblem, instead of a simple markdownplan, I expect to make a web of HTMLfiles. For example, I might start withasking Claude code to brainstorm andcreate some explorations of differentOptions. I would then ask it to expandmore into one, maybe make mockups orcode snippets. Finally, when I'm feelinggood, I'll ask it to write animplementation plan. When I have a plan,I'll create a new session and pass inall of those files for it to implement. Notice that he says he'll create a newsession instead of compaction.Definitely not cuz the compaction iskind of garbage in cloud code. Or, to befair, it got really bad at GBD55. I hatethe compaction now, and I used to trustit dearly with 53 and 54. So yeah, I'mstarting more sessions than I ever did. Even a simple thing like I just a fewdays ago did the uh Azure bench thing, avery simple benchmark, just measuringinference speeds on Azure. I did like 30plus threads to make this obviously allin T3 code. I wonder why, but yeah Irealized it's better to just make ashitload of branches and a shitload ofthreads instead of trying to massage anexisting long thread into the shape youWant. I just copy-paste the parts I likeinto a new thread and start fromscratch. But it is cool that the HTMLfiles are a good thing to hand to anagent. I bet you could just take one ofthese HTML files, give it to the agentwith no additional context, and it'llusually figure out what you want. Makessense. Also useful for verification. When he's verifying the results of thework, he'll ask a verification agent toread the HTML files, and it will have amuch broader context on what it actuallyneeds to verify. That's a really usefulpoint. He gives some example promptshere, too. I'm not sure what directionto take the onboarding screen. Generatesix distinctly different approaches,varying layout, tone, and density, andlay them out as a single HTML file in agrid so I can compare them side by side, label each with the trade-offs it’smaking. I like this a lot. Again, havingthe model generate distinctly differentoptions in one pass gets you a muchBetter variety than you might otherwise get. The next example he has is, create a thorough implementation plan in an HTML file. Be sure to make some mockups,show data flows, and add important codesnippets that I might want to review. Make it easy to read and digest. Again,just getting used to prompting the modeland seeing how it responds to these different scenarios. There is no oneguide. And even if there was, as modelupdates happen, things change so fast. You got to just feel it out with thesethings. The next section he has is forcode review and understanding. Codecould be difficult to read in a markdownfile. Eh, if you have a good likemarkdown parser, even one in like VSCode, and I'll just demo this quick.Let's uh check the skillmd file. Okay,cool. This file is a markdown file. It'sactually already quite readable in myopinion. If I make the font bigger, it'seven more so. Watch this. Typescript const x equals sub nerds. Please sub. It does syntax highlightingin code blocks as long as you label itwith the language. If I delete that, itstops. I'm amazed how people don't knowthis. In most markdown parsers, when youdo the triple back tick, you can put thefile extension for the language, and itwill do syntax highlighting for thatlanguage. If you include this in thebrowser via HTML, it now has to figureout how to render the diffs and how torender the code blocks. The process ofit figuring out how to do this, muchless doing it properly, is as if notmore expensive, both mentally for me asthe person consuming it, but more so forthe agent generating this and generatingthe tokens, that this is actually justas good. To each their own, but I don'tnecessarily agree with that piece. Iwill say rendering diffs sucks inmarkdown. Code can be difficult to readin a markdown file. Don't agree there. As I just established with HTML, we canrender diffs, annotations, flowcharts,Modules, etc. I don't really want thesethings in my code snippets that I'mreading outside of like a comment. I dowant diffs, though, so not having diffssucks. Use this to understand code thatthe agent has written to get code reviewor to explain a PR to somebody reviewingyour code. I find this often worksbetter than a default GitHub diff view. And I attach an HTML code explainer toevery PR I make now. Interesting. I seepotential for this part. One of myfavorite things a sponsor builtrecently, and this is not somethingthey're paying me to say. This is just athing I genuinely think is cool. It'sDevon Review. So, if you take github.comand change that to devonreview.com for agiven PR, it will do an analysis of thispull request. But the coolest parts arethat it will actually change the view tobe organized based on the importance andgrouped based on the related changes. Soinstead of it just having all of thefiles in order, it'll create its ownHierarchy where things are. Apparently, I am out of credits on my original compedaccount. I'll have to deal with thatlater. Julius has been abusing all ofthese tools. Clearly, I'm not using itthat much if it's broken right now, butthe couple times I did, I actually foundit really nice, and I'm going to go reupbecause I've enjoyed it a lot. The ideaof changing how we review code to bebetter shaped based on the sheer volumeof code that we're reviewing is a goodidea, and it's one I like because goingthrough all of your code in alphabeticalorder, depending on where it is in yourproject, has always been [ \_\_ ] stupid,and it's more stupid than ever now. Doing this yourself as a developer bytelling the model to generate HTML,summarizing the code, showing thechanges, and making a better hierarchy. That's a good idea. I like this. Theother cool thing is that you can steerthe model towards the parts you want thereviewers to focus on. So, in thisExample prompt he has, he says, "Help mereview this PR by creating an HTMLartifact that describes it. I'm not veryfamiliar with the streaming and backpressure logic, so focus on that. Renderthe actual diff with inline marginannotations, color code findings byseverity, and whatever else might beneeded to convey the concepts. Well, Ilike this idea a lot. Then we have thedesigns and prototypes. Claude's design is based on HTML because HTML is incrediblyexpressive at design. Even if your endsurface isn't HTML, Claude can sketchout a design in HTML and then write itin your language of choice, be it React,Swift, etc. I love that React's alanguage here. Long debate from theolden days of web dev, but React is kindof a language. You can also prototypeinteractions like animations, actions,etc. Consider asking Claude to makesliders, knobs, etc., to tune in exactlywhat you're looking for. Yeah, this is alittle much for a simple checkout. Button, but I I get why you would want to care this much. This section is one of my personal favorites, using this for reports, research, and learning. Cloud Code's incredibly good at synthesizing information across multiple data sources and converting it into a report for readability. You can prompt Claude to search your Slack, your codebase, Git history, the internet, etc., and use it to generate extremely readable reports for yourself, for your leadership, for your team, etc. This is actually a crazy hack for those who are looking for ways to like stand out using AI at your company. Give an agent access to your Jira and ask it to make a nice-looking HTML page over what got done every week and then present that during your standup. Like, give people a resource to look at that makes the leaders feel like they understand what's going on. It's stupid, but this is a really simple way to like look cool to your team and to your leadership. Making them feel moreInformed by running a simple prompt. Really powerful. Yeah, chat's alreadyunderstanding. Wait, I don't think mymanager allows me to use the Jira APIyet, but I can do this. Management willgo crazy over this. Yeah, you guys getthe idea. Always happy to sneak in thesehacks for career growth where I can.There's a lot of fun ones here if youknow where to look. You can assemblethings like this in long-form HTMLdocuments, an interactive explainer, oreven a slideshow or deck. Ask Claude touse SVG for diagrams to help visualizeit. I have not seen these models getsuper good at SVGs just yet, so mightnot have the best luck there, but maybe. Somebody just said that they got CloudCode access at work last week. Thanksfor the idea. Anytime. Yeah, you can dothis without having one of those either.You can spin a pretty simple API callsto DIY this, too. If you're curious howyou would do this without cloud code,maybe watch my video on how harnessesWork. I have a whole dedicated video onhow cloud code works. That's moregeneric. How to get AI to write code anddo real stuff. You can build your ownsolution internally that doesn't requirecloud code that has all of these samepowers. So, definitely worth consideringif you haven't done stuff like that yet. An example that he has here is he made apost on prompt caching. In order to dothat, he asked Claude to prepare anin-depth research file in HTML for himto read on all of their changes toprompt caching after reading the githistory. That's actually really cool. And again, like your prompt doesn'talways need to be honest about who youare. Sometimes it's useful to take adifferent perspective to steer the modelthe right way. Even if you are fullyaware of how the rate limiter works,telling the model that you don'tactually understand it is a reallypowerful way to get it to write andcreate artifacts for an audience thatIsn't it? I find that a lot of devs actuallyget hung up on this. They don't know howto talk to the agent outside of theirown voice. They only know how to tell itwhat they specifically want and know, anddo, not how to move past their ownknowledge to get the model steeredtowards something that isn't for them. It's easy to make an agent create thingsfor yourself. It is a very different wayto think to steer agents to make thingsfor others. And this is a silly butreally good example here. Just saying Idon't understand how a rate limiterworks. Read the relevant code andproduce a single HTML explainer page, adiagram of the token bucket flow, thethree to four key snippets annotated,and a gotcha section at the bottom.Optimize it for someone reading it once.I do this all the time. I would arguealmost half of my prompts are mepretending to be dumber than I am sothat the model will steer in the rightdirection for my users, and then I take. The reins back whenever it goes where Idon't want it. Here's another fun one,and I've actually done this a few timesbefore. Using HTML to create customediting interfaces. Sometimes it's hardto describe what you want purely in atext box. In this case, I'll ask Cloudto build me a throwaway editor for theexact thing that I'm working on. Not aproduct or reusable tool, but a singleHTML file purpose-built for this onepiece of data. Yep. A lot of devs stillaren't over the fact that like code isexpensive, so you only should write itfor reused things. Code is cheap now.Writing a bunch of code just to playaround with some data to make a gooddecision about other code you're writingis absolutely worth it. Of the code Iwrite right now, write obviously inquotes, I would say about 70 plus percentof it immediately gets thrown out afterI run it one time. If even more devs needto internalize this way of thinking,because you can make much better stuff. For your end users, if you build custom tools to get there that are only ever used once and thrown away,the trick here is to always end with an export a copy as JSON or copy as prompt buttonthat turns whatever I did into the UI back into something that I can paste into cloud code.Ready for a silly example of this? When I was trying to waste as much of GitHub's money as possible with my abuse of Copilot, I wanted a good way to visualize that.And, uh yeah, Anthropic makes a really shitty broken site, so I can't show you apparently right now, even though it generated me a nice little web app that I could use inside of Claude to calculate how much money I had spent and then import and export a CSV that just took upwards of a minute and a half to load despite being a single JavaScript file. God, the, I've been so nice this whole video. I will take this brief tangent to emphasize just how terrible the engineering atAnthropic is. It is genuinely [ \_\_ ]hilarious how bad these guys are atcode. That was insultingly bad. It makessense that he only mentions artifactsonce in this article because they're[ \_\_ ] useless and no one should usethem because the actual implementationon the anthropic site is [ \_\_ ]garbage. Which is why I tried it forthis, because I wanted to once again see ifit's made any progress. The answer is it[ \_\_ ] hasn't. The models can make anice little artifact that lets me have this fancy interface for putting invalues. I can import from the table. Ican export the table to this view andvery easily copy-paste the CSV. I madethis so I could quickly blast throughall of the data for all the agent runs Ihad to see how much money I was able towaste of GitHubs. But god damn,Anthropic cannot code for [ \_\_ ]. You getthe idea, though. The creation of a UI toplay with these things and an exportformat that you can paste elsewhere. Be it a state that you want to reuselater or values that you want to pass toyour agent. Very powerful. Thinking inthis way will be beneficial. And that'sreally what I want to like make thisvideo for and push you guys towardsthinking in terms of inputs and outputsbeyond just the flows of your code. Howdo you use new code for one-off problemsthat lets you import and export datathat is valuable to your agents? You canbuild much more effectively as a resultof thinking this way. It hasfundamentally changed how I build what Ibuild and how I manage my team, how Iprocess data, all of these things. Realizing that every time you have adatabase, a CSV, a JSON blob, that'syour data from something that you did,or even just a prompt with some complexvalues in it, generating code to helpsmooth out the edges and give you theinfo you're looking for is supervaluable. He has an FAQ section here,and I'm sure a lot of you guys have theSame questions. The first is the bigquestion. I've seen this a lot. Isn't this less token efficient? I've evenseen people going as far as saying thatThor's only writing this in order to getpeople to waste more tokens to makeanthropic more money. I think thosepeople are dumb. It's a funny joke, butit's not very real. While Markdown doesoften use fewer tokens, I found that theadded expressiveness of HTML and themuch higher likelihood of me reading itmeans that I get overall better outputs. With the 1 million token context windowin Opus 47, the increased token usage isnot really noticeable in the contextwindow. That's a silly point to make. Next, he has when do you use markdownfor now? I've honestly stopped usingmarkdown altogether for almosteverything, but I'm probably far on theHTML maximalist side of things. That's alittle insane to me. Moving out ofMarkdown entirely is crazy. How do youview the HTML files? He doesn't justOpen them in a browser locally. You caneven ask Claude to open it or upload toS3 if you want a sharable link. Fine. There's evidently an opportunity for amicroservice for this, by the way.Wink. What about version control? Thisis honestly one of the biggest downsidesof HTML. HTML diffs are noisy and hardto review when compared to markdown. Howdo I get Claude to match my taste andnot make it all ugly? The front-enddesign plugin helps Claude make goodHTML files, but to match your owncompany's style, you can create a singledesign system HTML file by pointingClaude at your codebase. You then usethat design system file as a referenceto other HTML files.How they didn't call out the skill forthis, but there's a direction herewhere you could make a better primitivethat is still HTML, but lets the agentmake things look better, more portable,have better version control, have betterhosting, better context on what else isGoing on. There are ways to adjust this,but until we move from Claude MD to CLA,this is just an experiment as far as I'm concerned. I do like Thor'sendpoint, which I'll get to in a sec,because I want to remind you guys westill have to read Karpathy's thoughtsas well. So don't skip just because I'mat the end of this. He ends with stay inthe loop. All of the above is to saythat I think the real reason that I useHTML is that I feel much more in theloop with Claude. I'd begun to fear thatbecause I'd stopped reading plans indepth, I would simply have to leave Claude to make its choice. But I'm happyto say instead that I feel more in theloop than ever before when I use HTML. Ihope that you do, too. I'm going to trythis a bunch and report back on how Ifeel. So keep an eye on my channel ifyou want to see that. But Karpathy'salready made the move, and I want to hearwhat he has to say. This works reallywell, by the way. At the end of yourQuery, ask your LM to structure your response as HTML, then view the generated file in your browser. I've also had some success asking the LLM to present its output as slideshows, etc. More generally, in my opinion, audio is the human preferred input to AIs, but vision like images, animations, and video are the preferred output from them.I think I agree. I am always surrounded with my team, so I don't get to use audio as much as others do. And I'm not like Prim. I don't walk around talking to my phone to send texts. I respect the balls he has to do that.The number of times I've been hanging with Prime and he just pulls out his phone and voice-to-text something to his wife or to his kids is adorable, and I respect it.I'm too insecure to do that myself, but there are some people who will just prompt all day, who will speak to their phone to talk to their family, to send prompts, whatever else, and all power to them. Them. Around a third of our brains aremassively parallel processors dedicatedto vision. It's the 10-lane superhighwayof information into the brain. As AIimproves, I think we'll see aprogression that takes advantage ofthat. I totally agree. I think vision ishow people like to process info, andit's really nice to be able to likelisten to music and watch something thatmy computer did at the same time. Textis a little more process-heavy, butyeah, you get the idea. He lists theseexamples of things. Raw text, which is hard and effortful to read. Markdown,which is a bit easier to read once youhave bold, italic, headings, tables, allof those types of things to the currentdefault. Then you have HTML which isstill procedural with the underlyingcode but it's a lot more flexible on thegraphics and layout, even interactivityside early, but it's forming a new gooddefault. And eventually, we get furtherand further, until we have interactiveNeural videos and simulations. Interesting hypothesis he has here wherehe thinks we're going to progress tomore and more visual interactive outputsfor models. Very curious to see wherethis goes. IMO, the extrapolation, though,the technology doesn't exist just yet.It ends in some kind of interactive videosgenerated directly by a diffusion neuralnet. Many open questions as to how exactlyand procedural software 1.0 showartifacts like interactive simulationsmay be woven together with neuralartifacts like diffusion grids, butgenerally, something in this direction ofthe recently viral, uh, what is this thathe's linking? Interesting. Imagine everypixel on your screen streamed livedirectly from a model. No HTML, no layout,engines, no code. Just creating this UIdynamically. Very interesting. There arealso improvements necessary and pending,at the input: audio, nor text, nor video,alone is enough. I feel a need to pointand gesture to things on the screen. Similar to all the things you would do with a person physically next to you and your computer screen. Okay, I cannot tell you guys how often I've done exactly this. I'm going to just show screenshot edit. I use Shotterter. There's lots of other screenshot utilities. I'm going to just highlight this section, copy this, paste it to CodeEx. Cool. What are your thoughts on this paste image? Actually, I can't see the image here because I'm using a terminal. No one should use terminals for these types of things. So I will just hop over here instead. Paste the image. What are your thoughts on this? And now I can actually see the image I just pasted because using Gooies is nice. Shout out T3 code. Fully open source. Works with all of your terminals. This is just a different view for the same thing. Yeah, I can't believe we're all just living with pasting images in a UI where we can't even see them. The amount of cope andLike, copy-pasting is broken too becauseit has to handle all the formatting andthe ter. Why are we still using [ \_\_ ]terminals? Yeah. And here we get a muchbetter formatted output in a UI that ismuch less bad. Something I'm nowthinking about is what would it looklike if in T3 code we asked the HTMLoutput thing similarly and it couldactually output custom UI in body here. I might play with this idea in the nearfuture, but part of T3 code being opensource is that you can go add thisyourself. If you're interested in whatit would look like to let agents respondwith HTML inside of your agent to codingexperience, you have to leave here tosee it. And maybe you can click a sharebutton to send it to somebody else.There you go. Fun opportunity. Play withit. Carpathy closes with the following. The input and output mind meld betweenhumans and AIs is ongoing, and there's alot of work to do and significantprogress to be made way before jumping. All the way into Neural links braincomputer interfaces and all of that. Forwhat's worth exploring at the currentstage, hot tip, try asking for HTML. Wehave a shitload of exploration to do asan industry here still. We are stillfiguring out the output formats thatmake sense. We're not even close tofiguring out the interfaces. The factthat we're still so attached to ourterminals shows how far we are fromgetting this all right. And in a worldwhere we can make better output formatsin better UIs with better control andcustomizability, we can make bettersoftware as a result. That said, HTML isjust the starting point. And whileKarpathy seems to think that thedirection we're going in is interactivevideos and simulations, I think we havesome important steps to go throughfirst. In chat has correctly identified.I think MDX is an untapped market. Allroads lead to React., Stop Letting Your Agents Write Markdown., YouTube, 01krgmzdbshebs8p2nmgycerqg.