Keep coding agents inside the same controls

A coding agent can look through several layers quickly, add a regression test and propose a patch. It can also chase the first plausible explanation too far. I'd give it an isolated branch or worktree, the bounded work order, the repository's conventions and the exact commands used for verification.

Where the diagnosis carries risk, ask for evidence along the way. Useful evidence includes a test that fails before the patch, the call path that writes the disputed state, and the reason an existing handler doesn't cover the event. A long explanation shouldn't stand in for a failure you can reproduce.

Keep the changes small enough to review. One agent shouldn't fix the integration, redesign the portal, change the role model and rewrite the test fixtures all in one pass. If the diagnosis turns up a wider problem, stop and revise the work order, and put that decision in the task record so a later session doesn't rediscover the expansion and quietly keep going with it.

The human review needs to look at both what the patch was meant to do and how it does it. Check that it changes the named contract, that authorisation still happens on the server, and that a retry can't create a second operation. Read the new test closely too. An agent can write a passing test that asserts its own revised behaviour and doesn't protect the original requirement at all.

Record the commands and what they returned, but keep the activity log in proportion. The release record needs the task, the diff, the tests, any open concerns and the final decision. The full exploratory transcript can live somewhere separate in case a later investigation needs it.