> [..] my rules do say: verify all changes with tests
replyI am a bit surprised that you're disappointed that it does exactly what you told it to - people usually have the opposite complaint.
If you're using it interactively and watching what it changes, I'd trigger the tests when you think it's needed. And if you want to go more hands-off, why not add try to encode the same nuance you'd use into the rule?
Rather than bake that into the prompt - wouldn’t it be better to just set up a pre commit hook that runs tests and linting?
replyMaybe, depends on their workflow. In my human workflow, I tend to use commits as checkpoints and then squash before pushing. I'd usually only run time-consuming tests before squash+push.
replyBut yes, anything you want to ensure really needs to be a hook.
edit: realizing with "precommit" you probably meant a git hook not one in their harness. I'd have written the same response more or less though. :)
Oh yes - definitely the git kind of hook. Also, I always forget that there’s a pre-push hook as well. So you don’t need to do things every commit.
replyBut then you could just be storing up a lot of problems…
Indeed. That's why I think it depends on the individual's workflow where it should live.
replyFollowing rules like "verify all changes with tests" down to a tee is usually a desirable trait in LLMs. Personally I'd leave that behavior there (just like with humans for some tasks like aviation you have them go through checklists even if some stuff you can infer is not needed). But otherwise just make it "always run tests unless you're absolutely sure they can be skipped".
replyAdd "... unless the changes are trivial, docs-only, or typo fixes" to the "always verify with tests" instruction and see how that does
reply