1. Make your tests as fast as practicable

2. Split out "syntactically correct" fast checks like linters into a standalone script and call it along with the slower checks in a full-check script

3. Set the fast-check script as a pre-commit hook and the full-check script as a pre-push hook.

4. Give the model instructions that it needs to run the fast-check script after every change and the full-check script when it thinks it's done.

5. Run full-check in CI.

Then you're good as long as the model doesn't bypass the pre-push hook, and even then CI will catch it.

▲

nzoschke 4 hours ago | parent [-]

pre-commit and pre-push hooks sound smart. I like that those will work the same for any human or any harness vs harness hooks.

Then push straight to main? Or do we need GitHub to help manage the queue https://docs.github.com/en/repositories/configuring-branches...

▲

zrail 4 hours ago | parent [-]

I think that's orthogonal to testing/ci/hooks and depends on what you're building and what stage you're at. Personally I would not run anything with real users without PRs and branch protection.

	▲	nzoschke 3 hours ago \| parent [-]
		My `codex` design session landed on opening GitHub PRs and labeling some with `automerge` that we're comfortable landing on main after GH also verifies the checks.