Setting it loose safely.

An agent that can edit your code and run commands is powerful, and power in a codebase wants guardrails. The good news is the safe setup is mostly things you already believe in: tight scope, good context, least privilege, and a green pipeline before anything merges. Here's how they come together when the contributor is an agent.

Scope the task like you mean it

The single biggest lever on getting a good change back is a tight brief. A vague task ("clean up the auth code") gives the agent room to wander, touch more than it should, and make decisions that were yours to make. A scoped task gives it a target and a finish line.

• One clear goal. "Add validation so the signup endpoint rejects empty emails with a 400," not "improve signup."
• A definition of done. Say how you'll know it worked: a new test passes, the existing suite stays green, the endpoint behaves a certain way.
• Boundaries. Name the files or area it should stay in, and say what's out of scope, so a small job doesn't sprawl across the codebase.

If you can't scope a task this tightly, that's a useful signal: it may not be agent work yet, or it needs you to break it down first. Either way you've learned something before you spent any time.

Give it the context a new hire would need

The agent only knows what's in the repo and what you tell it. So treat it like a sharp new starter on day one: capable, but blank on your conventions. Codex reads a project instructions file, an AGENTS.md in your repo, that gets loaded with every task. That's the place to write down what a new engineer would otherwise have to absorb:

• How to run the build, the tests and the linter.
• The conventions you actually care about: structure, naming, the patterns to follow and the ones to avoid.
• Anything load-bearing and non-obvious, the gotchas that trip people up.

A good instructions file is the highest-leverage thing you can do. Time spent here pays off on every task afterwards, the same way good onboarding docs pay off with every hire.

Lean on the sandbox and least privilege

An agent should run with the least access it needs to do the job, and no more. The cloud form does a lot of this for you by working in an isolated sandbox, off your machine and away from your environment. Wherever it runs, hold to the same rule you'd use for any account: minimum permissions, scoped to the task. Don't hand it broad write access or production credentials because it might come in handy. If a job genuinely needs network or a service, grant the narrow thing it needs, not the keys to everything. We give secrets their own lesson, because they're where the real damage lives.

Start small, then widen the leash

Don't begin with a high-stakes change to your core system. Begin where a mistake is cheap and easy to spot, and let trust build from there:

• Read-only or analysis first. Ask it to explain a module, find where something is handled, or propose an approach, before you let it write anything.
• Then low-risk changes. Add a test, tidy a function, fix a small bug with clear reproduction steps. Watch how it works and how it reasons.
• Widen as it earns it. Once you trust the pattern on small jobs, hand it larger, still-well-scoped ones. Permissions and trust expand together, never ahead of each other.

Make CI and branch protection the backstop

Here's the reassuring part: the agent works on a branch and opens a pull request, which means your existing safety net catches it just like it catches everyone else. Protected branches stop anything landing on main without passing the gates. Required status checks mean the tests and linters have to be green. Required reviews mean a human signs off before merge. None of this is agent-specific, and that's exactly why it works: an agent is a contributor, and your pipeline already knows how to keep contributors honest. If your branch protection and CI are solid, you've done most of the safety work already. If they're thin, shore them up before you lean on an agent, because they're the floor under everything else.