Rules for Autonomous Coding Agents

By Rogier Muller06.23.26

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

AI coding agents write code autonomously by reading the repo, choosing a plan, editing files, running tools, and iterating on errors until they produce a reviewable change. A team should not grant that loop unlimited access; it should govern it with repo rules, MCP boundaries, and code review guardrails.

Agentic coding is a workflow where an AI agent can take multiple steps toward a software task without being prompted for every file edit. In Cursor that means the Agent can use project context and tools, but the team still decides what safe autonomy looks like.

Define autonomy before you grant it

Start by deciding which tasks an agent may complete end to end. A safe first list is narrow: add a unit test, update a small component, refactor one module, or draft a migration plan without applying it.

This matters because autonomy is not one setting. Reading files, editing files, running tests, calling an MCP server, opening a pull request, and touching production data are different permissions with different risks.

Don't treat multi-agent orchestration as a substitute for engineering judgment. A Show HN project such as Saar is a useful signal that teams want orchestration, but orchestration does not tell your repo what is allowed.

During AI coding training, ask one plain workshop question: can we explain how AI coding agents write code autonomously here in one paragraph? If the answer is vague, the agent is not ready for broad permissions.

Put repo rules where coding agents read them

Put durable rules in files the agent can load every time. For Cursor users, that usually means a .cursor/rules/*.mdc rule for IDE behavior and an AGENTS.md for repo-level conventions that other coding agents can also understand.

Use nested files when a directory has its own constraints. A payments service, mobile app, or migration folder should not inherit only one flat root policy if local rules matter.

Do not leave rules in a wiki and expect an AI IDE to follow them. If the rule affects code, put it near the code.

A good repo boundary names what the agent may do, what it must ask about, and what it must never do. Keep it short enough that a teammate would actually read it during review.

Paste this team convention

Use this as a starting convention. Paste it into a repo proposal, then split the two file sections into .cursor/rules/agent-autonomy.mdc and AGENTS.md once the team agrees.

<!-- .cursor/rules/agent-autonomy.mdc -->
---
description: Agent autonomy boundaries for reviewable changes in this repo
alwaysApply: true
---

# Agent autonomy rule

The agent may:
- Read repository files needed for the task.
- Edit files inside the stated task scope.
- Run local formatters, linters, type checks, and tests.
- Create or update tests for changed behavior.
- Summarize unresolved questions before expanding scope.

The agent must ask before it:
- Changes public APIs, database schemas, auth logic, billing logic, or deployment config.
- Adds a new dependency.
- Calls an external MCP server that can read private data or write to another system.
- Deletes code it cannot prove is unused.
- Touches more than 8 files or more than 400 changed lines.

The agent must never:
- Read, print, transform, or commit secrets.
- Make production data changes.
- Bypass failing tests without naming the failure and the reason.
- Merge its own pull request.

Review checklist:
- The diff matches the requested task.
- The agent included the commands it ran and the results.
- Tests cover the behavior change or the PR explains why not.
- MCP/tool calls were necessary and within the approved boundary.
- A human owner reviewed risky areas: security, privacy, billing, migrations, auth.

<!-- AGENTS.md -->
# Repository agent guide

Architecture:
- Keep domain logic in `src/domain`.
- Keep UI-only state in `src/ui`.
- Do not import database clients into React components.

Workflow:
- Prefer small diffs over broad rewrites.
- Update tests with behavior changes.
- Use existing project scripts before adding new tooling.
- Leave a short handoff note with changed files, test results, and open risks.

Escalation:
- Ask a maintainer before changing schemas, permissions, pricing, telemetry, or CI/CD.

The adoption path should be boring. One engineer proposes the convention in a pull request, the owning team reviews it, and the final version lives in the repo beside the code it governs.

The enforcement rule is just as important: no agent-authored PR gets merged unless the review checklist is complete. That rule turns AI coding governance from a slide deck into a habit.

Treat MCP access as a boundary, not a bonus

Model Context Protocol, or MCP is a standard way for agents to connect to external tools and data sources. In practice, it can give coding agents access to systems like GitHub, Slack, Jira, Figma, databases, or internal documentation.

Give the agent the smallest useful set of tools. A read-only docs MCP server is very different from a database tool that can run writes, and both should be named in the repo convention.

Do not approve a tool because it is convenient during a demo. Convenience compounds when an autonomous agent can chain calls, inspect context, edit code, and propose a PR in one loop.

As of June 2026, a lot of coding agents news focuses on orchestration platforms and multi-agent work. The practical team question is still simpler: which tool calls are allowed for this repo, for this task, under review?

Review agent work as a system change

Review the agent's process, not only the final diff. Ask what context it used, what commands it ran, what assumptions it made, and where it expanded beyond the original task.

This is where developer productivity actually improves. Small, well-governed autonomous changes save time because reviewers can trust the shape of the work before they inspect every line.

Avoid treating human review as a rubber stamp after a large diff. Once a change crosses module boundaries, alters risk-sensitive code, or relies on external tool calls, review should slow down.

A useful pattern is to assign a human reviewer plus a narrow reviewer agent role. For example, a Cursor Agent pass can check whether the PR obeys .cursor/rules/agent-autonomy.mdc, while the human reviewer owns correctness and judgment.

Train the team on conventions, not prompt tricks

Run engineering team training around the operating model: rules, MCP boundaries, review checklists, and escalation paths. Prompt examples help, but team skills come from shared conventions that survive across Cursor, Claude Code and OpenAI Codex tooling.

This is the difference between agentic coding as a personal trick and AI coding for engineering teams. The first works until someone changes tools; the second works because the repo carries the rules.

Do not teach only the fastest path. Training should cover failed runs, bad assumptions, over-broad diffs, and when to stop the agent.

For a deeper rubric on deciding what an agent is allowed to do, read Skill Rubrics for Coding Agents. For a broader training path, see AI coding governance.

Start with one repo

Pick one low-risk repository, paste the convention, and require the checklist on every agent-authored PR for two weeks. Then expand only the permissions your reviewers can explain with confidence.