Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slightly safer vibecoding by adopting old hacker habits

addxorrol.blogspot.com

Post reply on HN
Print view View original

1–10 of 110 posts

Re: Slightly safer vibecoding by adopting old hacker habits

#3

Post by ozozozd »

thwarted wrote: post #2

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.

They mention that as a mechanism for protecting the SSH keys for the repo.

Essentially using a repo that doesn’t matter with the coding agent and then creating a cross-repo PR to the real repo.

Re: Slightly safer vibecoding by adopting old hacker habits

#4

Post by dddddaviddddd »

thwarted wrote: post #2

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.

I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.

Re: Slightly safer vibecoding by adopting old hacker habits

#6

Post by thwarted »

dddddaviddddd wrote: post #4
thwarted wrote: post #2

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.

I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can…

Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.

Re: Slightly safer vibecoding by adopting old hacker habits

#8

Post by kstenerud »

This is what yoloAI does. Automatically.

    # Create a new sandbox copying . as workdir (default container, but you can choose vm)
    yoloai new mybugfix . --isolation vm

    # attach to it (it has tmux already)
    yoloai attach mybugfix

    # Chat with the bot inside...

    # Happy with its work? Diff it to be sure
    yoloai diff mybugfix

    # Happy with the changes? Apply them to your workdir
    yoloai apply mybugfix

    # All done? Destroy the sandbox
    yoloai destroy mybugfix
The agent stays isolated at all times. No access to your secrets (except what you want), no access to your workdir until you apply. You can also easily restrict network access.

https://github.com/kstenerud/yoloai

Re: Slightly safer vibecoding by adopting old hacker habits

#9

Post by throwaway173738 »

dddddaviddddd wrote: post #4
thwarted wrote: post #2

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.

I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can…

You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
Post reply on HN