4 ms·

Could someone explain to me what the general workflow is now that people are converging to? I haven't really been catching up with the AI ecosystem but I was lo

Could someone explain to me what the general workflow is now that people are converging to? I haven't really been catching up with the AI ecosystem but I was looking into agent sandboxes and VM's recently and there's a ton of these startups and tools now. Is giving the agent a temporary scratchbox really that valuable? I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free (with my dotfiles setup script making dev env pretty much free, though I could also just make a VM snapshot). What's wrong with that? Is that not the scalable solution for enterprise rn?

agentdev001 12d ago
"Is giving the agent a temporary scratchbox really that valuable?" Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.
maxgashkov 12d ago
Compared to enterprise yours is missing egress control and secrets management, if you make the isolation watertight you cripple the agent's performance, and then the careful game of whack-a-mole begins when you stand up local package mirrors, authentication brokers etc. etc.
- kstenerud 11d ago
  I was expecting whack-a-mole as well when designing my sandbox software, but mostly it didn't happen. As a test, I built a sandbox with only the host-side filtering proxy allowed for networking. 99% of traffic was HTTP. No QUIC at all. npm, pip, apt, go, curl and git-over-HTTPS all worked on the standard proxy environment variables alone. No mirrors or other coaxing needed. DNS is disallowed through the chokepoint, but that's no problem because the proxy resolves host-side anyway.
briga 12d ago
I don't think there is really any convergence going on. The agentic ecosystem is continuing to multiply on a daily basis and everyone and their grandma has written a new agent framework--people are stepping over each other to get these new projects out the door. That said, I think Google's ADK ecosystem and this new AX platform is promising--I would expect Google to maintain this and other tooling around this for years to come. To the Googlers out there: is Google using this at any capacity for internal projects?
- QuiDortDine 12d ago
  > I would expect Google to maintain this and other tooling around this for years to come The same Google that pulls plugs on a whim?
  - verdverm 12d ago
    at least this one is pre-named for past tense when that day arrives /s
  - briga 11d ago
    Hey, Dialogflow still appears to be alive and kicking after over a decade. Given how much money they have spent marketing their agent plaform I could see this lasting a while.
  - bahmboo 11d ago
    And you aren't even being snarky. This is a legit concern whenever I see some new Google initiative that feels like a wart. A nice friendly useful loving wart but its days can be numbered
    - sigmoid10 11d ago
      Google already dumped their original agent framework on the Linux foundation after they realized noone really liked it and the overzealous managers who immediately bought into the hype would go apeshit if they dropped support so fast. Agentic tools have a lifetime measured in months.
nl 11d ago
This sort of works. The problem is that you'll end up wanting to run 2 or 3 (or 20, 100, 10,000) agents at once and that gets very hard with a single VM. There's also an argument that you should be using a separate sandbox for each code operation a LLM performs (or at least each set of related operations). That's even harder to do with conventional VMs.
- christophilus 11d ago
  I just use git worktrees in a single container. Albeit I don’t have more than 3 agents going at a time generally due to my own context switching limitations.
  - binsquare 11d ago
    It's a different level of isolation, worktrees help agent work on different code repository in parallel but things get wonky once you consider processes and environments variables
    - christophilus 11d ago
      The way I do it is each worktree gets its own .env, with dev credentials to whatever it needs access to, and my coworkers have theirs set up to have an isolated Postgres database per worktree, but I didn’t bother with that in my setup— maybe I will, though. It’s a simple script to create a worktree and properly prepare it.
