How to verify coding-agent output: a 7-step solo workflow

A coding agent finishing a task does not mean the code is ready to ship. My handoff point is not 'changes completed.' It is the moment when I can explain what changed, the tests have exercised the right behavior, and I know how to roll the change back. I use the agent as a fast implementer, not as the person making the final call.

GitHub's cloud agent can inspect a repository, make a plan, change code, and run tests or linters in an ephemeral environment. The result still comes back as a diff and pull request for a person to review.[1] That distinction matters. Being able to do the work and being qualified to approve the work are separate jobs.

The workflow below is not tied to one product. I use the same order with Claude Code, Codex, Copilot, or another agent. Not every task needs all seven steps at the same depth. NIST says its AI Risk Management Framework Playbook is not a checklist to follow in full; teams should choose the suggestions that fit their use case.[4] A copy edit and a payment-flow change should not pass through the same gate. Approving both with the same level of attention is worse.

1. Write the success condition before the code

'Fix the settings page' leaves too much room. I describe the visible result instead: the save button activates only after the form changes, a failed request preserves the old value, and the keyboard flow still works. Now I can judge the output against something written before the agent produced a confident explanation.

Include at least one failure case. What happens when the network drops, the API returns empty data, or the user repeats the action? Agents move quickly through the happy path. Quiet errors tend to survive at the edges. In my

note about code that ran but was still wrong, compilation was never the same thing as correct product behavior.

2. Measure the task boundary with the diff

I read the changed-file list first, then the diff. A form-validation task should not quietly include a package upgrade, unrelated renaming, or a repository-wide formatting pass. Extra work may be useful, but it expands the review surface. Moving it into a separate task usually makes both changes easier to trust.

The useful question is not how many files changed. It is which acceptance condition each change serves. A line with no answer needs to go or needs an explanation. GitHub also frames its cloud-agent workflow around a branch, visible diff, iteration, and a pull request when the reviewer is ready.[1] Reviewability is part of the product, not paperwork added afterward.

3. Ask whether the tests cover the change, not whether tests ran

A green test screen feels good and proves less than it seems. I first check whether the existing tests touch the behavior that changed. Then I look for one small test around the new failure mode. If a condition changed, I want both branches. If data conversion changed, I want a boundary value. If error handling changed, I want the failed request.

An agent can write a test that repeats the same mistaken assumption as its implementation. I read the test name and assertion separately from the code diff. For one critical case, I may deliberately break the implementation and confirm that the test fails. OpenAI's Codex Security documentation also recommends reviewing code changes before merge and verifying approved findings through bounded patches.[3]

4. Match permissions to the risk of the task

If writing code does not require production database access, payment credentials, or my entire home directory, the agent should not see them. My default is the working folder, local test commands, and limited network access when the task needs it. Anthropic documents Claude Code as read-only by default, with explicit permission required for file edits and command execution.[2] The same guidance describes working-directory boundaries plus filesystem and network isolation for more autonomous work.[2]

Automatically accepting every permission prompt looks faster until the reviewer becomes a button-pressing component. It is reasonable to allowlist frequent, safe commands. Package installation, remote downloads, migrations, deletion, and writes to production should remain separate checkpoints.

5. Treat external input as suspicious code

An issue, web page, log file, or third-party document can contain information alongside text written to steer the model. Prompt injection adds a different layer to ordinary input validation. Anthropic recommends reviewing commands before approval, avoiding direct pipes of untrusted content into Claude, and verifying changes to critical files.[2]

I separate research from implementation. The first pass can gather sources and propose a plan without write access. The second pass uses only the selected information and works inside a limited folder. That makes it harder for an instruction hidden on a web page to travel straight into a terminal with privileges.

6. Use separate technical, product, and rollback gates

Instead of one vague approval, I answer three questions. Technical gate: did the build, type check, tests, and relevant security scan pass? Product gate: does the acceptance condition hold in the real interface or API response? Rollback gate: if this goes wrong, how do I revert it without losing data?

The rollback question matters most for schemas, migrations, authentication, and payments. Reverting a commit can be easy while reverting the data transformed by that commit is not. An agent can prepare the plan and scripts, but the live action and final verification should stay with a person.

7. Explain the result without borrowing the agent's summary

If I cannot explain the change in one paragraph in my own words, I do not merge it yet. Which behavior changed, which risk remains, and what evidence did I use to accept it? Copying the agent's delivery message does not count. I do not need to memorize every line, but I need to understand the boundary of the change I am taking responsibility for.

My guide to choosing a coding agent separates tools by task type. Verification follows a similar rule: the task decides the evidence. A visual change needs a screen check; a data job needs sample records and a rollback rehearsal; a security fix needs proof that the attack path is closed.

The short verification card

Before merging, I want to see these seven lines:

• Expected behavior and at least one failure case are written down.

• The diff stays inside the task; unrelated changes are gone.

• Tests cover the changed behavior and the failure path.

• The agent has only the files, commands, network, and secrets it needs.

• A human checkpoint separates external content from command execution.

• Technical checks, product checks, and the rollback path are complete.

• I can explain the change without reading the agent's summary.

This workflow is not meant to slow the agent down. It makes the speed usable. If code takes five minutes to generate and an hour to understand, there is no gain. Small measurable tasks, narrow permissions, visible diffs, behavioral tests, and an explicit rollback path are what turn agent speed into saved time.