Keeping humans in the loop.

This is the lesson that keeps an agent an asset rather than a liability. None of it is exotic. It's mostly the disciplines you already apply to human contributors, held to just as firmly when the contributor is an agent. Get these habits right and you can move fast without the part where it goes quietly wrong.

Review every diff, full stop

The non-negotiable habit: an agent is a contributor, and you read its work like any other contributor's. Every diff gets a real review before it merges, the same scrutiny you'd give a capable junior. The trap is that agent output looks polished and the tests are green, so it's tempting to wave it through. Resist that. Green tests prove the code does what the tests check, not that it does the right thing, handles the edge you forgot, or avoids a subtle issue the suite never covered. Read it like you mean it: is the approach sound, is anything off, would you have written it this way? Confidence in the output is not the same as correctness, and the review is where you supply the judgement the agent can't. Keeping the work in a normal branch and pull request makes this natural, since the diff is right there to read.

Connect tools through MCP carefully

One of the powerful things about Claude Code is that it can reach beyond your code through MCP, the Model Context Protocol, to connect real tools and data: your issue tracker, a database, documentation, other services. Useful, and worth a moment's care, because every connection you add is something the agent can now touch. Keep it tight:

• Only what a task needs. Don't wire up everything you have just in case. Add the connection the job calls for, and leave the rest off.
• Least privilege on every connection. Give each one read-only or narrowly scoped access where you can, not broad write access to a live system.
• Trust the source. Only add MCP servers you trust, the same way you'd vet any dependency you pull into a project. An untrusted connection is an untrusted input.

Treat MCP connections as part of the permission picture: more reach means more to review, so scope each one to the job in front of you.

Keep production secrets well clear

This is where the real damage lives, so it gets its own rule. Never expose production secrets to an agent. Don't paste live API keys, database credentials or production tokens into a task because it might need them. Two habits keep you safe:

• Least privilege, always. If a task genuinely needs access to something, give it a scoped, least-privilege token that can do that one thing and nothing else, never a broad credential and never the access you'd give a senior engineer with full trust.
• Secrets live outside the work. Keep them in your secrets manager or environment, never committed to the repo and never in the task description. If a diff would ever print or commit a secret, that's a hard stop in review.

The test is simple: if this token leaked through a bad diff or a logged error, how bad would it be? Scope every grant so the honest answer is "not very."

Know what not to hand over

From the last lesson, but it bears repeating here as a safety rule, not just a productivity one: keep architecture, security-critical paths and ambiguous product calls with people. Handing those to an agent isn't just lower quality, it's a risk, because a confident wrong answer on auth or payments is exactly the kind of mistake that's expensive to catch and worse to ship. Delegate the well-defined, low-risk work. Own the decisions and the dangerous paths.

Use hooks and CI as guardrails, and keep it auditable

For guardrails that fire automatically, Claude Code has hooks: shell commands that run at set points in its work, say to format and lint after an edit, or to block a command you never want it running. Because a hook is your own code rather than a polite request in a prompt, it runs every time without depending on the agent choosing to comply, which makes it a dependable backstop for the rules you care most about. Your pipeline does the rest of the heavy lifting, so make it earn its keep too. The agent works on a branch and opens a pull request; protected branches, required status checks and required reviews mean nothing reaches main without passing the tests and getting a human sign-off. If your coverage is thin in an area you're handing to an agent, that's a strong reason to thicken it, because the tests are how you catch a confident mistake automatically before a person even looks. There's a quiet bonus to doing it all through normal version control: it's auditable by default. Every change is on a branch, in a pull request, with a CI record and a named reviewer who signed off. Months later you can see exactly what changed, why, and who approved it. That trail matters anywhere you answer to a customer, a standard or an auditor, and it's free if you keep the agent inside your ordinary review flow rather than letting it work around it.