Use coding agents inside the same controls

A coding agent can inspect several layers quickly, add a regression test and propose a patch. It can also follow the first plausible explanation too far. Give it an isolated branch or worktree, the bounded work order, repository conventions and the exact commands used for verification.

Ask for intermediate evidence where the diagnosis carries risk. Useful evidence includes a test that fails before the patch, the call path that writes the disputed state, and the reason an existing handler does not cover the event. Do not accept a long explanation as a substitute for a reproducible failure.

Keep changes reviewable. One agent should not repair the integration, redesign the portal, change the role model and rewrite the test fixtures in a single pass. If diagnosis reveals a wider issue, stop and revise the work order. That decision belongs in the task record so a later session does not rediscover the expansion and quietly continue it.

The human review should inspect both intent and mechanism. Check that the patch changes the named contract, that authorisation still happens at the server, and that a retry cannot create a second operation. Read the new test closely. An agent can produce a passing test that asserts its own revised behaviour without protecting the original requirement.

Record the commands and their outcomes, but keep the activity log proportionate. The release record needs the task, diff, tests, unresolved concerns and final decision. Keep the full exploratory transcript available separately if an investigation later needs it.