Comment by theturtletalks
1 day ago
Claude Code accelerated this divide. Programmers using Claude Code realized that giving LLMs access to a terminal made them feel 100 times smarter. Access to Bash, CLIs, and the ability to visit websites without the many restrictions made them powerful.
Meanwhile, the average user was still using ChatGPT, which probably felt like it had plateaued over the last few releases. The real power of these models became apparent when paired with a terminal. Agents like Muse and OpenClaw are now attempting to bring that same Claude Code-like power to everyday users through a simple chat UI.
for a lot of things ChatGPT has 100% plateaued, especially if you are just using it as a "better Google" search engine. ChatGPT still makes mistakes, makes things up occasionally, etc. that's the whole jagged frontier thing. what recent LLMs have truly achieved breakthrough in are fields that have results that are relatively cheap to verify, such as maths, coding, etc. so people outside of these fields will have disconnects with where LLMs really are right now.
also very important to note that the massive increase in capability in these fields doesn't necessarily immediately translate to increase in productivity. because the code and math proofs these LLMs write are legit _alien_ to us. if you just want code that do something (e.g. a port of Bloodborne that runs on PC), then they can do it. but if you want something human can understand and maintain, that's going to be a nightmare. and that'll surely slow down adoption.
A terminal also tells the model when it failed. Exit code, stderr, a stack trace. it reads that and tries again.
The apps normal people use mostly don't. I spent two years building agents that worked inside people's gmail and calendar, and the failures that hurt all came back as 200 OK. - Slack puts {"ok": false} inside a 200. - Google ignores query params it doesn't recognise, so i sent max_results instead of maxResults for weeks and every filter was silently dropped.
The agent says "done", the user finds out later, and they stop trusting it. So i think part of the gap is that agents look a lot dumber when nothing tells them they got it wrong.
Hmm, that's poor API design. If the big companies can't standardize their inputs and responses, then the small projects aren't going to either. Sounds like there are lots of small issues like this that will roadblock AI-powered automation for some time.
At this point I'd expect SOTA LLMs to have this in training data: most external APIs are protein-agent-made slop, you can't trust them to obey any reasonable standard, so you have to learn to spot failures in responses on your own.
I wonder if in response to this companies like google will build a sort of agent facing layer to the app in question. So rather than you building an agent to attempt to wrangle pupeteer to click css elements as a user does, it calls some apis google exposes to certified gemini user agents and these contain exit codes and can be run as script like instructions not e.g. the shortcomings of browser agent based methods such as having to wait for all content elements to actually load and the obfuscation arms race some devs have towards exposing these elements towards headless agents.
Google already did this https://webmcp.dev/
[flagged]
> Slack puts {"ok": false} inside a 200.
I found out due to a live bug that Apache strips out the response body for 5xx HTTP codes for security, and it's not configurable, so you can't use any of those if you want to return the error message to the user. Don't know what else might do the same, so nowadays I only use HTTP error codes for protocol-level issues, and application-level issues all go into a 200 OK with JSON just like that.
Do you mean Apache APISIX, https://github.com/apache/apisix/issues/13501? That sounds like a simple bug which existed for a short time and has been fixed. For Apache HTTP Server (what people mean by “Apache” in such a context), what you describe is thoroughly unbelievable.
4xx errors are for when the client did something wrong and needs to know about it. 5xx errors are for when the server is having problems and the only people who can do anything about it are the operators, who should be looking for errors in the logs rather than the HTTP client.
Truly "application level" issues are therefore correct as 200, although some application communication issues lead to 4xx errors that should be handled as such. But the case of an application trying to communicate via 5xx errors should never have been the case anyway.
1 reply →
I worked in environment where every HTTP 500 error was replaced by some middle ware by user "friendly" error page, and that included REST calls between services. That HTML also included one huge header image(as base64), so my logs were flooded by that junk response.
We run into that a lot using Mulesoft. 3 layer APIs, and each layer will discard error messages returned by the underlying layers unless we do tedious custom error handling. Makes it impossible for the teams using our integrations to know what they're doing wrong.