> Coding AI is different. By that I mean building features that use an LLM, where much of the programming involves writing prompts to get the output you want.
As soon as you add LLM fuzziness to a codebase, it seems to propagate like a virus. You can’t get anything reliably useful for machines downstream of a prompt—even with structured output & friends there’s always the possibility it’ll be flat-out wrong. Reminds me of the old “function coloring” issue except it’s probabilistic instead of async. Obviously it opens up incredible possibilities but I do miss the days where you could predict exactly what would happen by reading code.
I feel like I am going insane. Who in their right mind would feed an LLM raw HTML in the first place??
HTML is a markup language. User agents present it in a way that makes sense for the user—visually, or through assistive technology. Nothing about adding LLM “users” should change this—their user agent, the harness, should present HTML in a way they can natively understand, by translating it to Markdown.
We are not going to rewrite the entire web because harness developers are too lazy or stupid to pull an HTML to markdown package from npm. If some sites want to do so anyway, good for them, in many cases I’d love to skip the CSS/JS and read the markdown directly (or better, nicely formatted). But don’t blame website authors for your harness wasting your tokens.
Exa also has an API for it that has worked well for me, returning markdown for a URL, which means you don't need to render js or anything yourself. It doesn't need an account for up to 1k requests/month, which is more than I've ever needed.
Agree. I think many people forget that not long ago, HTML markup on many sites was a lot richer than it is today. Making it trivial to produce a good trimmed down markdown version.
The reason it may be more difficult today is because we've lost a lot of that. Some of it because of modern JS frameworks, but some also because publishers simply don't want to make it easy for the useful stuff to be scraped and extracted easily.
I'm not convinced that's changing because of AI agents (it's getting worse in many ways with anti-agent rules). Maybe improving for documentation pages intended for agents. But if it is changing, I think it'd be far easier to improve the HTML and let the agent take care of the rest.
> Who in their right mind would feed an LLM raw HTML in the first place??
I'd even say, is that even a problem ? If your website isn't a front end blob soup and just a relatively clean HTML file, your LLM is totally capable to handle it anyway.
And I'm still wondering myself which incentive do I have to serve my content to LLMs anyway.
There's nothing wrong with "dirty" HTML. Modern layouts require lots of wrapper elements--certainly some sites use them unnecessarily, but it's not reasonable to expect a nice modern layout to use the same number of elements as a basic document. And utility CSS has merits. That's a totally separate concern from inaccessible div soup--you can still use sections, navs, aria- attributes, etc.
If you're working with a marketing team, you'll find that they are desperate to serve their content to LLMs, to counteract the rapidly shrinking number of people actually visiting websites. What I don't want is for that to mean "build the website twice, one for humans and one for LLMs". Websites are for people—bots can adapt.
i have built 2 html to document pipelines and read it back with pdftotext, and I can say that "just convert it yourself" step is the place where things are getting wrong.
For example Markdown has no support for the subscript and superscript in CommonMark or GFM and if you have <sup>4</sup><sub>3</sub> becomes 43 and water formula becomes H2O so in the output you get not the ugly but the wrong one. And no converter can fix it, because that's a target format which can't express it. extractors like Defuddle don't save from this also. and non of those extractors or converter throws you just get wrong text
Might be tolerable if it would have given us fully automated utopia, but instead we get to watch the world burn and know nobody’s gonna do anything about it.
If things keep going this direction my job title is just going to be "tool call".
I'm a bit intrigued that he ended up happier now that Claude's in the driver's seat and he's playing a supporting role. Maybe I'm ngmi but I'm not sure I'd be happier.
This is a cool approach. Definitely better than an all-at-once cutover!
If only Ruby had better support for static typing though. Clearly infinite dynamism works for some folks and a lot of successful businesses, but I couldn't live without a type checker pointing me towards all of the places that need fixing. Kind of forces you to have comprehensive test coverage or you're screwed, which maybe isn't a bad thing.
I’m working on eslint-plugin-solid for this reason, and while I haven’t implemented this yet (it’s complicated), it will eventually warn when something is wrong with reactivity in general.
Nit: to me at least, "Never deal with another freelancer" comes off as unnecessarily harsh (even if it resonates with some). I understand the product is targeted to early-stage startups without the budget to hire someone, but it sounds like it's putting down the idea of working with a designer altogether (see "no need to hire a designer"), when you could poise it as complementary to working with a designer eventually if we choose to do so.
Yeah, that's good feedback. We don't want to put down the idea of working with a designer later in your company. In fact, many of our users have grown their companies and hired designers to extend their brand into their application UI. We'll work on the phrasing.
As soon as you add LLM fuzziness to a codebase, it seems to propagate like a virus. You can’t get anything reliably useful for machines downstream of a prompt—even with structured output & friends there’s always the possibility it’ll be flat-out wrong. Reminds me of the old “function coloring” issue except it’s probabilistic instead of async. Obviously it opens up incredible possibilities but I do miss the days where you could predict exactly what would happen by reading code.