Overview
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:
- Complete the implementation and commit it.
- Clear the context.
- Start a fresh reviewer with the code changes, the issue, and the relevant coding
standards.
- Ask the reviewer to identify bugs, design violations, and missing checks.
- Apply or queue the resulting fixes.
- 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.