Review principle
A clean render is not an acceptance test
Generated components often satisfy the visible happy path while leaving invalid data, loading races, keyboard behavior, permission boundaries and cleanup untested. The reviewer’s job is to recover the hidden contract: what inputs exist, what state may change and what must remain true when something fails.
Keep the change small enough to understand. If a generated diff mixes a dependency migration, redesign, data-model change and new feature, split it before evaluating correctness.
Production standard
Five gates before the code can ship
A gate passes with evidence, not with ‘looks good’. A failure sends the change back with a specific acceptance condition.
Behavior
PassCritical journeys work for valid, empty, invalid, slow and failed responses.
FailState is lost, duplicate actions occur or errors strand the user.
Security and privacy
PassTrust decisions remain server-side; inputs, outputs, secrets and data exposure are bounded.
FailThe client controls authorization, secrets enter the bundle or errors leak internals.
Accessibility
PassNative semantics, names, focus, keyboard behavior and status announcements match the interaction.
FailA custom visual control cannot be used or understood without a pointer.
Performance
PassThe change has a justified client boundary, bounded dependencies and measured loading impact.
FailLarge libraries, effects or requests were added for convenience without user value.
Maintainability
PassThe code has one clear responsibility, stable types and a testable interface.
FailDuplicated logic, dead branches or a configurable super-component hide behavior.
Decision matrix
Plausible-looking frontend failures
These patterns often survive screenshot review because the failure appears only through timing, input or a different user capability.
| Pattern | Why it looks acceptable | Hidden failure | Review move |
|---|---|---|---|
| Effect copies props into state | The first render is correct | Updates drift or loop as dependencies change | Remove derived state or document the synchronization contract |
| Clickable div with handlers | Mouse interaction works | Keyboard, roles and focus behavior are missing | Use the native control and test without a pointer |
| Client-side role check | Unauthorized UI stays hidden | Direct requests can bypass the visual restriction | Enforce the permission at the server boundary |
| Broad catch with friendly message | The UI never shows a stack trace | Different failures become impossible to diagnose or recover | Classify expected errors and preserve a request identifier |
| New dependency for one helper | The implementation is short | Bundle, supply-chain and maintenance cost grows | Compare with platform or existing project capabilities |
Repeatable process
A review packet for every generated change
Ask the author—human or agent—to provide this context before the reviewer opens the diff.
- 01
Intent
State the user problem, non-goals and acceptance criteria.
- 02
Change map
List affected routes, components, data boundaries and dependencies.
- 03
Risk notes
Name the most likely security, accessibility, performance and regression risks.
- 04
Verification
Run focused automation and manually exercise the critical journey.
- 05
Ownership
Identify who can explain, monitor and revert the change after release.
Plain answers
Code-review questions
Should AI-generated code receive a separate coding standard?+
Usually no. Apply the project’s normal standards and add process controls for change size, provenance and verification where generation increases volume or uncertainty.
Can a scanner replace repository review?+
No. A public scan sees delivered output. Authorization, secrets, data access, build configuration, tests and most maintainability concerns require repository or runtime access.