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?
"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.
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.
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?
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.
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
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.
Gmail for Your Domain/Google Apps for Your Domain/Google Apps/Google Apps Premier Edition/Google Apps for Business/Google Apps for Work/G Suite/Google Workspace
I was @ Google I/O at live keynote when they announced/demoed it. Ironically, at the exact same time, me and the guy next to me said (in different words), "Why do we need this?" That was a collaborative Google Wave moment IRL.
Google tries a lot of stuff. It doesn't always work out for them, and sometimes they give up on it. I don't think that's a complete loss for the rest of us. We get to see what didn't work in the real world, and if it's really valuable, someone else can pick up the idea and build on that knowledge. I say this as someone who misses Google Reader.
I think the negative impact lots of humans regularly experience from Google's approach to business is far more than the benefit of the very, very specific learning that "this idea doesn't make enough money for Google the way Google did it".
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.
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.
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
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.
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 (<a href="https://x.com/dbmikus/status/2099264325231771878" rel="nofollow">https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents
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.
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 <a href="https://lullabot.github.io/sandbar/latest/" rel="nofollow">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 <a href="https://lullabot.github.io/sandbar/latest/why/#recommended-workflow" rel="nofollow">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.
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.
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, ...)
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.
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.
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.
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.
What do you mean by the "React" of this space? The overall base layer has more or less converged on Kubernetes + MicroVM, which makes total sense. But if you mean how to interact with it as well as how permissions should work, yeah I agree.
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.
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.
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.
Yes, but what I'm saying is that it is much easier to put a limit on the read_file tool or the http tool rather than sandboxing your whole environment.
You only really need to sandbox when you provide access to tools that are almost impossible to filter correctly, such as a bash tool or a tool for arbitrary code execution.
Limiting it to just read and http limits its usefulness. If you want something like “filter for this, count the number of matches, format like this” you have to make custom tools. And you have to make sure they don’t have any bugs that allow arbitrary code execution.
You’re effectively building your own sandbox in this case. Using a standard one sounds easier unless you have a very focused use case.
Do you actually need it, or do you just fear you need it?
What's the actual realistic threat model for median developer or median user here?
By realistic, I mean that leaking your grandma's recipes or your SSN or your million dollar idea to some pastebin is neither likely nor going to meaningfully make things worse for you, or be useful for any malicious actor. Surely this is not what everyone is worried about?
I spent today doing forensics on ten compromised WordPress sites sharing one hosting account.
I used two agents: One with network access to collect the evidence, and one with everything except the model endpoint cut off, which did the analysis.
The second agent's entire input was attacker-authored. So PHP droppers, obfuscated loaders, database rows, filenames, blah blah.
In this case I'm more worried about hostile input attacking the agent, and I need to contain the damage. My sandboxing solution does that by restricting access to the source data, making it read-only. The work dir can only transfer data via patch and apply (like a git workflow), so even my workspace can't be modified until I approve each change. And then restricted network means that any compromise ain't going noplace.
The second agent couldn't even install PHP or contact any CVE site to check if it was looking at a known attack, and that was by design. All it could do is write up a report about what it observed, not make assumptions about what it is. I could then take its (much smaller) clean output and pass that to a third agent with network access.
This is forensic work, so of course not your median dev's bread & butter. But the attack surface is only just starting to be plumbed. Compromising input can turn your agent into their agent, planting things as easily as planting worms was back in the early internet days when people connected without a firewall.
Security by obscurity is just a bet on weights, a belief that the economic motivations for attacking are insufficient. That worked before, but developments in ML calls to account all the debt we’ve accumulated through that practice.
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.
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.
How many people with revolutionary ideas actually worth anything have genuinely failed to find someone to help them build it?
I think that if they're unable to sell their idea well enough to find a co-founder odds are the idea would die on the vine whether or not they're able to implement it.
<a href="https://chatgpt.com/" rel="nofollow">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.
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.
> 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 <a href="https://github.com/pjlsergeant/byre" rel="nofollow">https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.
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.
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.
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.
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.
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.
> 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.
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.
Perhaps. This was also before CDNs were a thing, so they may have decided they can't afford to be one, as more and more people discovered just how versatile the Public/ folder is.
Either way, this was the peak of Dropbox; after shutting down direct Public/ links, it was still useful for its main job as seamless cross-machine, cross-platform "folder that syncs", but gradually lost market share as OneDrive and Google Drive became more broadly useful (and had the advantage of being first-party on their respective platforms), and then Dropbox the company itself lost focus and tried a bunch of failed pivots in the direction towards cloudification, away from "just syncing files".
End result for end users? We now have zero options for bullshit-free, file-first, seamless "folder that syncs" experience for non-tech users (techies that like fiddling with things have Syncthing). Only cloud-first options remain, and they're full of footguns and enshittified to the core (which becomes apparent the moment you want to share a file outside of the vendor's cloud ecosystem).
I wrote a little program to spin up isolated rootless workspaces: <a href="https://github.com/jgillich/tpd" rel="nofollow">https://github.com/jgillich/tpd
Works pretty well for me but I haven't put any effort into promoting it
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.
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.
sigbottle · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
kstenerud · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
The same Google that pulls plugs on a whim?
verdverm · · focus · HN ↗
briga · · focus · HN ↗
bahmboo · · focus · HN ↗
sigmoid10 · · focus · HN ↗
pm90 · · focus · HN ↗
gnaman · · focus · HN ↗
btw its the same google that has already killed its "gemini cli" and re-introduced it in the form of "antigravity cli"
fishfasell · · focus · HN ↗
ozmaverick72 · · focus · HN ↗
sssilver · · focus · HN ↗
bethekidyouwant · · focus · HN ↗
anjel · · focus · HN ↗
rolymath · · focus · HN ↗
Gmail for Your Domain/Google Apps for Your Domain/Google Apps/Google Apps Premier Edition/Google Apps for Business/Google Apps for Work/G Suite/Google Workspace
hendler · · focus · HN ↗
p_l · · focus · HN ↗
flir · · focus · HN ↗
mansilladev · · focus · HN ↗
egl2020 · · focus · HN ↗
1dom · · focus · HN ↗
calgoo · · focus · HN ↗
contentkraft · · focus · HN ↗
therein · · focus · HN ↗
"Gosh, that Italian family at the next table sure is quiet"
pigeons · · focus · HN ↗
Do you see what you wrote?
falcor84 · · focus · HN ↗
fnord77 · · focus · HN ↗
guilty as charged
klaushougesen1 · · focus · HN ↗
ncruces · · focus · HN ↗
ElFitz · · focus · HN ↗
avazhi · · focus · HN ↗
First time?
nl · · focus · HN ↗
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 · · focus · HN ↗
binsquare · · focus · HN ↗
christophilus · · focus · HN ↗
dbmikus · · focus · HN ↗
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 (<a href="https://x.com/dbmikus/status/2099264325231771878" rel="nofollow">https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents
[1]: <a href="https://github.com/gofixpoint/amika" rel="nofollow">https://github.com/gofixpoint/amika
sroussey · · focus · HN ↗
srcreigh · · focus · HN ↗
dbmikus · · focus · HN ↗
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 · · focus · HN ↗
I've been working on <a href="https://lullabot.github.io/sandbar/latest/" rel="nofollow">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 <a href="https://lullabot.github.io/sandbar/latest/why/#recommended-workflow" rel="nofollow">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 · · focus · HN ↗
ngruhn · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
oblio · · focus · HN ↗
Especially with autonomous agents, it's the only way to sanity.
We might need new OS abstractions.
vidarh · · focus · HN ↗
internet101010 · · focus · HN ↗
faizshah · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
debazel · · focus · HN ↗
hosteur · · focus · HN ↗
debazel · · focus · HN ↗
You only really need to sandbox when you provide access to tools that are almost impossible to filter correctly, such as a bash tool or a tool for arbitrary code execution.
zerd · · focus · HN ↗
TeMPOraL · · focus · HN ↗
What's the actual realistic threat model for median developer or median user here?
By realistic, I mean that leaking your grandma's recipes or your SSN or your million dollar idea to some pastebin is neither likely nor going to meaningfully make things worse for you, or be useful for any malicious actor. Surely this is not what everyone is worried about?
kstenerud · · focus · HN ↗
I used two agents: One with network access to collect the evidence, and one with everything except the model endpoint cut off, which did the analysis.
The second agent's entire input was attacker-authored. So PHP droppers, obfuscated loaders, database rows, filenames, blah blah.
In this case I'm more worried about hostile input attacking the agent, and I need to contain the damage. My sandboxing solution does that by restricting access to the source data, making it read-only. The work dir can only transfer data via patch and apply (like a git workflow), so even my workspace can't be modified until I approve each change. And then restricted network means that any compromise ain't going noplace.
The second agent couldn't even install PHP or contact any CVE site to check if it was looking at a known attack, and that was by design. All it could do is write up a report about what it observed, not make assumptions about what it is. I could then take its (much smaller) clean output and pass that to a third agent with network access.
This is forensic work, so of course not your median dev's bread & butter. But the attack surface is only just starting to be plumbed. Compromising input can turn your agent into their agent, planting things as easily as planting worms was back in the early internet days when people connected without a firewall.
threatofrain · · focus · HN ↗
chickensong · · focus · HN ↗
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 · · focus · HN ↗
Where are the revolutionary software products?
vidarh · · focus · HN ↗
Revolutionary products depends on revolutionary ideas, not faster execution.
jerjerjer · · focus · HN ↗
vidarh · · focus · HN ↗
I think that if they're unable to sell their idea well enough to find a co-founder odds are the idea would die on the vine whether or not they're able to implement it.
jerjerjer · · focus · HN ↗
chickensong · · focus · HN ↗
zulban · · focus · HN ↗
IceDane · · focus · HN ↗
oblio · · focus · HN ↗
petesergeant · · focus · HN ↗
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 <a href="https://github.com/pjlsergeant/byre" rel="nofollow">https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.
BatteryMountain · · focus · HN ↗
pmontra · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
mgw · · focus · HN ↗
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] <a href="https://github.com/madeinorbit/podium" rel="nofollow">https://github.com/madeinorbit/podium
TeMPOraL · · focus · HN ↗
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 · · focus · HN ↗
TeMPOraL · · focus · HN ↗
Either way, this was the peak of Dropbox; after shutting down direct Public/ links, it was still useful for its main job as seamless cross-machine, cross-platform "folder that syncs", but gradually lost market share as OneDrive and Google Drive became more broadly useful (and had the advantage of being first-party on their respective platforms), and then Dropbox the company itself lost focus and tried a bunch of failed pivots in the direction towards cloudification, away from "just syncing files".
End result for end users? We now have zero options for bullshit-free, file-first, seamless "folder that syncs" experience for non-tech users (techies that like fiddling with things have Syncthing). Only cloud-first options remain, and they're full of footguns and enshittified to the core (which becomes apparent the moment you want to share a file outside of the vendor's cloud ecosystem).
fr2029 · · focus · HN ↗
[dead]
fr2029 · · focus · HN ↗
[dead]
jiaosdjf · · focus · HN ↗
- 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 · · focus · HN ↗
jgillich · · focus · HN ↗
Works pretty well for me but I haven't put any effort into promoting it
Melatonic · · focus · HN ↗
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 · · focus · HN ↗
stabbles · · focus · HN ↗
dboreham · · focus · HN ↗