Review in a Fresh Context and Use Manual QA to Restore Human Judgment

Implementation, automated review, code review, and manual QA are separate activities. They should not be collapsed into one long agent session. Automated review should begin in a fresh context, and humans should manually exercise the resulting behavior before the work is considered complete.

An implementation session consumes tokens while exploring, editing, and testing. If the same agent immediately reviews its own work in that context, the review happens later in the session, closer to the dumb zone. The reviewer also carries the assumptions that produced the implementation.

A better pattern is:

1. Complete the implementation and commit it.
2. Clear the context.
3. Start a fresh reviewer with the code changes, the issue, and the relevant coding

standards.

1. Ask the reviewer to identify bugs, design violations, and missing checks.
2. Apply or queue the resulting fixes.
3. Perform human code review and manual QA.

The fresh reviewer can be automated because review tokens are comparatively inexpensive and the agent is effective at catching many defects. The purpose is not to replace human review. It is to put an additional smart-zone pass between implementation and human validation.

Human code review can begin with the tests. Determine whether they express sensible behavior and whether their boundaries are meaningful. Then inspect the implementation for unreasonable design choices, unexpected dependencies, or unnecessary complexity.

Manual QA is where the human imposes product judgment and taste. Run the feature as a user. Confirm that the behavior is understandable, that the interface feels appropriate, and that the integrated system works in the real environment. When QA finds a problem, add a new issue to the Kanban board with the correct blocking relationship. QA is therefore not a terminal gate; it is a source of new backlog information.

Front-end work makes this especially visible. A coding agent can generate interface code, but visual quality depends on human eyes. A useful early technique is to ask the agent for several throwaway prototypes on a temporary route, allow a human to click between them, and feed the preferred direction back into the alignment process. The prototype is a feedback asset, not production code.

Automating every stage produces software without a reliable source of taste. The system may technically function while feeling incoherent, solving the wrong problem, or violating expectations that were never encoded in tests.

Fresh-context review also prevents the review from inheriting the full implementation session and all of its accumulated assumptions. A separate reviewer receives the result as code to inspect rather than as the continuation of its own implementation process.

Use the following validation pipeline for every completed issue or small group of issues:

1. Implementation agent completes the task with tests and a commit.
2. Fresh automated reviewer examines the diff against the issue and coding standards.
3. The implementation is corrected or a follow-up issue is created.
4. A human reviews the tests first, then the production code.
5. A human runs the integrated behavior manually.
6. Every defect, usability problem, or missing requirement becomes a new backlog item.
7. The implementation loop continues until the result is acceptable.
8. Only then is the work shared for broader team review and merge.

Keep the review unit small. The more issues an autonomous loop completes before review, the harder it becomes to understand causality and maintain a small pull request.

Delegating more coding creates more review work. There is no demonstrated mechanism that removes this cost. Teams should expect code review to become a larger share of engineering time.

Small pull requests and high-throughput autonomous loops can conflict. A long loop produces more code than a human can comfortably review at once. The practical controls are task size, loop length, branch separation, and disciplined issue boundaries, but these do not eliminate the tension.

Manual QA is slow and cannot cover every state. Its role is different from automated testing: it applies human judgment to integrated behavior and catches failures that the available feedback loops did not represent.

End implementation before review begins. Use a fresh automated reviewer, inspect tests and code, exercise the feature manually, and feed every finding back into the issue graph. Human QA is where correctness, intent, and taste are reconciled.