I've found my biggest gains came from agent managed local ephemeral environments and a verification matrix.
Agent managed local ephemeral environments is allowing your agents to quickly and easily set up worktrees (ideally polyrepo support), configure services in separate port ranges or isolated resources (eg its own postgres db, its own apis, its own web server, etc), and populate data. This enables many agents to work in parallel on your machine which opens the door for the verification matrix.
A verification matrix is a slug based list of every possible way to verify some aspect of a change to the project. That could be running a deterministic set of tools like linting processes, tests, or custom scripts. The verification matrix also includes manual processes such as executing sql code, api endpoints, cli commands, opening a browser and using the app, and so on.
Linking the verification matrix slug (eg web:manual-testing-via-chrome-devtools) to the acceptance criteria or product requirement in the plan phase is where you'd go next. Then your plan reviewer can object to any plan whose AC/requirement has no way to be verified -- the agent can build the new method of verification into the plan to move forward.
I've found my biggest gains came from agent managed local ephemeral environments and a verification matrix.
Agent managed local ephemeral environments is allowing your agents to quickly and easily set up worktrees (ideally polyrepo support), configure services in separate port ranges or isolated resources (eg its own postgres db, its own apis, its own web server, etc), and populate data. This enables many agents to work in parallel on your machine which opens the door for the verification matrix.
A verification matrix is a slug based list of every possible way to verify some aspect of a change to the project. That could be running a deterministic set of tools like linting processes, tests, or custom scripts. The verification matrix also includes manual processes such as executing sql code, api endpoints, cli commands, opening a browser and using the app, and so on.
Linking the verification matrix slug (eg web:manual-testing-via-chrome-devtools) to the acceptance criteria or product requirement in the plan phase is where you'd go next. Then your plan reviewer can object to any plan whose AC/requirement has no way to be verified -- the agent can build the new method of verification into the plan to move forward.
All of this is centered around verifiability.