Give the agent a sandbox, not production
Worktrees, branch policies, and human gates — how to use agents without torching the monorepo.
Agents fail loudly in files and quietly in state. The difference between a useful session and a disaster is usually isolation.
Blast radius checklist
Before tools are enabled, decide:
| Surface | Default for agents |
|---|---|
| Branch | dedicated, never main |
| Working tree | git worktree or clean clone |
| Secrets | none in shell env you paste |
| Network | allowlist if you can |
| Deploy / push | human approval |
rm, migrate, force-push | hard deny or explicit confirm |
If the agent can git push --force to default, you do not have a coding agent. You have a chaos monkey with a language model.
Worktrees beat “stash and pray”
git worktree add ../app-agentic -b agent/foo
cd ../app-agentic
# agent works here
Benefits:
- your main checkout stays usable
- parallel agents do not clobber each other
- easy to delete the whole experiment
Human gates that actually help
Not every step needs a human. These do:
- First plan on ambiguous product work
- Schema / migration changes
- Auth, billing, permissions
- Anything that leaves the machine (push, publish, email, prod API)
- Dependency major bumps
Autonomous inside the fence. Stateful outside it.
Context is a resource
Agents do not “know the repo.” They see what you (or the tool layer) stuffed into the window.
Prefer:
- search → open only relevant files
- small diffs over rewrites
- “read the test first” before editing production code
Dumping the whole monorepo into context is how you get confident edits to the wrong package.
Decision rule
Autonomy scales with reversibility.
| Reversible? | Autonomy |
|---|---|
| Local branch, tests only | high |
| Shared staging | medium + logs |
| Production data / customers | low / pair only |
Agentic development is powerful because it multiplies action rate. Your controls must multiply undo at least as fast.
get new posts
Occasional notes on agentic development. No spam.