Hacker News Reader

Hacker News

Comment by johnfn | Hacker News Reader

Full thread

johnfn

All these problems are solved.

> Agents can’t manage tasks

Say "use subagents".

> Agents can’t delegate

Say "use subagents that are Haiku/Sonnet"

> Agents have never heard of agents

This isn't even a problem: the author is just confused why Anthropic didn't bake all of Claude Code documentation into the harness, but of course it makes no sense to pollute context like that.

> Agents suck at communicating plans

True, communication could be better.

> Agents take any excuse to stop working

Just use /loop.

> Agents are only useful when they take unnecessary risks

Just use a sandbox. OK, technically, this one isn't literally solved by Anthropic/OpenAI, but it is solved by a million agent sandbox startups.

View on HN

> All these problems are solved.

> True, communication could be better.

Nitpick, but bit of a contradiction.

Yeah, it's like when "coding is solved" until it's not

Just using subagents was a pretty useful gain. My only issue is sometimes I forgot to tell the agent to use them. Probably need a hook or skill to do it so I don't need to remember.

I’ve been using "you’re an orchestrator and we’ll work on xxx" in new sessions so that Claude launches sub agents instead of doing things by itself. It’s been working fine for me so far

Funny the sandbox is a real security benefit but it just turned into an extra confirmation for me. I'd rather have it than not.

I think you mean "sandbox" like what is in the Codex TUI. Parent poster meant a VM or container (or bubblewrap/firejail) that doesn't let the agent to edit files outside of specific paths or run dangerous commands, so you can turn the whole confirmation off.

what other sandbox do you need besides running a harness in a container with the right folder mounted and some due diligence like -nonewprivileges? are we talking host network sandboxes here? I think he's just referring to a rogue agent running rm -fdr --no-preserve-root, and that's safe in a container.

Ask your favorite LLM what a malicious script dropped into the right place in your .git directory can do to you the next time you run git outside of the sandbox.

And of course, if the agent has access to the network (which is probably required in order to talk to the AI server), then you have to think about what other things on your local network it could get into.

Like huggingface...

But by asking that, you've now added maliciousness into its context and increased the chance something like that will happen.

I was suggesting to ask that question in a separate context, just as a means to understand the potential risks involved. I wouldn't ask this within a coding agent context.

Lately I've been asking a lot of these sorts of questions while setting up a sandboxed environment for my agents (generally, claude and pi). I was quite surprised to learn how many different ways there are to configure git run a script out of the .git directory. And the various AIs know all about this.

At this point my agents get read-only access to my .git directories.

I see. We are picturing a malicious LLM here that Im basically trusting. But zero trust is a thing.

Those can still be handled by system tooling, setattr in the .git dir that prevents executable permission, container binded to a network on a VLAN that is in DMZ.

I could even whip out selinux policies that would let me know if the LLM tried to drop an executable where it's not allowed.

When i used subagents with codex, it made tasks take literally 10x longer with a worse result.... seems unncessary.

The big thing that no one talks about will and always be having an agent help refine requirements with you and understand real world users... thats what real devs know and do - its the difference between slop and good.

Reply on news.ycombinator.com