> I SSH into that server with key-forwarding
Almost back to point A then. If the server is compromised in some way, they can use (not copy) OP's keys and use them to clone repos/inject code/etc..
Slightly safer vibecoding by adopting old hacker habits
61–70 of 110 posts
Re: Slightly safer vibecoding by adopting old hacker habits
#62Also, "ssh -A" is your friend. Keep your ssh key on your yubikey where you control it. Let Claude play on it's own VM and in its own clone of your repo. Only when you choose to add the -A, do you temporarily, for that one ssh connection, have the possibility to push Claude's work to your repo, where you can review it.
Treat it as a colleague, making PRs that you review.
Re: Slightly safer vibecoding by adopting old hacker habits
#63I 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?
Re: Slightly safer vibecoding by adopting old hacker habits
#64This 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
Re: Slightly safer vibecoding by adopting old hacker habits
#65This 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?
Re: Slightly safer vibecoding by adopting old hacker habits
#66[flagged]
Re: Slightly safer vibecoding by adopting old hacker habits
#67Why not just not vibecode? Safer methods of injecting recreational narcotics, such madness.
Re: Slightly safer vibecoding by adopting old hacker habits
#68I 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?
haven't tried it but amitds1997/remote-nvim.nvim
I need something like that though that's one of the thing that pains me the most while trying to use vim/nvim for dev
Re: Slightly safer vibecoding by adopting old hacker habits
#69I 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?
[dead]
Re: Slightly safer vibecoding by adopting old hacker habits
#70Apparently using SSH is some leet hacker thing according to this OP. Lmao...