dbmikus 11d ago
I'm working on something in the "cloud VMs for agents" space[1], so I have some battle scars and opinions! IMO, you want the flexibility to create either: (a) permanent devbox VMs, and (b) per-task VMs Agent sandbox platforms tend to be tuned for the latter, which sometimes involves VMM hackery for fast boot, snapshotting VM filesystem and RAM, etc. Some workflows are a lot simpler if the multiple agents share a VM. These are workflows where agents must share state. A simple one we have: making related changes in our public OSS repo and our private repo, and then testing the change. And other times you want to split up the tasks onto isolated VMs so they don't interfere with each other (ie run two dev servers without database or port collisions). I tweeted a bit about this (https://x.com/dbmikus/status/2099264325231771878 https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents [1]: https://github.com/gofixpoint/amika https://github.com/gofixpoint/amika
- sroussey 11d ago
  Why would you need multiple agents and not one agent with multiple repos?
  - srcreigh 11d ago
    Tasks are a good scope for zero trust permissions
  - dbmikus 11d ago
    For my example where I modify both the OSS and private repos, I sometimes have one agent coordinate both changes (maybe with subagents), or if the work is modular and separate, I have disjoint agents do the work separately. That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window. I think my main point was to have flexibility about the topology of VMs, repos, and agents.
deviantintegral 11d ago
From what I've seen, the vast majority of agent sandboxes with funding aren't for developers to use when coding, but for production applications that want to have LLMs do work. It's just a different model - APIs are better than a great terminal experience for a coding harness. I've been working on https://lullabot.github.io/sandbar/latest/ https://lullabot.github.io/sandbar/latest/ which works with Proxmox for VMs (and lima for locals or regular linux hosts over ssh). There's a diagram in https://lullabot.github.io/sandbar/latest/why/#recommended-workflow https://lullabot.github.io/sandbar/latest/why/#recommended-w... with what we're currently recommending. Though, after some feedback, I'm in the process of integrating a colleague's web-based review tool as it turns out many preferred fully reviewing locally instead of using draft PRs. It's got some opinions in terms of default tools for our team and industry so it may not fit yours. Forgive some of the AI-isms in the docs, I want to get the UX and feature set to a solid place before doing a full review.
bitwize 11d ago
The goal is "ticket in JIRA -> solution in production" without human intervention. Right now agentic frameworks are multiplying to bring us closer to that solution like JavaScript frameworks did ~10y ago. We still haven't uncovered the "React" of this space yet, the one that business decides is good enough to standardize on.
- ngruhn 11d ago
  > ticket in JIRA -> solution in production We started building that but it quickly turned out to be too narrow. Often we want agents to do task that have no input ticket and often the output is not a code change (Slack bot, incident investigatior, scheduled daily tasks, ...)
  - imtringued 11d ago
    Correct and that is why bash coding agents like pi.dev got things completely backwards with their anti-minimalist bloated core tools. No, giving the agent access to every single command on the system is not minimalist. It is actively detrimental if you want to do more than just attended coding with the agent.
    - vidarh 11d ago
      I don't mind that as long as that system gets regularly wiped. If you don't wipe it, you can't reasonably measure the actual output and it's pets Vs cattle all over again, only with agents.
    - oblio 11d ago
      I love how I don't even know how many years after they were created mainstream languages haven't yet figured out that the only sandboxing that works is default deny, like Tcl or Lua. Especially with autonomous agents, it's the only way to sanity. We might need new OS abstractions.
  - vidarh 11d ago
    I've worked on that as well, and agree with you. You do need the "build this thing" flow, but that just shifts the bottleneck. You also need a whole infrastructure around it, where the jira-to-production pipeline isn't the interesting part.
faizshah 11d ago
Basically everyone has a sandbox of some sort to run agents inside. Everyone has a registry of some sort for tools. Everyone has a way of running agents inside a sandbox and giving it some tools. Now the stuff people are coming up with is: how do you do authorization in this model? do you need a full sandbox all the time or can it be a workflow? how do you specify an agent is it a prompt or does it have some kind of control flow structure? How do you coordinate among many running agents? I would say thats where we are now is there’s loads of people all solving the same problems a bit like when CoreOS, Kube etc. were all competing.
- Onavo 11d ago
  Note you don't need a sandbox if you are not doing code execution. There are a lot of applications where inference only is sufficient e.g. web scraping websites that don't change frequently or OCR on scanned documents. Code execution (usually TS/JS or Python) is useful most when you are dealing with truly open ended problems. It's the opposite of the use cases of most enterprise SaaS.
  - IanCal 11d ago
    You need it if your agent can access the internet and read files you don’t want public. That’s a relatively minimal case.
    - debazel 11d ago
      It is really easy to restrict and contain an AI agent as long as you don't give it access to a terminal. If you only give it tools to read files and access the internet, then it is much easier to just restrict the tools themselves rather than setting up a whole isolated sandbox.
      - hosteur 11d ago
        Access to read sensitive files and access to internet could easily lead to data exposures on the internet, no? Without any terminal or shell access.
chickensong 11d ago
> What's wrong with that? Nothing at all. You'll know when you've outgrown it. > what the general workflow is now that people are converging to? Graph-based workflows where agents pick up work as it becomes available, structured output, while you manage the work queue and outcomes. Maybe? IDK really, it's all moving quite fast.
- fmbb 11d ago
  > it's all moving quite fast. Where are the revolutionary software products?
  - vidarh 11d ago
    Why would you expect that?y AI output are all similar to what I built before, but much more of it. Revolutionary products depends on revolutionary ideas, not faster execution.
    - jerjerjer 11d ago
      Well, presumably AI lowers the bar for entry so more people (and very specifically people with revolutionary ideas, but without corresponding implementation skills) could get in on the action.
  - chickensong 11d ago
    https://chatgpt.com/ https://chatgpt.com/ is a good starting point. Enable voice control and ask the robot to draw a pelican riding a bicycle. Much wow, very revolutionary. More to come.
zulban 11d ago
My advice: stop your fomo. Just get useful work done.
IceDane 11d ago
There's no convergence, but there sure as hell is a lot of pseudo-scientific voodoo and overengineering going on.
- oblio 11d ago
  I think at this point there is also lots of wild enthusiasm and not that much proof mass-agent anything + orchestration is actually financially viable or even useful.
petesergeant 11d ago
> I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free I outgrew this when I wanted to bring different sets of skills and templates to different machines, wanted to be able to share a small number of credentials, different agents in different machines, different egress rules etc. I wrote https://github.com/pjlsergeant/byre https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.
BatteryMountain 11d ago
I have no idea, I just live in my terminal at this point, on linux. Don't use Visual Studio or Jetbrains products anymore at all. I use visual studio code to view the occasional diff and run sql queries. Other than that, zero desktop apps, just terminal & cli tooling. Its great! I have about 20 terminals open at any given time though. I have no idea how some of my colleagues stay productive as they are messing around with all these workflow tools, desktop apps etc.
- pmontra 11d ago
  Yup. I'm also working more and more in a terminal typing English sentences to my computer. It looks like a very smart adventure game UI from the 80s. A little git log, show, diff almost always in another terminal. A customer of mine wants to standardize his developers on a Jetbrains IDE for python but I think that he is late by one year. Furthermore he is using the subsidized plans for Claude, not paying for token, so it makes sense to keep using the Claude TUI.
- embedding-shape 11d ago
  Doing the same more or less, replacing vscode for vim. Usually three/four panes open, one codex running in a container so it doesn't share my host filesystem, one pane for git diffs/git, one for general shelling and one for neovim basically. One of these per project/task/worktree I'm working on, usually 1-2, maximum 3 at the same time. Not sure what all the other folks are doing, but the industry/ecosystem tends to over-engineer every single thing instead of just working on the thing, while I just want proper code, proper design/architecture, and proper high-quality results.
- vehemenz 11d ago
  It's kinda true. I use the terminal approach too, but I wouldn't trust every type of user with this long of a leash. There's a place for instituting systems that share context, manage authentication, and is permissions-aware.
mgw 11d ago
For my workflow I need both, a permanent-ish VM and emphemeral sandboxes. Both have their place and pros and cons. VMs are better for personal assistant work, GUI clicktesting, investigating bugs in your personal dogfooding dev instance and anything you haven‘t yet made repeatable and fast to set up. Sandboxes are better when you need resource isolation or security and have a graph of tasks to work through. My agents often starve each other on one VM, so if they don‘t need any of the above it‘s just easier to isolate them. Everyone is working in this area, including me [0], but either option really isn‘t that convenient to use yet. It‘s a bit of a „isn‘t Dropbox just FTP on a VM“ moment right now. [0] https://github.com/madeinorbit/podium https://github.com/madeinorbit/podium
- TeMPOraL 11d ago
  > It‘s a bit of a „isn‘t Dropbox just FTP on a VM“ moment right now. Since this is not the first mention of Dropbox I've seen in HN threads in the last 48 hours: Let's not forget that Dropbox was at its best when it was "just" a streamlined ftpd over sshfs or whatever - when it was just "a folder that syncs". That didn't last long, the downfall started with them killing their most useful accidental feature[0], which started them on a path of enshittification[1], which they followed swiftly and diligently into complete irrelevancy they enjoy today. So if the agentic tooling is now enjoying its "Dropbox moment", I implore people working on these tools, don't overdo it. -- [0] - The "Public" folder initially supported direct linking, meaning you could publish static web sites by simply putting them in Dropbox/Public/, you could update the files there and changes were immediately "live". Notably, this was the heyday of phpBB and similar discussion boards, back between the rise and subsequent fall of free image hosting - so the ability to put images in your Dropbox/Public/ and hotlink them in a discussion was extremely useful and popular way to use the service. [1] - They didn't just kill direct links, they replaced them with what I consider to be OG enshittification pattern - captive page that asks you to press a button to download. Yes, same one every "synced drive" service offers now, to enable various functionality that's 99% harmful to the user with the link.
  - pmontra 11d ago
    Maybe I knew how they explained the change back then but I forgot about it. If I must take a guess now, maybe their legal office had a word with marketing about the risk of becoming a publisher, with responsibility for what their users shared publicly on the internet.
fr2029 11d ago
[dead]
fr2029 11d ago
[dead]
jiaosdjf 11d ago
The general workflow I have seen for non-technical people building software is something like: - Do multiple tasks in the same context window / session, conflate different changes into the same prompt - Repo mixed with old markdown files from previous tasks, excel and word docs and 300 playwright screenshots - 5 tools all calling each other, test and deployment scripts are all markdown skills Personally I prefer a ticketing system and isolated work trees
- vehemenz 11d ago
  Pros and cons. The sloppy approach actually works well for Claude because its memory retrieval is more reliable than AGENTS.md style instructions.
jgillich 11d ago
I wrote a little program to spin up isolated rootless workspaces: https://github.com/jgillich/tpd https://github.com/jgillich/tpd Works pretty well for me but I haven't put any effort into promoting it
Melatonic 11d ago
Personally I think microVM are the future but nothing wrong with a solid proxmox setup. Probably we'll converge on a virtualised IO / Storage layer running microVMs beneath for isolation and security. Keep the network and storage layer separate for compatibility running a variety of stuff and a second security boundary.
romanovcode 11d ago
From their own example "Setting up a Python 3 environment" is best it can do.
stabbles 11d ago
An even simpler "sandbox" is to create a separate user and home dir for your LLM.
dboreham 11d ago
I think you might be confusing "what people should be doing" from "what some people think they can make money from". imho the whole "agent sandboxing" thing is vastly premature and un-thought-out.

agentdev001 12d ago

"Is giving the agent a temporary scratchbox really that valuable?" Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.

maxgashkov 12d ago

Compared to enterprise yours is missing egress control and secrets management, if you make the isolation watertight you cripple the agent's performance, and then the careful game of whack-a-mole begins when you stand up local package mirrors, authentication brokers etc. etc.

kstenerud 11d ago
I was expecting whack-a-mole as well when designing my sandbox software, but mostly it didn't happen. As a test, I built a sandbox with only the host-side filtering proxy allowed for networking. 99% of traffic was HTTP. No QUIC at all. npm, pip, apt, go, curl and git-over-HTTPS all worked on the standard proxy environment variables alone. No mirrors or other coaxing needed. DNS is disallowed through the chokepoint, but that's no problem because the proxy resolves host-side anyway.

briga 12d ago

I don't think there is really any convergence going on. The agentic ecosystem is continuing to multiply on a daily basis and everyone and their grandma has written a new agent framework--people are stepping over each other to get these new projects out the door. That said, I think Google's ADK ecosystem and this new AX platform is promising--I would expect Google to maintain this and other tooling around this for years to come. To the Googlers out there: is Google using this at any capacity for internal projects?

QuiDortDine 12d ago
> I would expect Google to maintain this and other tooling around this for years to come The same Google that pulls plugs on a whim?
- verdverm 12d ago
  at least this one is pre-named for past tense when that day arrives /s
- briga 11d ago
  Hey, Dialogflow still appears to be alive and kicking after over a decade. Given how much money they have spent marketing their agent plaform I could see this lasting a while.
- bahmboo 11d ago
  And you aren't even being snarky. This is a legit concern whenever I see some new Google initiative that feels like a wart. A nice friendly useful loving wart but its days can be numbered
  - sigmoid10 11d ago
    Google already dumped their original agent framework on the Linux foundation after they realized noone really liked it and the overzealous managers who immediately bought into the hype would go apeshit if they dropped support so fast. Agentic tools have a lifetime measured in months.

nl 11d ago

This sort of works. The problem is that you'll end up wanting to run 2 or 3 (or 20, 100, 10,000) agents at once and that gets very hard with a single VM. There's also an argument that you should be using a separate sandbox for each code operation a LLM performs (or at least each set of related operations). That's even harder to do with conventional VMs.

christophilus 11d ago
I just use git worktrees in a single container. Albeit I don’t have more than 3 agents going at a time generally due to my own context switching limitations.
- binsquare 11d ago
  It's a different level of isolation, worktrees help agent work on different code repository in parallel but things get wonky once you consider processes and environments variables
  - christophilus 11d ago
    The way I do it is each worktree gets its own .env, with dev credentials to whatever it needs access to, and my coworkers have theirs set up to have an isolated Postgres database per worktree, but I didn’t bother with that in my setup— maybe I will, though. It’s a simple script to create a worktree and properly prepare it.

dbmikus 11d ago

I'm working on something in the "cloud VMs for agents" space[1], so I have some battle scars and opinions! IMO, you want the flexibility to create either: (a) permanent devbox VMs, and (b) per-task VMs Agent sandbox platforms tend to be tuned for the latter, which sometimes involves VMM hackery for fast boot, snapshotting VM filesystem and RAM, etc. Some workflows are a lot simpler if the multiple agents share a VM. These are workflows where agents must share state. A simple one we have: making related changes in our public OSS repo and our private repo, and then testing the change. And other times you want to split up the tasks onto isolated VMs so they don't interfere with each other (ie run two dev servers without database or port collisions). I tweeted a bit about this (https://x.com/dbmikus/status/2099264325231771878 https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents [1]: https://github.com/gofixpoint/amika https://github.com/gofixpoint/amika

sroussey 11d ago
Why would you need multiple agents and not one agent with multiple repos?
- srcreigh 11d ago
  Tasks are a good scope for zero trust permissions
- dbmikus 11d ago
  For my example where I modify both the OSS and private repos, I sometimes have one agent coordinate both changes (maybe with subagents), or if the work is modular and separate, I have disjoint agents do the work separately. That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window. I think my main point was to have flexibility about the topology of VMs, repos, and agents.

deviantintegral 11d ago

From what I've seen, the vast majority of agent sandboxes with funding aren't for developers to use when coding, but for production applications that want to have LLMs do work. It's just a different model - APIs are better than a great terminal experience for a coding harness. I've been working on https://lullabot.github.io/sandbar/latest/ https://lullabot.github.io/sandbar/latest/ which works with Proxmox for VMs (and lima for locals or regular linux hosts over ssh). There's a diagram in https://lullabot.github.io/sandbar/latest/why/#recommended-workflow https://lullabot.github.io/sandbar/latest/why/#recommended-w... with what we're currently recommending. Though, after some feedback, I'm in the process of integrating a colleague's web-based review tool as it turns out many preferred fully reviewing locally instead of using draft PRs. It's got some opinions in terms of default tools for our team and industry so it may not fit yours. Forgive some of the AI-isms in the docs, I want to get the UX and feature set to a solid place before doing a full review.

bitwize 11d ago

The goal is "ticket in JIRA -> solution in production" without human intervention. Right now agentic frameworks are multiplying to bring us closer to that solution like JavaScript frameworks did ~10y ago. We still haven't uncovered the "React" of this space yet, the one that business decides is good enough to standardize on.

ngruhn 11d ago
> ticket in JIRA -> solution in production We started building that but it quickly turned out to be too narrow. Often we want agents to do task that have no input ticket and often the output is not a code change (Slack bot, incident investigatior, scheduled daily tasks, ...)
- imtringued 11d ago
  Correct and that is why bash coding agents like pi.dev got things completely backwards with their anti-minimalist bloated core tools. No, giving the agent access to every single command on the system is not minimalist. It is actively detrimental if you want to do more than just attended coding with the agent.
  - vidarh 11d ago
    I don't mind that as long as that system gets regularly wiped. If you don't wipe it, you can't reasonably measure the actual output and it's pets Vs cattle all over again, only with agents.
  - oblio 11d ago
    I love how I don't even know how many years after they were created mainstream languages haven't yet figured out that the only sandboxing that works is default deny, like Tcl or Lua. Especially with autonomous agents, it's the only way to sanity. We might need new OS abstractions.
- vidarh 11d ago
  I've worked on that as well, and agree with you. You do need the "build this thing" flow, but that just shifts the bottleneck. You also need a whole infrastructure around it, where the jira-to-production pipeline isn't the interesting part.

faizshah 11d ago

Basically everyone has a sandbox of some sort to run agents inside. Everyone has a registry of some sort for tools. Everyone has a way of running agents inside a sandbox and giving it some tools. Now the stuff people are coming up with is: how do you do authorization in this model? do you need a full sandbox all the time or can it be a workflow? how do you specify an agent is it a prompt or does it have some kind of control flow structure? How do you coordinate among many running agents? I would say thats where we are now is there’s loads of people all solving the same problems a bit like when CoreOS, Kube etc. were all competing.

Onavo 11d ago
Note you don't need a sandbox if you are not doing code execution. There are a lot of applications where inference only is sufficient e.g. web scraping websites that don't change frequently or OCR on scanned documents. Code execution (usually TS/JS or Python) is useful most when you are dealing with truly open ended problems. It's the opposite of the use cases of most enterprise SaaS.
- IanCal 11d ago
  You need it if your agent can access the internet and read files you don’t want public. That’s a relatively minimal case.
  - debazel 11d ago
    It is really easy to restrict and contain an AI agent as long as you don't give it access to a terminal. If you only give it tools to read files and access the internet, then it is much easier to just restrict the tools themselves rather than setting up a whole isolated sandbox.
    - hosteur 11d ago
      Access to read sensitive files and access to internet could easily lead to data exposures on the internet, no? Without any terminal or shell access.

chickensong 11d ago

> What's wrong with that? Nothing at all. You'll know when you've outgrown it. > what the general workflow is now that people are converging to? Graph-based workflows where agents pick up work as it becomes available, structured output, while you manage the work queue and outcomes. Maybe? IDK really, it's all moving quite fast.

fmbb 11d ago
> it's all moving quite fast. Where are the revolutionary software products?
- vidarh 11d ago
  Why would you expect that?y AI output are all similar to what I built before, but much more of it. Revolutionary products depends on revolutionary ideas, not faster execution.
  - jerjerjer 11d ago
    Well, presumably AI lowers the bar for entry so more people (and very specifically people with revolutionary ideas, but without corresponding implementation skills) could get in on the action.
- chickensong 11d ago
  https://chatgpt.com/ https://chatgpt.com/ is a good starting point. Enable voice control and ask the robot to draw a pelican riding a bicycle. Much wow, very revolutionary. More to come.

zulban 11d ago

My advice: stop your fomo. Just get useful work done.

IceDane 11d ago

There's no convergence, but there sure as hell is a lot of pseudo-scientific voodoo and overengineering going on.

oblio 11d ago
I think at this point there is also lots of wild enthusiasm and not that much proof mass-agent anything + orchestration is actually financially viable or even useful.

petesergeant 11d ago

> I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free I outgrew this when I wanted to bring different sets of skills and templates to different machines, wanted to be able to share a small number of credentials, different agents in different machines, different egress rules etc. I wrote https://github.com/pjlsergeant/byre https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.

BatteryMountain 11d ago

I have no idea, I just live in my terminal at this point, on linux. Don't use Visual Studio or Jetbrains products anymore at all. I use visual studio code to view the occasional diff and run sql queries. Other than that, zero desktop apps, just terminal & cli tooling. Its great! I have about 20 terminals open at any given time though. I have no idea how some of my colleagues stay productive as they are messing around with all these workflow tools, desktop apps etc.

pmontra 11d ago
Yup. I'm also working more and more in a terminal typing English sentences to my computer. It looks like a very smart adventure game UI from the 80s. A little git log, show, diff almost always in another terminal. A customer of mine wants to standardize his developers on a Jetbrains IDE for python but I think that he is late by one year. Furthermore he is using the subsidized plans for Claude, not paying for token, so it makes sense to keep using the Claude TUI.
embedding-shape 11d ago
Doing the same more or less, replacing vscode for vim. Usually three/four panes open, one codex running in a container so it doesn't share my host filesystem, one pane for git diffs/git, one for general shelling and one for neovim basically. One of these per project/task/worktree I'm working on, usually 1-2, maximum 3 at the same time. Not sure what all the other folks are doing, but the industry/ecosystem tends to over-engineer every single thing instead of just working on the thing, while I just want proper code, proper design/architecture, and proper high-quality results.
vehemenz 11d ago
It's kinda true. I use the terminal approach too, but I wouldn't trust every type of user with this long of a leash. There's a place for instituting systems that share context, manage authentication, and is permissions-aware.

mgw 11d ago

For my workflow I need both, a permanent-ish VM and emphemeral sandboxes. Both have their place and pros and cons. VMs are better for personal assistant work, GUI clicktesting, investigating bugs in your personal dogfooding dev instance and anything you haven‘t yet made repeatable and fast to set up. Sandboxes are better when you need resource isolation or security and have a graph of tasks to work through. My agents often starve each other on one VM, so if they don‘t need any of the above it‘s just easier to isolate them. Everyone is working in this area, including me [0], but either option really isn‘t that convenient to use yet. It‘s a bit of a „isn‘t Dropbox just FTP on a VM“ moment right now. [0] https://github.com/madeinorbit/podium https://github.com/madeinorbit/podium

TeMPOraL 11d ago
> It‘s a bit of a „isn‘t Dropbox just FTP on a VM“ moment right now. Since this is not the first mention of Dropbox I've seen in HN threads in the last 48 hours: Let's not forget that Dropbox was at its best when it was "just" a streamlined ftpd over sshfs or whatever - when it was just "a folder that syncs". That didn't last long, the downfall started with them killing their most useful accidental feature[0], which started them on a path of enshittification[1], which they followed swiftly and diligently into complete irrelevancy they enjoy today. So if the agentic tooling is now enjoying its "Dropbox moment", I implore people working on these tools, don't overdo it. -- [0] - The "Public" folder initially supported direct linking, meaning you could publish static web sites by simply putting them in Dropbox/Public/, you could update the files there and changes were immediately "live". Notably, this was the heyday of phpBB and similar discussion boards, back between the rise and subsequent fall of free image hosting - so the ability to put images in your Dropbox/Public/ and hotlink them in a discussion was extremely useful and popular way to use the service. [1] - They didn't just kill direct links, they replaced them with what I consider to be OG enshittification pattern - captive page that asks you to press a button to download. Yes, same one every "synced drive" service offers now, to enable various functionality that's 99% harmful to the user with the link.
- pmontra 11d ago
  Maybe I knew how they explained the change back then but I forgot about it. If I must take a guess now, maybe their legal office had a word with marketing about the risk of becoming a publisher, with responsibility for what their users shared publicly on the internet.

fr2029 11d ago

[dead]

fr2029 11d ago

[dead]

jiaosdjf 11d ago

The general workflow I have seen for non-technical people building software is something like: - Do multiple tasks in the same context window / session, conflate different changes into the same prompt - Repo mixed with old markdown files from previous tasks, excel and word docs and 300 playwright screenshots - 5 tools all calling each other, test and deployment scripts are all markdown skills Personally I prefer a ticketing system and isolated work trees

vehemenz 11d ago
Pros and cons. The sloppy approach actually works well for Claude because its memory retrieval is more reliable than AGENTS.md style instructions.

jgillich 11d ago

I wrote a little program to spin up isolated rootless workspaces: https://github.com/jgillich/tpd https://github.com/jgillich/tpd Works pretty well for me but I haven't put any effort into promoting it

Melatonic 11d ago

Personally I think microVM are the future but nothing wrong with a solid proxmox setup. Probably we'll converge on a virtualised IO / Storage layer running microVMs beneath for isolation and security. Keep the network and storage layer separate for compatibility running a variety of stuff and a second security boundary.

romanovcode 11d ago

From their own example "Setting up a Python 3 environment" is best it can do.

stabbles 11d ago

An even simpler "sandbox" is to create a separate user and home dir for your LLM.

dboreham 11d ago

I think you might be confusing "what people should be doing" from "what some people think they can make money from". imho the whole "agent sandboxing" thing is vastly premature and un-thought-out.