Right.. Countless times I see people struggle with something then complain about the fact that nobody wrote anything down ahead to hand hold them through the problem. As if the old experts would've known to write that. And often times they did write stuff, but it either wasn't read or it ran into this issue of instruction being incapable of transmitting everything you actually need.
I agree with you and follow the same principles myself, but JavaScript already has HTTP, and yet everyone still uses Axios. So the problem isn't that JS doesn't have batteries, it's that people don't want to use them for some reason.
I'm guessing it's similar to the tragedy of the commons phenomenon. When things are freely available people tend to overuse or carelessly use them. NPM is just too easy to use. If a package offers a 1% ergonomics increase over a builtin function, many folks will just go for it because it costs them nothing (well, it seems to cost them nothing).
This seems more like a KDE thing then a Wayland thing. At least for me on GNOME Wayland is strictly better. And the newer Wayland-only desktops like Niri are arguably better then that.
This is the first time I've seen MCP's push capabilities come in handy. I'm not much of an MCP nerd though so I don't know much. But when I read the spec it looked extremely over engineered partly because of the 2 way nature of it.
Unfortunately, we're all stuck moving at the speed of the model labs because of the subscription models that they've provided.
The rest of us were able to implement things like push a long time ago, but because Claude Code and Codex stubbed those things out, we couldn't really use them for 'most agent users'.
In fairness to OpenAI, they have been generous in allowing for example OpenCode to sign in with your ChatGPT subscription – so you _could_ build a more powerful agent (which OpenCode is... not) – but unfortunately GPTs' instruction following just isn't up to snuff yet. Hopefully they pre-train something amazing this year!
I think it's an old stereotype. When Rust started gaining popularity, I did see comments like that. Even felt compelled to post them sometimes. But now that we have real production Rust experience, we're a bit more nuanced in our views.
I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.
You might also have success asking your agent to run `eslint` at the end of every subtask and instruct it to always address lint errors, even if they are preexisting. I agree with your diagnosis; there's "implicit prompting" in Rust being more strongly typed and the agent "knowing" that going in but we can compensate with explicit prompting. (You do also have to tell it to actually fix the lints, I find, or it will conclude they aren't relevant.)
I'll add that agents (CC/Codex) very often screw up escaping/quoting with their bash scripts and waste tokens figuring out what happened. It's worse when it's a script they save and re use because it's often a code injection vulnerability.
I want them to be better at it, but given how hard it is for me as a human to get it right (which is to say, I get it wrong a lot, especially handling new lines in filenames, or filenames that start with --) I find it hard to fault them too much.
I agree with a lot of the siblings that it's probably not the same people. But for the overlap that probably does exists, I don't think "because it's AI" is their reasoning. If I were to guess, I'd say it's something closer to "exploring the potential of this new thing is worth the risk to me".
reply