Sandbox the AI's Work: A Walkthrough of Checks and the Test World
A Show HN went up for Plimsoll, a self-hosted sandbox for running code your AI agent writes. The pitch is one sentence long and everyone on Hacker News got it instantly: agents write code faster than you can read it, so the code needs somewhere to run that isn't your actual machine.
Sandboxing your laptop is the easy half, though. The harder part is what happens after the code looks fine and ships. If an agent builds a feature and it's live for paying customers an hour later, the sandbox stopped existing right when it counted.
On DontCode that second sandbox is the test world. Here's how to actually drive it.
1. Build one feature at a time
Open the Features page. Every feature is planned, building, or built. Select one planned item and press Build. Not five. One build is one thing to read, and when a check fails you know what caused it.
2. Read the checks it wrote
As the feature gets built, Insight writes plain-language checks and lists them under that feature. They're sentences, not code. "A signed-out visitor can submit the contact form." "Staff can refund an order."
Notice the first few words. Every check names who it runs as: one of your app's roles, or a visitor who is signed out. That's the part people skim past, and it's the part that does the work.
3. Open the app as that person
The role chips in the Features page header are the fastest thing in the editor. Click one and your live app opens in a new tab, in the test world, signed in as that role.
The test world is a separate copy of your data, seeded with sample rows written from your own pages, and reset before every run. Delete things. Refund a fake order. Try to break the signup. None of it reaches real users or real data. It's also exactly where checks run, so what you're looking at is what a check sees.
4. Let a build get stopped
This is the payoff. Every build is checked in the test world before it goes live. A change whose checks fail gets repaired a limited number of times, and if it still fails, it stops before Live. Your live app stays as it was. History shows the failed check statements right on the Checked step, so you read "Staff cannot see another customer's address" instead of a stack trace.
A few things are always checked without anyone writing them: the app builds, every page loads, and each service it uses still answers.
5. Decide on the new ones yourself
A check that fails its very first run goes to "Needs your OK" rather than blocking you, since it was written from the commit it failed on. Press Keep or Stop checking. Retiring one needs a reason, and it stays on the row. Insight can write checks and read results. It has no way to delete one. That asymmetry is the whole design.
My take after living with this: the checks worth writing are the negative ones. "A customer can see their own orders" is nice. "A customer cannot see anyone else's" is the one that saves you. Agents are good at making features work and careless about who else can reach them.
Checks and the test world are on Pro and Enterprise for Insight Projects. The details are at the checks docs and the test world docs, and the rest of the feature surface is at /en/docs/features.
If you want to try it on something small, DontCode is a decent place to spend an afternoon. More walkthroughs on the blog.