Slightly safer vibecoding by adopting old hacker habits • Hacker News Board

Re: Slightly safer vibecoding by adopting old hacker habits

#71

Post by xnorswap » Wed, Apr 08, 2026, 10:21 AM UTC

arcanemachiner wrote: post #56

Borealid wrote: post #43

I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launch…

The main Claude Code GitHub repo even has a Devcontainer config: https://github.com/anthropics/claude-code It's a great starting point, and can be customized as needed. With the devcontainer CLI, you can even use it from a terminal, no GUI/IDE required.

Is there a guide on getting it working with a devcontainer on the command line?

Re: Slightly safer vibecoding by adopting old hacker habits

#72

Post by [deleted] » Wed, Apr 08, 2026, 10:25 AM UTC

kstenerud wrote: post #13

ori_b wrote: post #12

Earlier quoted context omitted.

Spammy ai-generated self promotion.

In what way? This does the same thing as in the blog post, except that there are a LOT of gotchas and minutiae and some yak shaving involved if you want to keep doing it manually. I've gone through the whole path the author has, and finally had to admit that it's too much fiddling around to do it manually. Easier to just have a cmdline tool that does it for you. That's why I built it in the first place.

[deleted]

Re: Slightly safer vibecoding by adopting old hacker habits

#73

Post by unsupp0rted » Wed, Apr 08, 2026, 10:46 AM UTC

codemog wrote: post #14

I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.

Codex 5.4 medium couldn’t figure out how to run tests in my staging Cloudflare so it went ahead and ran those tests against prod. Mission accomplished.

Yes, agents.md yells not to mess with prod.

Re: Slightly safer vibecoding by adopting old hacker habits

#74

Post by datsci_est_2015 » Wed, Apr 08, 2026, 10:51 AM UTC

mr_mitm wrote: post #63

Borealid wrote: post #43

I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launch…

Has anyone figured out a good way to use (neo)vim with devcontainers?

I personally just use Vim directly in a dedicated development VM that I SSH into. I can always spin up a new one if something goes astray

Re: Slightly safer vibecoding by adopting old hacker habits

#75

Post by rubises » Wed, Apr 08, 2026, 11:06 AM UTC

[dead]

Re: Slightly safer vibecoding by adopting old hacker habits

#76

Post by jbergqvist » Wed, Apr 08, 2026, 11:08 AM UTC

mettamage wrote: post #65

jbergqvist wrote: post #64

This works well for vibecoding on a codebase in isolation, which to be fair is what the author is addressing. I don’t think it solves the problems at the current frontier of agent use though, where you expose internal infrastructure via tools to make the agent maximally productive. How to do this safely is still unsolved

I mean this question unironically: how do you do it with interns?

Limit access to whatever their project requires. The difference is that human interns have some common sense and won't suddenly be hijacked by a hidden message they stumble upon while searching the web, instructing them to exfiltrate a bunch of proprietary data. It is surprisingly easy to get an agent to do that though

Re: Slightly safer vibecoding by adopting old hacker habits

#77

Post by mr_mitm » Wed, Apr 08, 2026, 11:21 AM UTC

datsci_est_2015 wrote: post #74

mr_mitm wrote: post #63

Earlier quoted context omitted.

Has anyone figured out a good way to use (neo)vim with devcontainers?

I personally just use Vim directly in a dedicated development VM that I SSH into. I can always spin up a new one if something goes astray

I'd prefer containers, because they are more light weight and I'm not too concerned about kernel exploits or other sandbox escapes. Configuring a container per project brings me right back to something like devcontainer. But I haven't figured out a good way to incorporate that into my vim/tmux workflow.

Re: Slightly safer vibecoding by adopting old hacker habits

#78

Post by hk1337 » Wed, Apr 08, 2026, 11:40 AM UTC

Borealid wrote: post #43

I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launch…

I love JetBrains and they’ve gotten better with using devcontainers but they’re still kind of flaky at times. I love using devcontainer too, just wanted to note that.

I found cloning the repo when creating the devcontainer works best in JetBrains for some reason and I hard code the workspace directory so it’s consistent between JetBrains and vscode

Re: Slightly safer vibecoding by adopting old hacker habits

#79

Post by hk1337 » Wed, Apr 08, 2026, 11:42 AM UTC

ArchieScrivener wrote: post #42

The fact that Claude can and does access files outside the PWD while asking for sudo to do things constantly seems to be a recipe for Anthropic scanning your system without your knowledge and saving that for 5 years if you decided to 'help improve Claude'. No, 'safety oriented' lab has a clause like that which can't be revoked historically. Anthropic, like the majority of 'don't be evil' firms is apart of the great m…

It does but AFAIK it always asks me if I want to allow it unless it has it saved that permission was already given.

Re: Slightly safer vibecoding by adopting old hacker habits

#80

Post by datsci_est_2015 » Wed, Apr 08, 2026, 12:19 PM UTC

mr_mitm wrote: post #77

datsci_est_2015 wrote: post #74

Earlier quoted context omitted.

I personally just use Vim directly in a dedicated development VM that I SSH into. I can always spin up a new one if something goes astray

I'd prefer containers, because they are more light weight and I'm not too concerned about kernel exploits or other sandbox escapes. Configuring a container per project brings me right back to something like devcontainer. But I haven't figured out a good way to incorporate that into my vim/tmux workflow.

Hmm, maybe I misunderstood the point of the original comment. I thought the OP was suggesting using containers to isolate resources for development vs personal computing, for which I use a VM. But VMs don’t play nicely with IDEs (hence devcontainers).