The sandboxing problem

A decade ago, I discovered an interesting way to sandbox my development environment. Or rather, co-discovered; I realized later that others, probably several dozen worldwide, had also figured it out. Apparently, it was an idea whose time had come.

What I did not realize at the time, is how this sandboxing technique would also be perfect for coding agents today.

You see, I made that sandbox not because I wanted to isolate my IDE. I wasn't worried the IDE would randomly decide to delete my home directory, or email my ssh private keys to evil hax0rs, etc. Like we have to worry about with coding agents, now.

But you know the kind of bug where the program works great on your machine, and then immediately blows up in production? Don't you hate that? Which happens because prod is a different environment, and probably even a different OS.

I got sick and tired of that kind of bug. So I set up a kind of virtual-machine sandbox, a near clone of production, but running on my laptop. So those prod-only bugs showed up during development, when it was easy to fix, and I lived happily ever after.

Fast forward to today...

When much to my delight and surprise, I realize that same VM sandbox is the perfect way to protect yourself from coding agents.

I wasn't too sure of this, actually, until the past week, when I went went on a deep dive on ways to sandbox coding agents. Some of the tools I looked at include:

I will spare you the gritty details...

And just point out that every one of these make SOME of what you want to do easy. But not all.

They're all good solutions, especially if your company has someone whose full-time job is to solve their problems for you. If that's the case, just do what they say and move on.

But what I keep coming back to is my battle-tested VM sandbox.

Where you have the code locally on your machine, and edit them with your IDE as normal. But also mount those files in the VM, where you actually run the program, execute its test suite, and (now) run the coding agent.

And in many cases, this allows you to closely replicate the production environment, making it impossible for those nasty prod-only bugs to hide.

This approach is not really taught publicly. Even though a number of us (mostly ex-devops who now focus more on coding) have figured out how to do it, there isn't any instruction anywhere I know of.

In fact, the only place I know it is fully taught is in the course called:

"Sandboxing Coding Agents: Creating a Local VM Sandbox With Vagrant"

Which is exclusively in the Boosted Code curriculum.

And when I started researching those other sandboxes last week, I was checking whether I needed to add them to the course. I thought maybe some of them were better, faster and easier than what I had been doing.

But no. My deep dives just increased my conviction that what I'm already teaching is the best single solution you can learn right now.

(One which will be useful for many years. It is so general and future-proof, it will probably work well for over a decade, maybe decades. Because it does not depend on any technology that might get abandoned once its early enthusiasm wears off.)

If you are in BC right now, I strongly recommend you complete "Sandboxing Coding Agents" as soon as you can get to it. Especially because some of the upcoming new course modules will depend on it, as a prerequisite.

For more about Boosted Code and how to join, go here:

About Boosted Code