Clojurians Log v2
ai-skeptics 2026-10-20
they should quote a fake study on the matter saying that it decreases the gainz not like the vibe coders are too used to verifying stuff
I object to the React components!
Yeah, let's keep it functional!
its probably why I started running years ago, no risk of me trying to read or type anything. Just a brain with nothingness, bliss.
That image is exactly how my colleagues look when they see one of my PRs
guardrails work up to a point, they are not code. Something like https://github.com/nolabs-ai/nono is simple to set up, it wraps your harness and you can revoke permissions. For example, you can make it impossible for the LLM to edit a file.
The Hugging Face disaster happened because explicit guardrails were ignored. The deeper cause was that the experimenters did not know AI routinely fails to follow explicit instructions.
Yeah, sure, people that wrote the AI and the harness for years didn't know they failed to follow instructions... and nobody was monitoring what the AI was doing, checking network access, logs, etc. I'm sooooo tired of the lies...
https://lobste.rs/s/h0eate/updates_site_guidelines_ai_llm_tags Communities are getting ……
Not sure what the fuss is about in this particular case. Just from the announcement to me it seems like a reasonable change. Very similar to how we earlier decided not to label any content with any AI involvement with any kind of emoji. With similar reasoning outlined in some of the comments there (just glanced at them, no way I'm reading all that humongous comment chain.)
Ah, I thought your comment was within the scope of the lobsters announcement.
I had vibecoding filtered out there, and I have to say it was nice to have one place where you can go check some technology discussion without being barraged with all the LLM talk, whether pro or contra. I understand some false positives were caught there, but tough shit!? So I guess they'd rather have a dynamic similar to hacker news where 95% percent of the front page is LLM / vibecoding stuff?
It's not about false positives at all. > Other people can't be your punching bags and Lobsters can't be your boxing ring.
re-focus topicality around ensuring that content submitted to the site should, at a minimum, be respectful of a reader's time and intelligence.When I read this, I thought they would try to filter out useless vibe slop even more. I was so wrong lol. In fact, I cannot even follow the logic from this sentence to what comes after? We want to respect the reader's time and intelligence, so we will no longer allow readers to filter out things that they find is a waste of time to them...
@p-himik As one person replied in the comments: > I find it unfortunate that this update portraits people who prefer not to interact with LLM-related content as assholes who want to shame others Those exists, but I'd be willing to bet the majority of people who liked that they could filter out or know in advance something related to vibe coding were not punching on anyone and making comments to that effect.
It also misses users like me, who might want to specifically select for posts that are related to vibe coding sometimes. I think they could have at least expanded the tags, differentiating AI tooling posts, from made with AI projects/features, from AI slop would be nice.
Don't they do offer new tags, and vibecoding has had negative connotation undeniably? Slop is considered as spam.
We are 100% behind people being able to shamelessly relieve themselves in the communal swimming pool. We believe people should not be judged for this and it's perfectly acceptable behaviour. If anything it's progress!
Is what that announcement amounted to. The whole punching bag bit is just a strawman.
End you message with "Discuss." if you don't want to get any edits. This usually works for me. And also add this to the system prompt 😢
It is the classic difference between people who build tools and those who live with them. You would be surprised.
@xifi Just in case - with a caveat, if I understand things correctly. While LLM would be unable to e.g. edit a file, something else might be, and that something else might be callable by the LLM, like a separate MCP server, or something else that the harness does.
I tested on Linux. Child processes are sealed with the same constraints. A client/server architecture allows a bypass, so if the MCP server is not a child of the session, it is not confined and you'd need to apply the same sandbox
Cool, thanks for confirming.
if that's your case there's still solutions, just more involved, like running under a separate non-privileged user, in a VM, in a docker sandbox...
After being bitten with this, I only run anything agentic in a VM
A prompt is not a guardrail to be honest. (a .md file is essentially a prompt, there's nothing special about it, and like any other prompt, it's subject to context rot) There are various deterministic tools that you can use, like permission layers, hooks, etc. You can go as far as hacking on OpenCode to make your own harness as strict and predictable as possible.
Ya, AI is annoying. To follow on some of the recs, a hook that runs a script to reject is best, but isn't always smart enough. You can do a hook that uses another agent with fresh context to assess if an edit is being made. It won't have the context bias from before that you're trying to meet a goal and so on, so less likely to think it should not allow edits if all it has in context is: "No edits are ever allowed under any circumstances". Or wtv circumstance you want.
YoU JuSt NeEd To AdD GuArDrAiLs... Give me a break!
@xifi FWIW: I saw this with Opus (I forget the level, probably high), although it was a few months ago
sure, every model, even the best ones, exhibit failure