[Terretta]

Arguably, even without LLM, you too should be dev-ing inside a VM...

https://developer.hashicorp.com/vagrant is still a thing.

The market for Cowork is normals, getting to tap into a executive assistant who can code. Pros are running their consumer "claws" on a separate Mac Mini. Normals aren't going to do that, and offices aren't going to provision two machines to everyone.

The VM is an obvious answer for this early stage of scaled-up research into collaborative computing.

[messh]

Yeah, very easy to do today. May VPS providers help with this, checkout:

https://exe.dev

https://sprites.dev

https://shellbox.dev

[Terretta]

Yes! Whether VPS or local VM, this is a thing for good reasons.

Some reasons aren't even optional. Small but regulated entities exist, and most "Team" sized businesses aren't in Google apps or "the cloud" as they think about it, but are in M365, and do pay for cyber insurance.

Cowork with skills plugins that leverage Python or bash is a remarkably enabling framework given how straightforward it is. A skill engineer can sit with an individual contributor domain expert, conversationally decompose the expert's toil into skills and subcommands, iterate a few times, and like magic the IC gets hours back a day.

Cowork is Agents-On-Rails™ for LLM apps, like Rails was to PHP for web apps.

The VM makes that anti-fragile.

For any SaaS builders reading this: by far most white collar small business work is in Microsoft Office. The scarce "Continue with Microsoft" OIDC reaches more potential SMB desks than the ubiquitous "Continue with Google" and you don't have to learn the legacy SAML dance.

Anthropic seems to understand this. It's refreshing when a firm discovers how to cater to the 25–150 seat market. There's an uncanny valley between early adopters and enterprise contracts, but the world runs on SMBs.

Sign them all up!

[hirvi74]

I concur. I don't want to install libraries on my host machine that I won't use for anything other than development, e.g., Node.js.

On macOS, Lima has been a godsend. I have Claude Code in an image, and I just mount the directory I want the VM to have access to. It works flawlessly and has been a replacement for Vagrant for me for some time. Though, I owe a lot to Vagrant. It was a lifesaver for me back in the day.

[mihaelm]

I prefer devcontainers for more involved project setups as they keep it lighter than introducing a VM. It’s also pretty easy to work with Docker (on your host) with the docker-outside-of-docker feature.

However, I’m also curious about using NixOS for dev environments. I think there’s untapped potential there.

[Terretta]

we love nix for dev environments, and highly recommend it. many other problems go away. don't see that as what's being solved here, though.

containers contain stuff the way an open bookcase contains books, they're just namespaces and cgroups on a file system overlay, more or less, held together by willpower not boundaries:

https://jvns.ca/blog/2016/10/10/what-even-is-a-container/

https://github.com/p8952/bocker

as a firm required to care about infosec, we appreciate the stance in their (2). and MacOS VMs are so fast now, they might as well be containers except, you know, they work. (if not fast, that should be fixed.)

that said, yes, running local minikube and the like remain incredibly useful for mocking container envs where the whole environment is inside a machine(s) boundary. containers are _almost_ as awesome as bookcases…

[mihaelm]

I just went on a tangent related to dev environments i.e. inside what to develop. In case of Cowork, a VM is definitely the right choice - no doubt.

[sherburt3]

Do you wear a condom while you’re programming too for maximum protection?