Working with an AI coding agent on a large codebase often feels like herding cats: it starts strong, then drifts into unrelated files, refactors code you didn’t ask about, or fixates on a minor style issue while ignoring the actual bug. This guide gives you practical, step-by-step techniques to keep the agent on task, reduce wasted tokens, and get predictable results—even when the repository has thousands of files.
What You’ll Need
- A codebase you can access locally (or a remote one the agent can read).
- An AI coding agent tool (e.g., Claude Code, Cursor, GitHub Copilot, or similar) that supports custom instructions or system prompts.
- Basic familiarity with your terminal or IDE and with Git (for reverting changes if needed).
- A clear idea of the task you want done—vague goals lead to vague results.
Step-by-Step
- Define the task in writing before you start. Write a single sentence that states the goal, the files you expect to change, and what you do not want touched. For example: “Fix the login bug in
auth/login.tsby updating the token refresh logic. Do not modify any other files.” Put this in your prompt or as a top-level instruction. - Set explicit scope constraints. Tell the agent which directories or files are in scope and which are off-limits. Use absolute paths or glob patterns if your tool supports them. For instance: “Only edit files under
src/; never touchtests/ordocs/.” If the agent can see a file tree, point it to the relevant folders. - Provide a minimal context window. Instead of letting the agent scan the whole repo, give it the specific files or symbols it needs. Paste the relevant function, class, or configuration snippet directly into the prompt. If your tool supports file references (like
@file:src/auth/login.ts), use them—but only include what’s necessary. - Use a system prompt or custom instructions file. Many agents read a file like
CLAUDE.md,AGENTS.md, or a project-level prompt. Add rules there, such as: “Always check for existing tests before writing new ones.” or “Never reformat code unless explicitly asked.” This keeps the agent consistent across sessions. - Break the task into small, verifiable steps. Instead of “Refactor the payment module,” ask for one thing at a time: “Rename
PaymentServicetoBillingServiceand update all references.” After each step, review the changes before moving on. This prevents the agent from going off on a tangent. - Use the agent’s planning mode if available. Many agents have a “plan” or “think” mode where they outline their approach before editing. Ask it to first produce a short plan: “List the files you’ll change and the exact modifications you’ll make.” Review that plan and correct any misunderstandings before allowing edits.
- Pin dependencies and lock files. If the agent might run commands (like
npm installorpip install), ensure your environment is stable. Use a lockfile (package-lock.json,poetry.lock) and instruct the agent not to modify it unless necessary. Uncontrolled dependency changes can cause the agent to go down a rabbit hole. - Monitor and interrupt early. Watch the agent’s output in real time. If it starts editing files outside the scope, stop it immediately. Most tools have a cancel button or you can send a new message saying “Stop. Revert to the last commit and only edit
src/auth/.” - Use Git for safety and rollback. Before each agent run, commit your current state or create a branch. That way, if the agent makes unwanted changes, you can revert cleanly without losing work. After the agent finishes, review the diff carefully before merging.
- Provide feedback after each run. If the agent did well, say what worked. If it drifted, tell it exactly where it went wrong. This helps the agent adjust its behavior in the same session and improves future sessions if the tool learns from history.
Common Mistakes
- Giving too much context. Pasting the entire codebase or large files overwhelms the agent and encourages it to explore unrelated areas. Keep context tight.
- Vague instructions. “Improve performance” is not actionable. The agent will guess, and guesses often lead to widespread changes.
- Not setting boundaries. Without explicit “do not touch” rules, the agent may refactor, rename, or reformat code that was already fine.
- Letting it run unattended. Even with good prompts, agents can get lost. Check in frequently.
- Ignoring the agent’s plan. If the agent proposes a plan that doesn’t match your intent, correct it before it starts editing. Skipping this step almost guarantees wasted effort.
Tips
- Use a “definition of done” in your prompt. For example: “Done means the login flow passes the existing tests and no other files are changed.” This gives the agent a clear stopping point.
- Leverage code search tools. If your agent has a search function (like ripgrep or a semantic search), use it to locate relevant code instead of letting the agent scan everything.
- Create a project-specific instruction file. Add a
CLAUDE.mdorAGENTS.mdwith your team’s conventions, such as “Use TypeScript strict mode” or “Never useany.” This reduces the chance of the agent making stylistic changes. - Ask for a diff summary. After the agent finishes, have it produce a concise summary of what changed and why. This makes review faster and catches unintended edits.
- Use multiple agents for different tasks. If your tool supports it, keep one agent for bug fixing and another for feature development. This prevents cross-contamination of context.
Troubleshooting
The agent ignores your scope and edits other files. Stop the session immediately. Revert the changes with git checkout -- . (or your preferred method). Then restart with a more explicit constraint: “Only edit src/auth/login.ts. Do not edit any other file. If you need to change another file, ask me first.” Some tools allow you to set a “read-only” mode for certain directories—use that if available.
The agent keeps asking clarifying questions instead of working. This usually means your prompt is too vague. Provide more detail: include the exact function name, the expected behavior, and what you’ve already tried. If the agent still asks, answer its questions directly and then say “Proceed with the plan.”
The agent produces code that doesn’t compile or fails tests. First, check if the agent ran the tests itself—many tools don’t by default. Instruct it to run the relevant test suite after making changes. If it still fails, ask the agent to debug the error, but limit its scope to the files it already touched.
The agent goes off on a refactoring spree. This is common when the task is open-ended. In your prompt, explicitly say “Do not refactor code that is not directly related to this task.” If it happens mid-run, interrupt and say “Stop refactoring. Revert all changes and only make the minimal fix.”
The agent doesn’t understand the codebase structure. Give it a high-level map in the prompt: “The project is a Django app. Models are in models/, views in views/, and templates in templates/.” This helps the agent navigate without scanning everything.
Frequently Asked Questions
Q: How do I prevent the agent from modifying my lock files?
A: Add a rule to your system prompt or instruction file: “Never modify package-lock.json or poetry.lock unless explicitly asked.” Also, run the agent in an environment where you can revert those files quickly.
Q: What if the agent needs to see a large file but I don’t want to paste it all?
A: Use the agent’s file reference feature (like @file:path/to/file) if available. If not, extract the relevant function or class and paste only that snippet.
Q: Can I use multiple agents on the same codebase simultaneously?
A: Yes, but be careful—they may conflict with each other. Use separate branches or have them work on different directories. Always merge and test carefully.
Q: How do I make the agent follow my coding style?
A: Include style rules in your instruction file (e.g., “Use 2-space indentation, single quotes, and no semicolons”). Also, provide a small example of your preferred style in the prompt.
Q: Is it better to give the agent a very detailed prompt or a short one?
A: For large codebases, a detailed prompt with clear scope is better. Short prompts invite the agent to explore and make assumptions. But don’t overload it with irrelevant details—only include what’s necessary for the task.
Q: What should I do if the agent makes a change that breaks something?
A: Immediately revert the change (using Git) and then ask the agent to analyze the failure. Provide the error message and ask it to fix only that issue. If the agent can’t fix it, you may need to manually debug or roll back to a previous commit.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.
More cards in this drawer
- Refillable Photo Printers: Match to Your Prints
- Right Technology Tools for Schools: A Practical Guide
- Your Account Has Been Disabled? Fix It Now7 days
- Name Lookup Scope Problem: A How-To Guide
- Razer Synapse Not Detecting Mouse? Fixes That Work
- Inaccessible Shared Printer KB5005565: Fix Guide