Rules for Autonomous Coding Agents

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, Anysphere's AI code editor, 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.

The trap is treating 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, Anthropic's coding agent, and OpenAI Codex, OpenAI's coding agent 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 the related training topic.

Common questions

• How do AI coding agents actually write code on their own?

  AI coding agents write code on their own by looping through context gathering, planning, file edits, tool calls, and test feedback. The important caveat is that every loop should leave a review trail: changed files, commands run, test results, MCP calls, and open assumptions.

• Should we use one AGENTS.md or nested rules?

  Use one root AGENTS.md for global repo rules, then add nested files when a directory has different risks or architecture. A simple threshold is useful: if reviewers regularly say “this folder works differently,” give that folder its own agent guidance.

• Where should MCP access stop?

  MCP access should stop before the agent can make irreversible or sensitive changes without approval. A practical boundary is read-only by default, write access by explicit exception, and no production data writes from an autonomous coding task.

• Do we need an AI coding workshop before turning this on?

  You do not need a large workshop before trying agentic coding, but you do need a shared convention before broad rollout. A 60-minute AI coding workshop can align the team on allowed tasks, MCP boundaries, review guardrails, and the first repo checklist.

Further reading

• Cursor — Agent
• Claude Code — getting started
• OpenAI Developers — Codex quickstart
• Model Context Protocol — specification
• GitHub — openai/codex
• GitHub — anthropics/skills
• OWASP — Top 10 for Large Language Model Applications
• NIST — AI Risk Management Framework
• Google Search Central — helpful, people-first content
• Google Search Central — generative AI content guidance

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.