Set up your workbench
Four things must be true before your agent can be trusted with anything. Most of them are about being able to undo.
Agent work is fast, and fast mistakes need cheap reversal. Before the first real session, get these in place.
1. Version control discipline
Work on a branch, always. Commit before you start a session and after each session you accept. This is not ceremony: the commit boundary is your undo button, and it is also how you read what the agent did, since a diff of one session is reviewable in a way that a diff of six sessions is not.
git switch -c feat/session-scoped-work git status --short # must be clean before you start # ... one session of agent work ... git add -p # read it as you stage it git commit -m "..."
2. A fast, honest check command
Your agent needs a way to find out whether it broke something, without asking you. One command that type-checks, lints, and runs the fast tests. If it takes four minutes, the agent will run it once; if it takes fifteen seconds, it will run it constantly and fix its own mistakes before you ever see them.
"scripts": {
"check": "tsc --noEmit && eslint . && vitest run --changed"
}Any language, same idea: make check, cargo clippy && cargo test, ruff check . && mypy . && pytest -x -q. Name it the same thing in every repo so your standing instructions can just say "run the check command".
3. A permission posture you have actually thought about
Every harness has a permission mode: which tool calls run without asking. The two defensible postures are ask before anything that writes or executes, while you are learning the agent's habits, and auto-approve reads and the check command, ask for everything else, once you trust it. The indefensible one is approving everything on a machine with production credentials in the environment.
Watch out
If you want to run with broad auto-approval — and for long unattended runs you will — put the agent in a container or VM with no credentials it does not need. Autonomy and blast radius are separate dials. Turn the first one up only after you have turned the second one down.
4. A scratch log
One file, notes/agent-log.md, gitignored. Each session: what you asked, what you had to correct, what surprised you. It feels like overhead for three days. In Module 05 it becomes the first draft of your project brief, written from evidence instead of from guessing.
Try it
Set all four up in your practice repository now. Then time your check command. If it is over sixty seconds, spend twenty minutes making a faster subset — it will pay for itself before you finish Module 04.
Takeaways
- Commit before and after every session; the session-sized diff is the unit of review.
- One fast check command is the single highest-leverage thing you can give an agent.
- Autonomy and blast radius are separate dials — lower the second before raising the first.
Why does check-command speed matter more than check-command thoroughness?
Because speed determines how often the agent runs it inside a session. A fast check turns into a tight self-correction loop the agent runs on its own; a slow one gets run once at the end, by which point the mistake is buried under later work. Keep the thorough suite for CI.
A course by Pieter Zandbergen