I read the first two paragraphs and the post presumably criticising folks for using AI is so clearly written by AI. It's got all the tell tail claude-isms in it.

Analogies about 'students and exams' that don't quite fit. The sentences ending in artificially punchy short phrases. The 'correction' and dash-as-reveal in "they can't answer it - no one can".

It's not good, or a compelling read, and I think it's lazy not to have swept through and fixed these things.

Still cost more than you paid for it eh.

26 years of startups and no one has made a way to pay $0.01 for an article.

It's advertising. People should be paying us to read it.

I'm really put of reading ai-isms like "It quits working around the fourth time, and the average hides who it worked for"

This is classic Claude, and makes me think the author didn't read, edit, or invest in their own words.

Hard to open with something that is not defensive here. Let me first thank you for your attention. Call me naive but I had no hope that I could get any audience for this blog. I started this on the side at a very busy time of my life and thought AI could write catchier posts. I had given detailed instructions on the sections or outlines and what to cover, style etc, but ultimately, THIS LINE MATTERS MOST "makes me think the author didn't read, edit, or invest in their own words." And from now on, I have decided, if I ever write a post it will entirely be written by me - however, flawed, however less worthy of eyeballs. So, I rewrote the entire post in place to actually articulate what I wanted to with this idea- feel free to run substack's native AI detection on it :D.

What surprised me is that this post got much over 1k views. It actually made me believe that I can actually have an audience that I can learn from, connect with. Thanks for opening my eyes and many thanks to hackernews for bringing so many people together. I have many ideas to explore in this moment that we share as humans where we can ask these intelligent machines to execute (hopefully) our will and would love to go in this journey together. I request you to help me grow thanks for your love.

The author's AI applied a thin layer of varnish to what is more or less handwaving. I think more people need to take an undergraduate level statistics course; the conclusions made are completely unsupported by the random trials.

Weighing six rocks a hundred times doesn't tell you the average weight of a mountain.

Great criticism. I should have examined the numbers and the experimental setup more closely before publishing. The signal is there - repetition does help but the exact quantitative conclusions are erroneous in this post.

That aside, I like the way it's put - "Weighing six rocks a hundred times doesn't tell you the average weight of a mountain".

No offense nkhola, but even this comment feels entirely like a chatbot response.

ROFL, is it because they all say "you're right" or something like that - lol maybe I am influenced by them, I need to really think hard about how I phrase things when I type a response in a hurry. I genuinely wanted to just thank the guy. As an aside, not sure if you are following this thread still, but I reworked the experiment and rewrote the post - this time it is all me :D.

First of all, thanks for your criticism again, nateb2022. It woke me up. I tried to run a few more tasks and not make any grand claims this time. Actually there is no golden number of repetitions that I can suggest. In fact, the picture is rather noisy. What does happen is that the median task improves in compliance pretty fast after 2 repetitions. I did a sign test and I rewrote the entire post in place. It also gives you due credit and I borrowed the "Weighing mountains" phrase for a section header. I am incredibly thankful to you for being a careful reader. I am super humbled and would love to connect with you. Perhaps I can count on you for future discussions and posts.

The original Typescript version of the AI SDK has two parts. A backend part called Vercel AI-SDK, and a frontend part called AI UI SDK.

When you make an LLM call, if you use the streaming responses (typical of token streaming into applications) then the response from the LLM provider comes in a specific format; mostly made up of individual json events, one for each text-delta or token generated, and some framing around start/stop. That API format differs across different LLM providers, and also isn't that convenient to process for what you actually want to show in the client/browser.

The backend portion of these sdks (AI-SDK) are an abstraction over the LLM provider, and re-write the 'events' that you get back from the LLM provider into an abstracted json format that's a little bit easier to work with. And not coupled to a specific provider.

The frontend portion of these SDKs (AI UI SDK) helps you to render those message into a frontend interface, and uses the same abstracted format that the backend uses.

There's one big missing piece though, and that's the fact that the transport between frontend and backend is over a single HTTP+SSE stream. If that connection fails, all the work that the backend is doing cannot be transported to the frontend anymore. The HTTP connection also doesn't allow for useful features like cancellation, steering, interruption, and multiple devices.

If you want those, checkout Ably AI Transport, which targeting the _transport_ section between backend and frontend, to make sure you get reliable experiences in the UI regardless of which AI provider or SDKs you use.

Disclaimer, I work for ably on this product:

https://ably.com/docs/ai-transport

