Why does it do this when I never asked?

Because it was built to be useful, and clumsy wording or uneven spacing looks like a problem worth solving. With no instruction to the contrary, improving things in passing seems like the right behaviour to it.

Doesn't the "go back" feature protect me?

Only partly. It recovers edits made through the file editing tools, but not those made by system commands — a file moved or deleted that way does not come back. The official documentation states this plainly.

It changed things I never asked it to change

Q: How do I know exactly what it touched?

Ask at the end of every task: "list every file you modified and what you changed in each". Thirty seconds of reading that saves you from discovering a change three weeks later.

You ask for a button colour. It changes the colour, and the spacing, and the wording above it that it found "clearer this way". You only notice three days later, hunting for the reason a page you liked no longer looks anything like the one you remember approving.

An AI takes initiative when nothing stops it: it believes it is helping by improving whatever it passes. Ask for the list of everything it modified after each task, and explicitly forbid unrequested improvements. Without that, you discover the changes weeks later.

Why it takes initiative

An AI that codes was shaped to be useful. When it passes clumsy wording, uneven spacing or an approach it considers dated, it sees a problem to solve — not something that is none of its business.

With no instruction to the contrary, improving things along the way looks like exactly the right behaviour. It hides nothing: it simply does not think to mention what, from where it stands, went without saying.

The outcome is the same either way: you find out long afterwards, once you can no longer tie the change to a specific request or remember what the earlier state looked like.

Seeing what it touched, before you close

One sentence, at the end of every task:

“List every file you modified, and what you changed in each.”

Thirty seconds of reading. It is the best effort-to-result ratio in the whole relationship with a tool that codes.

And when something in the list surprises you, ask it to pinpoint the gap between your request and what it did — and to justify it.

The “why” is not politeness. It often reveals a genuine reason — something that really was blocking the rest — and sometimes a plain aesthetic preference, which has no business being there.

What “go back” does not recover

Modern tools keep track of their own edits and offer to undo them. That is useful, and it is incomplete — the official documentation lists the gaps itself.

Anything done through a system command is not tracked. A file deleted, moved or copied that way does not come back. That is precisely the category of change hardest to spot and most expensive to lose.

Edits from an assistant running in the background are not covered either, in most cases. Recovering those needs a version control tool.

Changes made outside the tool are not captured, nor are those from another session open on the same project at the same time.

And the history disappears after a month. In other words: this feature undoes the mistake from ten minutes ago, it does not protect a project over time. For that you need real version control — the documentation says so itself.

The instruction that removes the problem at the source

Three rules in the file your tool re-reads at every start, each with a distinct job.

One that bounds the scope: nothing beyond what was asked, and anything else gets flagged rather than done.

One that protects what already works from the urge to make it cleaner. This is the one most often missing, and it is what stops Monday from breaking what worked on Friday.

One that makes the rest checkable: an inventory of edits at the end of every task. Without it, the first two rest on trust.

All three sit in the free kit’s ten ground rules, written as orders you can check rather than as intentions.

The real cost, which is not the obvious one

A surprise edit can be repaired. What cannot be repaired is what it does to the way you work: the moment you no longer know whether your project moved while you were looking elsewhere, you reread everything, you doubt everything, and you slow down.

A frame is not there to stop it doing wrong. It is there so you no longer have to supervise.