GUIDE / 11 MIN READ
By Alex Cinovoj, Founder & CTO, TechTide AI · 13 years in US enterprise IT.
Give the agent a short operating manual (CLAUDE.md), make it plan before it edits, give it commands it can run to check its own work, scope what it is allowed to touch, keep the context window on one task at a time, review its diffs the way you would review a new colleague's, and put one named person in charge of the setup. Everything below is one of those seven things in more detail.
CLAUDE.md is read at the start of every session. The model will follow a page of precise instructions and skim ten pages of background. Keep it to the things that change behaviour: exact build, test, lint and typecheck commands; conventions the code does not make obvious; a short map of where things live; the files and systems that must not change without a human.
When the agent gets something wrong twice, the fix is one line in the file, not a longer prompt. Commit it with the code and review edits to it like source. The setup guide covers the initial version.
Ask for a plan first, in plan mode or simply by asking, and read it. A plan that names the wrong files, misses a call site or proposes a bigger change than the task needs is cheap to correct before any edit exists and expensive afterwards. Most bad diffs were bad plans that nobody read.
Keep tasks small. One behaviour change, one bug, one refactor per session. If a task needs three paragraphs to describe, it is three tasks.
An agent with no feedback loop cannot tell whether it finished. Put the test, typecheck and lint commands in CLAUDE.md and make "run them before reporting done" an explicit instruction. For anything with a visible result, describe how to check it: a curl against the dev server, a screenshot, a query.
This is the same discipline that decides whether an AI workflow can be trusted in operations. The agent eval suite note is the production-scale version of the same idea.
Claude Code asks before it runs commands or edits outside the working tree. Teams either click through every prompt until they stop reading them, or disable the prompts entirely. Both are wrong. Use the allowlist in the project's settings to pre-approve the specific commands the team trusts, such as the test runner and the package manager, and leave the prompt in place for everything else.
Fully unattended runs belong in a disposable environment: a container or VM with a scratch copy of the repository and no credentials that reach anything real. Never on a workstation that holds production tokens.
MCP servers give the agent access to context outside the repository: the issue tracker, a database, an internal API. That access is where most of the leverage and most of the risk lives. Start read-only. Use a project-scoped configuration under version control so everyone shares the same servers. Give each server the narrowest credential that works and point database servers at a replica.
Any tool that writes to a real system needs a human between the agent and the effect. The MCP security checklist and the prompt injection defense note explain why: content the agent reads through a tool can contain instructions, and an ungated write tool turns that into an incident.
The reasoning behind these habits is covered in context engineering for production agents.
The agent writes plausible code quickly. Plausible is not the bar. Review every change for scope creep, silent behaviour changes, deleted tests, and edits in files the task never mentioned. Ask for a commit message that explains why, not what. If the diff is too large to review, the task was too large; split it and start again rather than approving on faith.
For parallel work, separate git worktrees keep sessions from stepping on each other's changes.
Running the CLI with a prompt and no interactive session is the right shape for CI: a first-pass review on a pull request, a summary of a failing test run, triage labels on new issues. Keep those runs read-only and treat their output as a suggestion for a human, not an action. A pipeline that can both read untrusted input and write to a real system is the one setup to avoid.
Session counts and token spend measure activity. What you want to know is whether reviewed, merged, working changes are arriving faster and with fewer defects than before. Pick one team, one repository and one baseline period, and compare like with like. The AI ROI measurement note covers how to do this without fooling yourself.
CLAUDE.md, the MCP configuration and the permission policy are living configuration. Without an owner they decay within a quarter: commands go stale, a convenient credential gets added, the allowlist grows until it means nothing. One engineer owns the files, reviews changes to them, and updates them whenever the agent misbehaves in a way a line of instruction would have prevented.
Scoped tools, a verification loop, gated writes and a named owner are four of the conditions the Systems Decision Audit checks when it decides whether an AI workflow can be trusted in operations. If the thing you are building with Claude Code is the workflow your operation will depend on, the audit is the written answer to whether it is ready, with the evidence behind it.
Short enough to be followed in full. Commands, conventions the code does not make obvious, a brief architecture map, and the no-go zones. When it grows past a screen or two, move background material into linked docs and keep the manual lean. Nested CLAUDE.md files in subfolders carry the detail that only matters there.