This is a backend written in go that's wire-protocol compatible with the (catchy named) Vercel AI UI SDK; which is an SDK for helping to build AI chat apps. The original Vercel AI SDK backend is in typescript.

I think they really missed the opportunity to add in resumable streaming after a dropped SSE connection, or multi-device support. Because these SDKs are easy to drop-in to your applications, but hard once you actually try and build resilient systems on top of them. Systems that can heal from dropped connections, or support multiple users or multiple devices.

ADK seems like a better thought through SDK family, I use Go, Py is most mature, also TS and Java. The docs still need a lot of work to cover all the languages, it's pretty hit or miss right now, but one can also have a coding agent look at the source and an example for another language. Notably to your complaint, I have a coding agent that if the client drops, the llm/agent keeps working in the background. This requires it being set up as a server, which implies tool calls happen there instead of where the client is. I used Dagger as the "sandbox" more for easy time traveling / forking than being a sandbox. The well designed interfaces that allow custom implementations are what hooked me on ADK.

https://adk.dev/get-started/about/ | https://github.com/google/adk-go

Agreed, ADK is really well designed. We’ve used it as the harness for our main product since about January and it’s been solid.

Instead of writing a Go converter to use it with AI SDK Elements, we added this client side and use ADKs SSE streaming and recovery out of the box.

Yeah, with only minimal guidance it's what you get out of claude. The colours and layout are pretty 'default'.

So, I do understand people using LLMs to do websites, they want to communicate some idea, and "typing HTML" isn't part of that, fine, use the LLM to slop it together, whatever.

But don't people review these things before they make it public? The website is borderline unreadable, how does this happen? Am I wrong for assuming people generate a website, review it and then deploy it? Do they only review the source, generate a website, asks Claude to review it, Claude says "Looks good" and the author just goes with it?

I'm struggling to understand why so many of the websites are so unreadable, when it's so easy to spot and fix these issues, it's like people are lazymaxxing nowadays, and not even in the fun "I'm a good developer because I'm lazy", just people being lazy-lazy.

How do you know?

There's a lazy habit from some folks to say something they either disagree with or don't understand was "written by AI" without backing up that statement.

"You're absolutely right to question that.

Let me restate that correctly. Just facts. No fluff."

I don’t think it’s AI. AI would at least keep the article body consistent with the title even if it had to bend over backward and hallucinate new facts.

That would maybe be true, if AI wrote both the title and the body of the article.

In human practice, some hack usually writes the body, but the editor decides the title. And that can happen after the article is written or before.

I don't think they would change that workflow, even if the writer, or both writer and editor, were replaced with a AI.

So yours was a good observation, but it's rather weak evidence.

It's becoming the modern adult equivalent of the old kids saying:

" I know you are but what AmI ? "

That's because most of the LLM output is associated with low effort spam, and they are not wrong. You keep fighting for LLM rights, lol.

^ this comment was written by an llm.

See the problem?

People usually make the determination by reading at least part of the text and then find multiple smoking guns / llm-isms

The comment you responded to did not have those.

Fwiw, the article we're commenting on was likely not LLM written. The sentence structure is too convoluted, no LLM would've generated it like that - unless very carefully prompted ... But at that point it's no longer pure AI slop (imo).

I'll start downvoting all posts that are about criticizing something solely because it was "made by AI". Humans using AI can make great things.

If the article is bad, just say "this is a bad article without coherent arguments" or something like that.

The industry decided a long time ago that sticky sessions was a terrible idea. They only half-solve the problem, while suffering from session loss on server loss and imbalanced load over time.

The services, I ran didn't care about decisions "the industry" made. They worked just fine.

And once those long running jobs have reported their status back to the database, how will the client find out about that status?

Please, please, please don't say "polling". Because you've clearly missed the entire argument of the article if you say polling.

postgresql has LISTEN and NOTIFY. redis and kafka have pubsub. this is a solved problem

Isn't the point that you no longer have a connection to the client?

So you can be notified by the database, but you can't (with the stateless HTTP + loadbalancer design explained in the article) get that notification back to the client. Because the client isn't connected anymore; so how does the client know that there's new information?

*I guess there would have to be some mechanism for the database to push notifications to the client. This is not a fundamentally unsolvable or particularly interesting problem.*

would be nice to see an example linked

here https://share.agx.computer/KQM8fX9g

Folks will probably say, 'I just use cmux, or tmux, or tabs, or warp'. But I do appreciate it when the original project makes an attempt to solve the problem.