upvote
I actually think there is a second level to this. Yes HTML will get you most anywhere, but I found that letting the LLM define its own language is also unreasonably effective.

Currently working on a dumb little mobile game with isometric view and sound:

- told codex to write a tool that lets its place blocks in a prepared three.js document and have chromium dev tools take a screenshot. It made up a little JSON structure that defines blocks / colors and some other effects and it outputs 2.5d tilesets.

- told it to create a uv python script that would let it define sounds and music, and it made a yaml format that lets it create noises.

We completely shot past the svg pelican test. Codex has created both perfectly adequate prototype art of soldiers/knights/priests as well as a prototype soundtrack.

reply
I’ve started using HTML for reports recently. But I always use a markdown file as an intermediate and tell the LLM to generate a fancier version of it with SVG for graphs/pictures based on tables in the markdown.
reply
We have been authoring HTML by hand for decades with ease. Text editors are very good at it, and many have commands to auto-wrap, auto-close etc. Reading and writing is simple.
reply
Templated though, not manually writing it out for every blog post say. I think GP means it just has more friction as a writing format than markdown for example.
reply
Oh my sweet summer child…
reply
No, literally manually typing out HTML tags and everything. Many of us did it so much things like Emmet (https://emmet.io/) were invented and used so we could hammer out full HTML documents even faster.

Even after React became popular, people are still manually typing out HTML elements, although they call it "JSX" instead, but in reality it's just HTML.

My first blog on the internet literally was a bunch of .html files, where my post "template" was the first post copy-pasted when you wanted to make a new post. Changing the design involved changing the same thing across all files.

reply
You have been authoring HTML by hand for decades. Not every SWE is a FE dev.
reply
Java engineers write lots of HTML in java docs:)
reply
Yes so far, but it‘s switching heavily towards Markdown.
reply
People have been authoring html by hand for a long time before the specialization to Frontend dev even existed...
reply
Most front end devs can’t get HTML right either.
reply
Modern JS/TS devs probably not, but I wouldn't even call someone a "frontend dev" if you don't know HTML, kind of being a infrastructure engineer and not knowing how any OSes work.
reply
>We have been authoring HTML by hand for decades with ease

No, we've been generating it with templates or authoring templates.

Authoring HTML by hand is a very early 2000s thing to do.

reply
After you a FE webdev that doesn't regularly author HTML by hand?
reply
Hand on heart. When was the last time you built a serious production system for a real business that was 100% built from HTML without using any build step? Just editing the footer and header in every file when it updates (or using iframes)
reply
I suppose that only applies if you constrain yourself to a raw teletypewriter emulator… in any proper coding environment, editing HTML should be absolutely simple - even an embedded WYSIWYG editor would be an option if rich model output is a way we head into.
reply
A counter argument would be that all programming languages of the last decades have been plain text based. No other more structured format has ever gained traction even though modern editors could be argued to be able to support that easily. Turns out, it doesn't actually work that way.
reply
HTML is plain text based at the same level as any programming language I can think of.
reply
But we’re not even dealing with a programming language in any classical sense here. Interacting with an LLM coding system is a multi-mode communication system with on-demand, purpose-generated ephemeral UI. That doesn’t fit any of the established categories, so I think carrying over constraints from them doesn’t make sense either.
reply
Most people edit documents in Microsoft word, though, so it didn’t seem too far fetched that LLM content would be edited similarly, especially as more and more non-programmers use it.
reply
MS Word uses HTML under the hood, right? (Or some SGML at least.)
reply
It highlights the extremes the anthropic team adopts LLMs in their workflow.

I think most of us live somewhere in the middle, using the right tool / output for the job.

reply
Is HTML really that much worse to edit than MD?
reply
Markdown is essentially just syntactic sugar for HTML[0], so yes it was made to be easier to edit than HTML.

[0]: https://spec.commonmark.org/0.31.2/#html-blocks

reply
It’s a bit easier yeah but there’s not much in it.
reply
Let’s see…

    *No!*

    I mean, <b>yes!</b>

It depends what we mean I guess, isn’t Markdown supposed to allow [hx]ml tags anyway if user need them? Then it’s more about asking the LLM to generate Markdown with this in consideration, and privilege rendering the output of reports in the preferred browser after relevant rendering.
reply
1. I believe many applications that use markdown allow html. Others don't due to security/rendering issues.

2. One of the limiting factors of LLM is context. An html table takes up way more tokens than a markdown table. Especially if it's a WYSIWYG editor that has all kinds of css and <span> tags just for fun.

reply
Yes that’s the case. And as Anthropic staff, author has an incentive to promote workflows that require an agent to interact with text documents.
reply
I've yet to see Anthropic promote any sort of token optimization strategy to its users - they always assume we all have infinite inference.

"No bread? Let them eat cake!"

reply
Not sure how you use CC, but the last 6 months has felt like significant optimization efforts to me. Last year Claude would just read and edit files, now it's all kinds of basic tool gymnastics with grep/awk/sed/etc to narrowly slice and avoid token-heavy reads. Resuming sessions that aren't even that large get a scary prompt about using a significant portion of your token budget if you continue without compacting.

To me it feels like a worse experience, and they probably feel it too, but it makes sense from an optimization perspective. I've probably learned some shell tricks, but also going blind from watching Claude try dozens of variations of some multi-line chained and piped wall of bash nightmare, instead of just reading a few files.

reply
Valid points, but they address a totally different matter than the one I pointed out.
reply
I completely agree but hadn’t found a way to put it to words. It could be the model too trained on optimized strategies
reply
I've noticed that's changed over the past month or so. Claude-code used to happily pipe build commands straight into context, but recently it's been running them as background tasks that pipe to file, and it'll search and do partial reads on the output instead.

It also gives tips on reducing context size when you run /context .

Presumably they are actually starting to feel the pinch on inference costs themselves with what still feels like a fairly generous max plan.

reply
And it seems to use head, tail etc. more than it used to, even when unnecessary, which, combined with the recent(?) tendency of more chaining and as you said, piping to temp files and the like, totally screwed up claude code’s auto approval system for me (by auto approval I mean the system to decide which commands can be run without permission prompt, based on the permissions.allow setting among other things, not to be confused with a specific new approval mode called “auto” that burns more tokens to decide whether the command is safe). I had to write my own auto approval system and plug it in as a hook.
reply
Nah they do. They push Sonnet pretty hard rather than Opus for most tasks.

Also: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

reply
HTML is super human readable if you stick to a subset of it.

It's arguable even more readable.

<b>bold</b> <i>italic</i> <u>underline</u>

I can never remember how many stars and ticks correspond to what in markdown.

reply
Makes sense for actual devs. For non-devs who'd just edit docs via LLMs anyway (myself), I can't imagine it'd introduce much friction.
reply
Yes, and you can always embed HTML in Markdown for <script>, <style>, <svg>, and other tags that cannot be coded in Markdown.
reply
[flagged]
reply
[dead]
reply