Safer Agents for Legacy Code

The safest way to put a coding agent into an old codebase is to start it small: one directory, one test target, one reviewer who owns the result. Most teams do not fail on the first prompt. They fail when an agent touches old code, moves fast, and nobody can explain why the diff is safe. A coding agent is a tool that reads your repo and proposes changes on its own, so the work here is governance, not cleverness. Claude Code, Anthropic's coding agent, gives you the same handles as Cursor and Codex for this: a memory file, scoped rules, and a place to gate tool access.

Give the agent one narrow slice

When an agent has broad access and a loose prompt, it wanders. It edits past the task, tidies nearby files, and brings old edge cases back as fresh bugs. Then your reviewer spends the afternoon reconstructing intent.

The fix is a slice the team already understands: one directory, one test target, one reviewer-owned outcome per task. Keep the agent inside a shape you can describe in a sentence, and the diff stays small enough to actually read.

Each tool has a home for that boundary. In Cursor, use a scoped .cursor/rules/*.mdc file instead of one giant repo rule. In Claude Code, keep durable repo memory in CLAUDE.md and push task-only notes into the prompt. In Codex, use AGENTS.md plus nested overrides so the instruction chain matches the folder you are in.

Gate every connector before you trust it

If the agent can reach every connector, every file, and every external system, your review problem gets bigger than your coding problem. Old systems make this worse, since they often hold the most sensitive data behind the least clean abstractions.

Treat MCP as a boundary, not a shortcut. Review each MCP server the way you would review a production integration: what data it can see, what it can change, and what consent the user has to give. The Model Context Protocol specification is explicit that tools can imply arbitrary code execution paths, so least privilege here is the floor, not a nice-to-have.

Make the agent show its work

If your reviewers only inspect the final diff, they miss the path the agent took to get there. That is how an unsafe change reads as reasonable in isolation.

Ask the agent to prove the change before it asks for approval: passing tests, a short rationale, and a rollback note. In Codex, that can live in a small loop around codex exec. In Claude Code, a hook can enforce checks before handoff. In Cursor, an agent-mode or background run should end with a reviewable summary, not just a patch. Once you require proof, review comments shift from "what is this?" to "does this test cover the edge case?"

Train on three files, not buttons

A lot of agent training teaches buttons and stops there. People learn how to invoke the agent but not when to stop it, and adoption stays shallow.

Teach the operating model instead, built around three files a person can hold in their head:

• One rule file that scopes what the agent may touch (.cursor/rules/*.mdc, CLAUDE.md, or AGENTS.md).
• One memory or policy file for durable context and exceptions.
• One review file: a pull request checklist the human owner signs off on.

Once the team carries those three, they have a habit, not a demo. That is what makes training on a legacy codebase actually stick. You can go deeper on the team side in training.

Run a two-week rollout

Here is a plan you can paste straight into the week's notes and follow service by service.

# Legacy-codebase rollout plan

- Pick one legacy service with clear tests and one owner.
- Add a scoped rule or memory file at the repo root.
- Define one allowed task shape: bug fix, test repair, or small refactor.
- Limit agent access to the minimum files and connectors needed.
- Require a verification loop: tests, rationale, and rollback note.
- Review every agent-authored PR with a human owner.
- Record one failure and one fix after each run.
- Expand scope only after three clean changes in a row.

Tighter boundaries will slow your first few tasks. That is the cost of keeping ownership with the team, and it pays back the first time a risky diff gets caught before merge.

Common questions

• How should I start using a coding agent in a legacy codebase?

  Start with boundaries. Give the agent one directory, one test target, and one reviewer-owned outcome, then grow from there. In Cursor that is a scoped .cursor/rules/*.mdc file, in Claude Code it is durable repo memory in CLAUDE.md, and in Codex it is AGENTS.md plus nested overrides that match the folder. Small slice first, brilliance later.

• When is it safe to expand an agent's scope in old code?

  Expand only after three clean changes in a row. Until then, keep everything small: one legacy service with clear tests and one owner, minimum file and connector access, a required verification loop, and one recorded failure and fix after each run. Three quiet successes is your signal that the operating model holds, not a hunch.

• How do I review an MCP server before connecting it?

  Review it like a production integration. Check what data it can see, what it can change, and what consent the user must give before it acts. The MCP specification is clear that tools can imply arbitrary code execution, so apply least privilege by default. Legacy systems often hold the most sensitive data, which makes a tight connector gate more important, not less.

• What proof should an agent attach before I review its change?

  Passing tests, a short rationale, and a rollback note, attached before it asks for approval. That receipt lets you judge the change instead of reverse-engineering it from the diff. Once your team requires it, review comments move from "what is this?" to "does this test cover the edge case?", which is the conversation you actually want to be having.

Your next move

Pick one repo and one rollout owner, then run the two-week plan above on a single legacy service. When it lands cleanly, standardize the next service with the agentic coding governance topic page.