Guide
Source-Backed AI Workspaces vs. Sandboxes
Sandboxes are good for experiments. Source-backed AI workspaces are for code that needs Git history, previews, logs, secrets, and deployment.
The difference shows up after the demo works: where does the code live, who can review it, and how does it become the next release?
A sandbox optimizes for the first run
A sandbox is useful when the goal is to try an idea quickly. You can prompt, inspect a prototype, and decide whether the shape is worth pursuing.
That speed has a boundary. Once the project needs review, repeatable builds, secrets, health checks, or production routing, the important asset is no longer the demo. It is the source state that produced it.
A source-backed workspace optimizes for the next change
In a source-backed AI workspace, the agent works against project files. The result is a diff, not a memory of a chat. Developers can run the app, inspect logs, commit the change, sync with Git, and continue from the same codebase next time.
That matters for AI-assisted teams because the model's context should be grounded in the app that actually ships. The next prompt should see the files, manifest, framework conventions, and recent changes rather than a pasted summary.
- —Review generated code as a file diff.
- —Keep deploy config beside the source.
- —Use previews and logs to test behavior.
- —Commit, revert, and branch through Git.
Choose based on where the work is going
Use a sandbox when the output can be thrown away. Use a source-backed workspace when the code needs an owner, a release path, or a future teammate.
Most production apps cross that line earlier than teams expect. The first API key, database table, custom domain, or webhook handler is usually the point where the experiment needs a real source and runtime contract.