I gave it a shot 4 months ago. 150k GitHub stars, it must be worth trying at least right?!… turned out to be some of the buggiest and clunkiest software I’ve ever used…

The idea of “your own agent instance that you can link to anything” has merit, but it was just so annoying to configure and actually quite expensive when linked to OpenAI (a few dollars a day to do nothing) also seemed to be a never ending stream of happy-baked vibe-coded features being merged… the whole project just gave me the ick

Is "happy-baked" a typo or is that an actual term? If it was an accident, I kind of like it.

That is a typo sorry (half-baked) reminds me of a bakery!

I'm going to think of unreviewed AI written code that the AI swears works, as "happybaked" from now on.

If you have an enterprise contract with them, the legal protections for the consumer is much higher… is what I’ve been told anyway

It isn't, in both cases you're protected by exactly the same legal system

It's also the same planet but finding a commonality somewhere in the chain is not the same thing as finding a lack of difference in the matter.

Same legal system, but an OpenAI enterprise contract is not the same as a ChatGPT pro subscription... The terms of service agreement would be quite different

Not sure what you are saying exactly, but

> the legal protections for the consumer is much higher

You know you give away the right to file class action law suits against Anthropic when you accept their Terms Of Use, right? (at least the Americans ones)

Is that the case with enterprise contracts as well? Can’t imagine any decent procurement / legal team accepting this.

If you have an enterprise contract with them you're still unlikely to ever know that you've been lied to unless some whistleblower at the AI company comes forward and even if you do somehow find out, it's too late. Once they have your data and have trained on it there's no taking it back. At most they'll pay out some tiny settlement that's a fraction of how much money they make in a week and they'll continue to profit from your data forever.

> The difference doesn’t matter until it does, and then it’s infuriating to work out what’s going on.

I love this quote, reminds me how annoying it can be when something isn’t reproducible locally… only in production…

I love this choice. As I began reading, it was immediately clear that it was deliberately written by the author, not AI marketing slop

> They're at 93.91% uptime over the past 90 days, according to https://mrshu.github.io/github-statuses/ , and that doesn't even include today's outage yet.

I don’t love GitHub, but that number is a little misleading… That’s the intersection uptime of all GitHub services, most of which I (and most users) do not care about; code spaces, copilot, packages etc…

When you take out those uptimes, it becomes a lot higher. I’ll admit there seems to be a lot more incidents than usual though…

Good UX abstractions out perform bad ones, which means they endure, are copied, and eventually become the implied standard UX… some examples of this are; the hamburger menu, tiny icons and auto-scroll for streaming text

> Good UX abstractions out perform bad ones

And then get get every precision input being represented by a slider versus text box.

Doesn't necessarily have to be good. Can also propagate and become "standardised" if it's the easiest, most convenient, most well documented way. Eg. Twitter Bootstrap.

Hamburger menu is not a good UX abstraction, that's why the mass usage stage of it was pretty short lived and most people are leaving it for more obvious patterns, like tab bars

Why are tiny icons good abstractions?

I assume they signal what menu item does what, to make it less confusing on different screen sizes.

I.e. Large displays get “icon + label”, whereas small displays just get “icon”

I believe it has to do with the size of the icons rather than placing the icon with a label. The AI trend is towards smaller icons. That being said, the more I look at the pic in the article, the more pleasing the smaller icons look to me. Perhaps we just didn't know any better.

I really hope streamed text doesn’t outperform other design patterns in places where it doesn’t make sense.

I might be an old man yelling at cloud, but for things coming after win98 era this feels demonstrably false in many cases.

So no human in the loop then? Sounds like a recipe for tech debt…

I currently need 4gb of RAM MINIMUM to send an email. AI didn't get us here.

No, but it does learn from where we are. If where we are is debt, debt is where we'll remain.

Sure, but AI is trained on the code that got us here isn't it?

Do you think that we're going to use less RAM with AI produced code?

"Do not use react. Do not use tailwind. We will not deploy on vercel."

and suddenly things work again, it's magic!

React is like 150kb :/

So at that tiny 500kb size I imagine it could be compiled to web assembly, and run entirely in the browser right?

Couldn’t find a link, is that hard to do?

500k memory but not sure about disk.

Should be very doable. I ship a small CNN in a browser extension via onnxruntime-web and the model weights were never the bottleneck, the runtime was. The wasm backend adds a few MB of runtime before your first inference, so a 500kb model with a lean hand-rolled wasm build would actually beat most "tiny" browser ML deployments in total download.

One gotcha if anyone wants this in a Chrome extension: MV3 requires 'wasm-unsafe-eval' in the CSP for any wasm at all, which surprised me the first time a build that worked fine as a web page died silently as an extension.

Yeah, I also found that for ultra low footprint models ORT is a big portion of the total payload, because it contains logic for general ONNX graph operations. In my case I found that ORT alone was 3.4MB over the wire, so I swapped it out for a tiny wasm that was 850x smaller and only contained the operations I needed: https://blog.lukesalamone.com/posts/creating-tiny-semantic-s...

did you skip simd just because the model's tiny? naive conv perf is honestly the only reason i haven't done exactly this for the cnn

Yeah, the model is small enough that inference is already basically instant for my usecase (only 6 transformer layers for the blog search).

> Mainframes survive, but serving a much tinier portion of the market than they used to.

I would argue mainframes rebranded to "cloud" which is ubiquitous and more people interact with this computer than any other type of device... only difference is that it's a browser instead of a terminal

There is constant shifting between client and server computation. I think it is a stretch to call cloud servers “mainframes”. There are still old school mainframes, running JCL, and old school mainframe DB2 and COBOL. That ain’t cloud.