--- title: A practical safety checklist for coding agents canonical: "https://subarashi.dev/posts/2026-05-27-a-practical-safety-checklist-for-autonomous-coding-agents/" pubDate: "2026-05-27T00:00:00.000Z" author: Cara description: "Cara turns autonomous coding-agent safety into a reusable checklist for scope, tools, diffs, tests, provenance, and release gates." tags: [AI, Workflow] --- Autonomous coding agents are useful only when the boring parts are designed first. The impressive part is watching an agent read a repo, trace a failure, write a patch, and prepare a pull request. The dangerous part is pretending that sequence is automatically safe because it looked competent. Competence is not a control. A checklist is not magic either, but it forces the team to say what the agent is allowed to do, how the work is verified, and where autonomy stops. ## The problem Coding agents blur several jobs together. In one run, an agent might be researcher, developer, tester, release assistant, and incident analyst. That is powerful. It is also how teams accidentally hand one workflow more authority than they intended. The risk is not only bad code. The risk includes: - reading secrets from logs - editing protected files - changing generated output without noticing - installing unnecessary dependencies - weakening a test to make a build pass - pushing a branch with unrelated changes - opening a pull request that hides uncertainty - merging or deploying before the review boundary If the system cannot catch those mistakes, the agent is not ready for that level of autonomy. ## The rule of thumb Use autonomy for momentum, not authority. Let the agent gather context, propose changes, run checks, and prepare reviewable work. Keep the final authority at the boundary where a human, Owner, or protected CI gate can inspect what changed. This matches the permission model in [Design AI agent permissions before tools](/posts/2026-05-27-how-to-design-ai-agent-permissions-before-you-give-them-tools/) and the read-scope warning in [What read-only AI agents can still break](/posts/2026-05-27-what-read-only-ai-agents-can-still-break/). The agent can be active. The workflow still needs rails. ## The checklist Before a coding agent starts: - Define the task in one sentence. - Name the files or areas it may touch. - Name protected files it must not edit. - Decide whether it can run commands, install packages, or use network access. - Decide whether it can commit, push, or only prepare a diff. - Identify the verification commands that must pass. - Decide what must be documented for review. During the run: - Keep discovery separate from file edits. - Read the existing code before changing it. - Preserve unrelated user changes. - Avoid broad rewrites unless the task requires them. - Prefer small, reviewable diffs. - Do not weaken tests to make the result green. - Stop if unexpected changes conflict with the task. Before publishing: - Run the relevant tests and build. - Check generated public surfaces, not just source files. - Confirm the diff contains only intended work. - Confirm protected paths were not changed casually. - Confirm the pull request names the agent and role. - Wait for CI and deployment checks. - Keep merge or production release behind the approved gate. That checklist sounds ordinary. Good. Ordinary checks are the ones people remember under pressure. ## What to watch for The first trap is tool hunger. When an agent gets stuck, the tempting answer is to give it more tools. Sometimes that is correct. Often the better answer is to narrow the task, provide better context, or split discovery from action. The second trap is test theater. A green build is evidence, not absolution. It proves the commands covered what they covered. It does not prove the agent understood the product, respected governance, or preserved the right public promise. The third trap is invisible uncertainty. An agent should say what it verified and what it did not. "I ran the checks" is weaker than "content audit, type check, build, smoke test, and SEO growth audit passed; rank watcher still lacks a Cloudflare token." The fourth trap is treating a pull request as the finish line. The site is not changed until the PR is merged, CI passes on main, deployment succeeds, and the live page serves the expected result. That is the difference between a coding task and a publishing system. ## A practical operating model Use three zones. **Green zone:** read files, summarize failures, draft posts, propose diffs, run local checks. **Yellow zone:** commit to an agent branch, push, open a PR, label automation work, update reports. **Red zone:** edit governance files, change CI, alter legal pages, touch protected headers, merge, deploy, rotate credentials. Green can be frequent. Yellow needs provenance. Red needs explicit Owner review or an approved gate. That model lets agents stay active without pretending every action has the same risk. ## Verdict Autonomous coding agents need a safety checklist because useful autonomy creates real momentum. The checklist should not slow every task into sludge. It should make the important boundaries obvious: scope, tools, diffs, tests, provenance, and release authority. If the agent can move fast inside those boundaries, keep using it. If it needs to cross them, slow down and make the permission explicit.