Comment by manmal

Comment by manmal 3 days ago

Containers bring their own set of problems, there are some examples brought up in this thread, mainly around communication with the host OS.

I‘d argue the reproducible parts of vibe coding (agentic engineering) setups are just text files. Many people use a mix of web apps (AI studio), Mac apps (Wispr Flow), and other UI tools (repo prompt) in their workflow which can’t be put in a container anyway - well, reasonably at least.

If you want security, containers won’t get you that far. You’ll need to use a VM.

But if you give Claude Code access to your GitHub repo, what else is there worth protecting, that’s not protected by keychain & sudo?

photonthug 3 days ago

All development is text files, that is missing the point. The development environment is a system, and a pretty complicated one too. It matters where the files are, what's in them, and how they interact. Things change together instead of staying isolated, you add more pieces over time, and even more things need to change together. Anyone who likes text-files more than click-to-configure UIs for tools, will probably like containers more than text files for systems, and for all the same reasons.

Your choices to reproduce complex systems are basically to 1) deny that complexity exists and accept any corresponding limitations in your working environment, 2) follow some error-prone multistep processes to reproduce existing system setup manually, 3) commit to centralizing all development on external cloud platforms, or 4) do something else to bundle together a setup that's repeatable.

I'm strongly in favor of (4) here, and while I'd probably disagree that it requires VMs instead of docker, the goal of repeatable processes is so important that hey, whatever works. It sounds like you're in camp 1 or 2?

Reply View 2 replies

skydhash 3 days ago

> The development environment is a system, and a pretty complicated one too.
It's also partly personal. I also like to use isolated environments, mostly because I tinker with different technologies, and over times, it becomes a mess on my machine.
But I still like my git config, my editor and other tooling that I have to assist in my tasks. And it's not worth it to replicate it over to other people's setup. And neither I want their things.

Reply View | 1 reply
- photonthug 3 days ago
  
  > But I still like my git config, my editor and other tooling that I have to assist in my tasks. And it's not worth it to replicate it over to other people's setup.
  This isn't about stopping you from customizing your development environment. It's about making your custom development environment automatically useful on your desktop or your laptop, or committing a project-specific starter environment to version control so that it doesn't take everyone on your team days to onboard.
  > And neither I want their things.
  Why not? This isn't about something like git aliases or editor keyboard shortcuts. It's about tooling pipelines. If someone's claiming enhanced productivity I don't want to watch their 1 hour youtube video, pause it, and painstakingly recreate their setup to check if the claims are true.
  There's a reason projects grow Tiltfiles, compose files, and similar. In the limit, agents are basically just a collection of microservices that just happen to operate on code. How do you expect to do that sort of thing without tools?
  
  Reply View | 0 replies