> Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command with the dangerouslyDisableSandbox parameter.
The ability for the agent itself to decide to disable the sandbox seems like a flaw. But do I understand correctly that this would cause a pause to ask for the user's approval?
I agree, and by all accounts the success of coding agents is due to code being amenable to very fast feedback (tests, screenshots) so you can immediately detect bad code.
That's in terms of functionality, not necessarily quality though. But linters can provide some quick feedback on that in limited ways.
> we as customers are better off because things we want are cheaper
Why privilege that side of the equation over "we as workers"? Being a customer isn't all there is to life. I happen to spend quite a bit more time working than shopping.
It's not a matter of "privilege". It's simple economics: if the same functionality can be provided more cheaply, that's a gain to everyone. The gain to customers is the most obvious gain, and it's what I focused on in my previous post--but it's also a gain to producers, because it frees up resources to produce other things of value. But the producers have to be willing to change how they make use of resources in order to take advantage of those opportunities.
> I happen to spend quite a bit more time working than shopping.
Then you should be a lot more worried about AI providing the same functionality you were providing as a coder, but more cheaply--because that makes you, or at least you as a coder providing that functionality, a commodity that's no longer worth its cost. So if you want to avoid being commoditized and treated like cattle, you have to change what you produce to something that AI can't do more cheaply than you can.
There are a lot of "probably"s in the article. I was also suspicious that the author didn't say they did any pre measurement runs of the code to ensure that it was warmed up first. Nor did they e.g. use V8 arguments with Node (like --trace-opt) to check what was actually happening.
Thanks for the link, looks promising, even if "no separate extensions" under Known Limitations for the initial release is perhaps a little unfortunate.
Shout out to Vivaldi, which renders RSS feeds with a nice default "card per post" style. Not to mention that it also has a feed reader built in as well.
Isn't ironic that browsers do like 10,000 things nowadays, but Vivaldi (successor to Opera) is the only one that does the handful of things users actually want?
I don't use it myself because my computer is too slow (I think they built it in node.js or something). But it makes me happy that someone is carrying the torch forward...
To me it sounds like one way to do this would be to have LLMs write Cucumber test cases. Those are high level, natural language tests which could be run in a browser.
This is interesting, and I think worth trying. However,
The process is iterative:
Vibe code users <--> Vibe code software
Step by step, you get closer to truly understanding your users
Do not fool yourself. This is not "truly" "understanding" your "users". This is a model which may be very useful, but should not be mistaken for your users themselves.
Nothing beats feedback from humans, and there's no way around the painstaking effort of customer development to understand how to satisfy their needs using software.
I agree. I do like the general idea as an exploration.
Perhaps the idea is to use an LLM to emulate users such that some user-based problems can be detected early.
It is very frustrating to ship a product and have a product show stopper right out of the gate that was missed by everyone on the team. It is also sometimes difficult to get accurate feedback from an early user group.
https://code.claude.com/docs/en/sandboxing#sandboxing
> Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command with the dangerouslyDisableSandbox parameter.
The ability for the agent itself to decide to disable the sandbox seems like a flaw. But do I understand correctly that this would cause a pause to ask for the user's approval?
reply