I think mostly it is not messing up. Sometimes it does unwanted change. I have to review the agent's work before I can commit it -- if for nothing else than that it doesn't touch any unexpected files. It is rare but it happens often enough that I need to skim through a git diff to be sure that the changes are related to what I actually want done, and that sometimes I find that the agent didn't realize which component I wanted to change and it can have implemented the entire change into wrong file.

I find it rarely going off the rails, unless the code looks on superficial analysis to be completely incorrect, in which case it can helpfully attempt to fix it for you. To stop this, I typically request agent to write documentation explaining why something is done the way it is, so that it will stop trying to change it in the future. If you provide useful documentation, you will help yourself and the context-free agent that later stumbles on the same code and likely concludes again that it's something that it must change.

Project documentation helps. AGENTS.md file can cover exceptions and special cases. It can define coding style, and I find that the agent tries very hard to observe your instructions. At the same time, I advice not making the file extremely long or trying to cover lots of use cases by writing tons of examples, because long system is also counterproductive in terms of polluting the context and inference, and any mistakes in examples or discussion will just confuse the model and degrade performance you get out of the model one way or other. Watching the first reasoning traces after any changes is critical, especially if it suddenly spends dozens of seconds and writes 1000 tokens of reasoning, as this indicates that the model is arguing with itself about what you want or how it should interpret one clause or another.