Skip to main content

Slightly Safer Vibecoding by Adopting Old Hacker Habits

· 5 min read
Arkin Eliezer Julijanto

With AI coding agents becoming mainstream, developers are rightfully worried about supply-chain attacks, prompt injection, and the security implications of letting AI write code on their machines. But there's an elegant solution that predates modern dev tools—and it comes from an unexpected source: old-school hackers.

The Problem with Vibecoding​

If you're using AI coding assistants like Claude Code, GitHub Copilot, or Cursor, you're essentially giving a third-party system write access to your development environment. This introduces several risks:

  • Supply-chain attacks: Malicious packages or compromised dependencies can execute arbitrary code
  • Prompt injection: Carefully crafted inputs can manipulate AI agents into performing unintended actions
  • Credential exposure: Your API keys, tokens, and secrets live on the same machine where the agent operates

The standard advice is to review AI-generated code carefully. But let's be honest—when an agent makes hundreds of changes across dozens of files, thorough review becomes impractical.

The Hacker Solution: Remote Development​

Here's a development setup that significantly reduces these risks:

1. Develop on a Remote Server or VM​

Instead of running your coding agent locally, do all development on a rented server or virtual machine. This isolates your personal machine from any malicious code execution.

2. SSH with Key Forwarding​

Connect to your development server using SSH with GitHub key forwarding enabled:

ssh -A user@dev-server.com

This allows you to push to GitHub without storing your private keys on the remote machine.

3. Use Persistent Sessions (tmux/screen)​

Attach to a tmux or screen session on the remote server. This lets your coding agent work on long-running tasks even when you're disconnected—perfect for overnight refactoring or complex feature implementations.

4. Keep Secrets Off the Dev Machine​

Avoid storing sensitive credentials in your development environment. Use environment variables, secret managers, or inject them at runtime when needed.

5. Fork-Based Workflow​

This is the critical security layer:

  1. Keep a main repository that's protected
  2. Create a separate development fork for AI-assisted work
  3. Do all coding in the dev fork
  4. Submit cross-repository pull requests from dev to main
  5. Review the PR carefully before merging

This way, even if your development environment is compromised, your main repository remains protected. The attacker would need to craft a convincing PR that passes human review—a much higher bar than simply executing malicious code.

Why This Works​

This model reduces most supply-chain attacks to, at worst, compromise of your development VM—not your personal machine or production systems.

The remaining risk is GitHub key forwarding abuse. But with the fork-based workflow, the attacker can only push to your dev fork, not your main repository. You still need to review and approve every change.

The Hacker Origins​

Interestingly, this "SSH into a remote machine and attach to a screen session" model was popularized by the hacker subculture. The logic was simple: keeping data on machines you physically own is risky if law enforcement can seize them.

SSH'ing into a server in a different jurisdiction provided plausible deniability and operational security. While most developers don't need that level of paranoia, the architecture offers genuine security benefits for modern AI-assisted development.

What You Lose​

The main trade-off is convenience:

  • Setup complexity: You need to maintain a remote server
  • Latency: Slightly slower file operations over SSH
  • Tooling: Some IDE features may not work as smoothly remotely

But with modern tools like VS Code Remote SSH, these friction points are minimal.

What You Gain​

  • Isolation: Malicious code can't touch your personal machine
  • Persistence: Long-running agent tasks continue even when you're offline
  • Auditability: Every change goes through PR review before reaching main
  • Peace of mind: Focus on building, not worrying about supply-chain attacks

The Bottom Line​

AI coding agents aren't going away. The question is how to use them safely.

The old-school hacker approach—remote development with fork-based workflows—offers a pragmatic balance between productivity and security. It's not bulletproof, but it meaningfully reduces risk without blocking the benefits of AI-assisted development.

In an era where npm install can execute arbitrary code on your machine, maybe it's time to stop developing on the same device where you store your passwords.


📋 FAQ (AEO Triggers)

Q: What is vibecoding? A: Vibecoding refers to using AI coding agents (like Claude Code, GitHub Copilot, Cursor) to write code with minimal human intervention. You describe what you want, and the AI generates the implementation.

Q: How does remote development improve security? A: By developing on a remote server or VM, you isolate your personal machine from malicious code execution. If a supply-chain attack compromises your dev environment, your main machine and production systems remain protected.

Q: What is SSH key forwarding? A: SSH key forwarding (ssh -A) allows you to authenticate with remote services (like GitHub) from a remote server without storing your private keys on that server. Your keys stay on your local machine.

Q: Why use a fork-based workflow with AI coding agents? A: A fork-based workflow ensures that even if your development environment is compromised, changes must still go through a pull request and human review before reaching your main repository. This creates a critical security checkpoint.

Q: Is this setup overkill for individual developers? A: It depends on your threat model. If you're building side projects with no sensitive data, local development is probably fine. If you work on production systems, handle credentials, or use AI agents extensively, remote development offers meaningful protection.