You mean instead of them running the code that they are writing they pretend to run the code and the model shows what it thinks would happen?

I don't like that at all. Actually running the code is the single most effective protection we have against coding mistakes, from both humans and machines.

I think it's absolutely worth the complexity and performance overhead of hooking up a real container environment.

Not to mention you can run a useful code execution container in 100MB of RAM on a single CPU (or slice thereof). Simulating that with an LLM takes at least one GPU and 100GB or more of VRAM.

▲

lvl155 19 hours ago | parent [-]

I understand your point but I basically find myself running all my agents in barebones containers and they’re basically short-run make-or-kill types. And once we ramp up agent counts, possibly into the thousands, that could add up rapidly. Of course, you would run milestone tests on actual container/envs but I think there might be a need for lighter solutions for rapid agent dev runs.

▲

rgo 19 hours ago | parent | next [-]

There are now many solutions, and full-blown startups, under the "swarm", "agent orchestration" and other similar keywords, for spinning agents in the cloud. I'm not sure if that's what you mean, but I totally see most of vibe coding being replaced by powerhouse agents, placed locally or in the cloud, picking up tasks and working them out until its really done.

▲

withinboredom 19 hours ago | parent | prev [-]

You do realize that there is virtually no overhead in running containers, right? That's the entire point of their existence. They're just processes, with specific permissions (to generalize it). Your computer can run thousands of processes without sweating.

▲

lvl155 16 hours ago | parent [-]

> You do realize that there is virtually no overhead in running containers, right? That's the entire point of their existence.

No, I didn’t know running containers used “virtually no overhead.” It appears I can run millions of containers without any resource constraint? Is that some sort of cheat code?

▲

withinboredom 9 hours ago | parent [-]

The only resource constraints are physical. You can run millions of containers, but it is unlikely you have the physical resources to do meaningful work with them.

▲

lvl155 6 hours ago | parent [-]

So now you’re saying there are constraints? You just said there are no limits. You can run infinite containers. Why did you lie about this magic?

	▲	jonfk 2 hours ago \| parent [-]
		What withinboredom meant is that running processes in containers don't add overhead vs simply running them outside of them. That is mostly true because of the way that containers work in linux through cgroups and namespaces, which means that you would only be limited by what your hardware would already be able to run before running the processes in containers.