They’ve been shilling the same statement since GPT-2

Anecdotally the “power users” of AI are the ones who have succumbed to AI psychosis and write blog posts about orchestrating 30 agents to review PRs when one would’ve done just fine.

The actual power users have an API contract and don’t give a shit about whatever subscription shenanigans Claude Max is pulling today

Generalisations and angry language but I almost agree with the underlying message.

New tools, turbulent methods of execution. There's definitely something here in the way of how coding will be done in future but this is still bleeding edge and many people will get nicked.

Uh, no. Definitely not me at all.

The OP “bug report” is a wall of AI slop generated from looking at its own chat transcripts

Do you disagree with any of the data or conclusions?

I must admit, the fact that the writing was well formatted and structured was an instant turn off. I did find it insightful. I would have been more willing to read it if it was one lower case run on line with typos one would expect from a prepubescent child. I am both joking and being serious at the same time. What a world.

Yes

I'm open to hearing, please elaborate

It's only slop if it's wrong or irrelevant.

People file tickets against closed source "black box" systems all the time. You could just as well say: Stop using MS SQL, just use a different tool, it's not that hard.

Equivalent of filing a ticket against the slot machine when you lose more often than expected

Well now you're just being silly and I can't take you seriously.

The only "black box" here is Anthropic. At least an LLM's performance and consistency can be established by statistical methods.

Seems more like a case study in AI psychosis

Indeed, the text feels very LLM-written.

All interactions with the "author" of the "research" in this thread also.

Reading HNN is not interesting anymore if bots are allowed at the party.

They’re the same thing now except that skills can have some frontmatter to allow the agent to execute them automatically.

State in HTML is a horrible mistake. Now everything has to be constantly serialized/deserialized into strings.

It's a bit more nuanced than that. State in Qite is held both in HTML and in JS Component. The html serialization is sort of consequence of changing a field (like when you want to update textarea content, for example). You can completely ignore it or you can also use it for CSS, for example. Another usecase is when user interacts with the pages, changes text in said textarea and it also automatically updates the JS Component field. Finally, there are also flags, which aren't stored in DOM. I'd like to point out this architecture isn't random, it came from building apps and realizing how everything interacts.

If the state can't, or shouldn't, be serialized in the client I question whether that state belongs in the client at all.

I'm sure you could find counterexamples so that isn't a hard line I'm proposing, but it is my opinion that nearly all website or web app built today over uses client state.

Congrats, you described imgui which is basically react

An underappreciated source of bloat is module duplication stemming from code splitting. SPAs have a bad rep because you don't expect to download an entire app just to load one page on the web. You can solve this by code splitting. But if you just naively split your app by route, you'll end up with duplicate copies of every shared module.

Bundlers handle this by automatically creating bundles for shared modules. But if you optimize to avoid all shared modules, you end up with hundreds of tiny files. So most bundlers enforce a minimum size limit. That's probably fine for a small app. But one or more of these things happens:

1. Over time everybody at the company tends to join one giant SPA because it's the easiest way to add a new page. 2. Code splitting works so well you decide to go ham and code split all of the things - modals, below-the-fold content, tracking scripts, etc.

Now you'll run into situations where 20 different unrelated bundles happen to share a single module, but that module is too small for the bundler to split out, and so you end up downloading it N times.

fwiw the “tax” in Japan is not paid by the individual, and generally taxing the behavior via e.g sugar taxes rather than the outcome has worked better without much public outcry after the fact

Not sure that would play the same in US though.

Black population in the US is still concentrated in neighborhoods formed by overt racism and segregation and same neighborhoods tend to be food desert where no healthy or even fresh options exists. Even if we taxed just the bad food, the lack of options and mobility that higher income might provide, basically means it’s something that would be seen as targeted. Not to mention, people will draw the most racist perception no matter how carefully you crafted the tax because race relations are always unfortunately weak and these correlations are being forced/drawn.