Why your MacBook Pro is the worst place to run an AI coding agent

I still love coding on a fast local machine. Neovim feels instant, builds are quick, and the fan only kicks in when I'm doing something dumb. But as soon as I started treating an AI agent like borg as a real pair programmer rather than a one-shot prompt, my laptop turned into the bottleneck. Not the agent itself: the damn hardware and the flaky network it was attached to.

The 64GB trap: why your laptop still isn't enough

AI coding agents are not like a static LSP server. They spawn chains of subprocesses: linters, test runners, package managers, and sometimes entire headless browsers. Watching htop while borg works on a typical task is a horror show. You'll see Node.js grabbing 400% CPU for 90 seconds, then a Rust compiler hitting all cores, then a Python test suite that forks into 12 workers. All of this happens in parallel while the agent streams context to an LLM.

On my M3 Max with 64GB, swap still creeps in during a large refactor. The machine doesn't crash, but it throttles. The agent's own thinking gets slower because the LLM responses compete with the subprocesses for CPU time. Battery life vanishes; you're tied to a power brick. The local dev loop that used to feel snappy becomes a chore you don't want to touch.

Disconnections kill your agent's context (and your afternoon)

Here's the scenario that finally pushed me off local execution. I was on a train, WiFi kept dropping, and borg was 45 minutes into a cross cutting refactor. The SSH connection to the remote jump box broke, and because the agent was running inside my local tmux session, the entire tmux pane hung and then the agent process died. I lost not just the in-progress work, but the context the agent had built up over dozens of back-and-forth messages. Rebuilding that context took another 25 minutes of conversation.

Local agents are hostages to your laptop's connectivity and power state. Close the lid, the agent stops. WiFi blips, the agent loses its stdin stream and often exits. VPN rotates credentials, goodbye. These aren't edge cases for anyone who codes on the move or works from a coffee shop. And even at a desk, the temptation to reboot for an OS update kills every running agent. That gets expensive when you're paying for LLM tokens that effectively get thrown away.

Offloading to a remote shell: your local machine becomes a thin client

The simplest fix is to move agent execution to a dedicated remote Linux shell. Spin up a VM, push your repo, and run borg run "modernize the error handling in lib/" inside a persistent tmux session on that host. The heavy lifting, the context window, and all the subprocesses live on a machine that never goes to sleep. Your laptop is now just a terminal emulator. You can detach, commute, switch networks, and reattach from your phone or another machine. The agent hasn't skipped a beat.

On a proper remote shell, resources are predictable. You know you have N vCPUs and M GB of RAM dedicated to your session, not shared with Slack, Docker Desktop, or the fifty browser tabs you need open. This means you can give the agent real concurrency. Let it run a full test suite in the background while it plans the next step. You'll see fewer timeouts from the agent getting starved of CPU, and the LLM responses arrive faster because nothing on the host is soaking up I/O bandwidth.

The always-on advantage (and why borg was built for it)

This is where xShellz fits. We offer always-on remote shells that don't hibernate when you disconnect. You can install borg or any other CLI agent, start a long running session, and walk away. The shell stays up, the process tree stays intact, and you get back the time you used to lose to restarts.

We built borg to treat a remote shell as a first-class home, not an afterthought. It checks resource limits on startup, warns you if it's about to peg the CPU, and can pause subprocesses gracefully when you reattach. But even if you use Claude Code or another agent, the same principle holds: a persistent remote execution environment gives you back hours every week that local machines and unstable connections steal.

Don't throw away local dev, just use the right tool for each job

I still edit code locally. The feedback loop of typing and seeing syntax highlights is too fast to give up. But I treat local as the thin client for thinking, and the remote shell as the heavy lifter for doing. When I need an agent to run a cross-repo refactor that requires 20 parallel test runs, that task belongs on a cloud VM. When I want to brainstorm a design, local is fine.

This hybrid approach is the real cloud-native dev loop. Your laptop becomes a control plane; the remote shell is the data plane. If you've been blaming your AI agent for being slow or unstable, try moving it off your local machine before you blame the software. The bottleneck isn't the agent. It's the hardware you're forcing it to live on.