Treat your coding agents like developers
finbarr.site
Treat your coding agents like developers
1–10 of 18 posts
Re: Treat your coding agents like developers
#2Author here. Three months ago I posted a Show HN for yolobox [1] - a sandbox for running AI coding agents without them being able to nuke your home directory.
Since then I've been using it almost every day, which eventually meant wanting more than one agent running against the same project at the same time. This post is what I learned trying to make that work without it being a constant disaster.
The short version: git worktrees are the right Git abstraction and the wrong abstraction for this problem. The unit you want to fork is the developer, not the branch - full folder copy, its own Compose project, its own URL. yolobox now ships a fork subcommand that does this.
Happy to answer questions.
Re: Treat your coding agents like developers
#3This is great stuff, walking the reader through your thought process was helpful for me as a developer to grok why yolobox was designed this way. I ended up landing in the "just make a local copy, don't get fancy" world myself after many iterations of workflows. Separate agents, separate containers, separate ports, that all resonates.
You mention this approach gobbling up a bunch of extra disk space as a consequence of the tradeoffs. Have you considered using APFS cloning on macOS to reduce some of that burden, or is that too tiny of an optimization to be worth it at this point?
Re: Treat your coding agents like developers
#4This is great stuff, walking the reader through your thought process was helpful for me as a developer to grok why yolobox was designed this way. I ended up landing in the "just make a local copy, don't get fancy" world myself after many iterations of workflows. Separate agents, separate containers, separate ports, that all resonates. You mention this approach gobbling up a bunch of extra disk space as a consequence…
Hard drives are cheap and I haven't approached the limit yet. So I left this as a future optimization.
Re: Treat your coding agents like developers
#5I think I'd go a slightly different route, if I was trying to do this, and that would be to give each agent at least a VM. Not to mention an email account, so that they can coordinate/collaborate with the other "developers" ...
In the end, I firmly believe that agents need a lot more guidance in terms of direction than what a lot of people seem to be giving. Let alone code reviews.
Re: Treat your coding agents like developers
#6I think I'd go a slightly different route, if I was trying to do this, and that would be to give each agent at least a VM. Not to mention an email account, so that they can coordinate/collaborate with the other "developers" ... In the end, I firmly believe that agents need a lot more guidance in terms of direction than what a lot of people seem to be giving. Let alone code reviews.
VMs bring greater isolation but they're a lot heavier and slower. The agents just use github for synchronization here, though I've been considering building some kind of todo list overlay locally.
Re: Treat your coding agents like developers
#7I think I'd go a slightly different route, if I was trying to do this, and that would be to give each agent at least a VM. Not to mention an email account, so that they can coordinate/collaborate with the other "developers" ... In the end, I firmly believe that agents need a lot more guidance in terms of direction than what a lot of people seem to be giving. Let alone code reviews.
VMs bring greater isolation but they're a lot heavier and slower. The agents just use github for synchronization here, though I've been considering building some kind of todo list overlay locally.
Yes... but with full VMs, you can integrate docker (compose) into the application workflows without risking conflicts between separate agents on the same system/vm.
Re: Treat your coding agents like developers
#8Earlier quoted context omitted.
VMs bring greater isolation but they're a lot heavier and slower. The agents just use github for synchronization here, though I've been considering building some kind of todo list overlay locally.
Yes... but with full VMs, you can integrate docker (compose) into the application workflows without risking conflicts between separate agents on the same system/vm.
Did you read the post? That's exactly the problem I just solved.
Re: Treat your coding agents like developers
#9Earlier quoted context omitted.
Yes... but with full VMs, you can integrate docker (compose) into the application workflows without risking conflicts between separate agents on the same system/vm.
Did you read the post? That's exactly the problem I just solved.
That's the part of your post I have trouble understanding. That you need to work around colliding ports suggests that the containers spun up by the agent run directly on the host, not inside some form of nested containerization. But if you do that, how do you ensure that the application running in those containers is sandboxed just as strictly as the agent itself?
Re: Treat your coding agents like developers
#10This is great stuff, walking the reader through your thought process was helpful for me as a developer to grok why yolobox was designed this way. I ended up landing in the "just make a local copy, don't get fancy" world myself after many iterations of workflows. Separate agents, separate containers, separate ports, that all resonates. You mention this approach gobbling up a bunch of extra disk space as a consequence…
Hard drives are cheap and I haven't approached the limit yet. So I left this as a future optimization.
I'd try a modern file system with de-duplication/copy-on-write support. `cp` creates reflinks automatically if the file-system supports copy-on-write.
> Support for reflinks is indicated using the remap_file_range operation, which is currently (6.18) supported by bcachefs, Btrfs, CIFS, NFS 4.2, OCFS2, overlayfs, and XFS. Some external file systems support them too, including bcachefs and OpenZFS.
https://unix.stackexchange.com/questions/631237/in-linux-whi...