Eyeballing a few examples doesn't scale
It's tempting to tweak a prompt or adjust a tool's description, try it on two or three examples, see that it looks better, and ship it. The problem is that a change which improves behavior on the cases you happened to test can silently break behavior on cases you didn't. Prompts and tool definitions are entangled in ways that aren't obvious. Rewording an instruction to fix one failure mode can easily shift the model's behavior on an unrelated case that was previously working fine, and you'll have no idea until a user hits it in production.
The practical fix is the same idea software engineering has used for decades: a test suite. Build a fixed set of representative test cases, real or realistic inputs paired with a known-good expected behavior or output, and run every candidate change against the full set before shipping. This turns 'I think this feels better' into 'this passed 47 of 50 known cases, and here are the 3 that regressed.'