What I Let a Coding Agent Touch, and What I Don't

I build client sites with an AI coding agent. Plenty of developers do now, whether or not they mention it. So the useful question isn't whether your developer uses one. It's what stops the agent from changing something it shouldn't.

I learned where that line sits the expensive way, on my own site, before it could happen on a client's.

The Folder Is the Scope

The first time I used a coding agent for real work, I asked it to build a small standalone tool for a different project. I expected a few files I could hand to the developer on that project.

I had my studio website open in the editor at the time. So the agent built the tool inside my website's folder. To make its tool run, it also edited three of my site's own configuration files: package.json, package-lock.json and tsconfig.json.

My prompt never mentioned the website. It didn't need to. An agent works in whatever folder it's started in, and everything in that folder is within reach. The scope is the folder, not the prompt.

Nothing broke, because none of it was committed. I found it about two weeks later, when git status listed three files I hadn't touched. Undoing it took four steps: remove the tool's folder, restore the three files, reinstall dependencies from the lockfile, and check that git status came back clean.

If I'd been in the habit of committing everything in one go, those changes would have gone into my site's history and out to the live server with the next deploy.

Rules in a Chat Don't Reach the Agent

On another project, I spent a long time in a chat working out how the agent should behave. One branch per task. The agent opens a pull request and never merges its own work. Secrets never go into the repository; only an example file with empty values does.

Good rules. But they lived in that conversation. When the building started, I passed them to the agent in my prompt, which works for that one session. The next session starts fresh, from the instruction files in the project itself: CLAUDE.md or AGENTS.md. That project's CLAUDE.md contained a single line pointing to another file. None of the rules were written where a new session would find them.

The first draft of those rules was also wrong, which I only found out because I asked a second AI to review them. "Never commit to main" is impossible in a brand-new, empty repository, since the first commit has to land somewhere. And the rules told the agent to run a lint script the project didn't have. Rules for an agent need testing like code does.

What I Do Now

1. One project per folder, opened on its own. The agent gets the folder it's meant to work in and nothing beside it.

2. Rules go in the file the agent reads at startup. This site's CLAUDE.md now has a rule I added after reviewing my commit history: no AI attribution lines in commit messages. It's a small rule, but it's in the file, so every session follows it without me repeating it.

3. Read the framework's own instructions. Next.js 16 ships an AGENTS.md in every new project. It tells the agent that the framework has breaking changes the agent's training may not include, and to read the documentation bundled with the installed version before writing code. Following that instruction is how I confirmed that the documented signature of a Next.js analytics function had changed. The old form had been silently dropping every custom event on this site.

4. Permission level follows risk. On an early, low-stakes project, I let the agent apply changes without asking each time. On my own site and on anything a client or visitor will see, I review each step before it's applied. Speed matters less on a live site than knowing what changed.

5. git status before every commit. It's the check that caught the folder problem, and it costs five seconds. If it lists a file I don't expect, I stop and find out why before anything else.

None of this is specific to one agent or one framework. It's the same discipline you'd want from a junior developer on their first week, written down so it doesn't depend on anyone remembering it.

Four Questions to Ask Your Developer

If you run a clinic or a course business and someone is building or maintaining your site, these are fair questions. You don't need to understand the technical answer. You need to hear that there is one.

1. Do you use AI coding agents on my project? "Yes" is a perfectly good answer. Not being sure is the problem.
2. Where are the agent's rules written down? The answer you want is a file in the project, not "I keep it in mind."
3. Can anything the agent writes reach my live site without a person reviewing it first? It shouldn't.
4. Where are my site's keys and passwords kept, and can the agent ever commit them? Payment, email and database credentials should live in environment settings, never in the code.

If the answers are vague, the risk isn't that AI is involved. It's that nobody decided where its limits are.