Fencing the change so it stays where you put it

The unrequested refactor

You ask for a cancel button. The diff shows changes in nine files. Somewhere in there the agent renamed a database column it thought was unclear, replaced your date handling with a library, and reorganised a folder.

None of it was malicious and some of it might even be improvements. It is still a problem, because you now cannot review the change you asked for (it is mixed in with four you did not), and if something breaks next week you have no idea which of the five caused it.

The fix is a fence, stated in the request.

What a fence looks like

Add a Cancel button to BookingRow.tsx.

Change only these files:
  components/BookingRow.tsx
  app/api/bookings/[id]/cancel/route.ts   (new)

Do not modify the schema. Do not modify lib/queries.ts beyond
adding one function. Do not add dependencies. Do not rename
anything. Do not reformat files you touch.

Six lines of restriction for one line of request. That ratio is correct and it will feel excessive until the first time it saves you.

“Do not reformat” earns its place on its own: a tool with different formatting settings can turn a three-line change into a 400-line diff, and a 400-line diff does not get read.

The standing fences

Some restrictions belong in the rules file so you never type them again:

- Never change the database schema without asking first.
- Never edit files in drizzle/migrations/. They are history.
- No new dependencies without asking.
- Do not refactor code I did not mention.
- Do not change formatting in files you are editing for another reason.
- Never edit .env or anything in .git.

The migrations one matters more than it looks. A migration that has already run is a record of what happened to the database. Editing it does not change the database; it makes the record lie, and the next person to set up the project gets a different schema from yours.

Ask for the plan first

For anything non-trivial, one extra round trip:

Before writing code: list the files you will change and one line
on what changes in each. Wait for me to confirm.

The plan arrives in twenty seconds and is easy to evaluate. Half the time you will see a file in the list that has no business being there, and correcting it at that point costs nothing. Correcting it after the change means reading and reverting.

This is also the cheapest way to catch a misunderstanding. A plan that says “modify the payment handler” in response to a request about display formatting tells you the model has understood something else entirely, and it tells you before any code exists.

Fences do not enforce themselves

A model can ignore a fence. It is text, not a permission system, and an agent convinced that a change requires touching another file will often touch it and mention this politely in its summary.

So the fence is a filter, not a guarantee, and the actual enforcement is git diff --stat:

git diff --stat
# components/BookingRow.tsx        | 24 ++++++++++
# app/api/bookings/[id]/route.ts   | 41 +++++++++++++++
# lib/dates.ts                     | 96 +++++++++++-------------

That third line is the one to notice. You did not ask for lib/dates.ts and 96 lines changed in it. Ask why before you go any further, and be willing to say revert that file and do the task without it.

Fencing time as well as files

The same idea applies to how long a run goes. “Do this one thing and stop” is a fence. Without it, an agent that finishes early will look for adjacent work, and adjacent work is exactly the category you did not review.

A useful closing line for any request: when you are done, stop and summarise. Do not start anything else.

When to take the fence down

Greenfield work in a directory nobody depends on. A prototype you intend to throw away. Mechanical changes with a build or a test to catch mistakes. In those cases the fence costs more than it saves.

The rule of thumb: fence in proportion to how much working code is nearby. On an empty folder, let it run. In the file that handles payments, name every line it may touch.