joshum97

> 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.

marketers

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 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.

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.

Very nice!

Really fresh approach to site “addons” by just copying in and owning a folder instead of installing a million packages.

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.

This looks a lot better with the F# proposal:

    return cb(predicate) |> negate |> filter;