review ai-generated code by checking the claim before the implementation. read the goal, find the seams where the change can be wrong, verify what ran and then use the changed behaviour yourself.
an agent can produce a tidy explanation of a diff. treat that explanation as a map, not proof. the shortest route to confidence is usually not reading every unchanged line. it is checking whether the requested behaviour now holds without damaging the nearby behaviour.
01start with the acceptance check
before you open the diff, read the problem and the expected result. if the request cannot tell a reviewer what done means, the review will drift into taste and guesswork.
for a password error, the check might be: a wrong password shows a visible error, stops the spinner, leaves the email field intact and allows another attempt. now the review has a route through the app.
compare the pull request summary to that route. has the change solved the named problem, or has it solved a convenient smaller one?
02inspect the risky seams
most bugs are not hidden in a long new helper. they sit where the new code touches an existing boundary: an API response, a permission check, a database transaction, a route or a loading state.
for each changed seam, ask what happens on both sides. if an agent added a seat limit, check the value source, the boundary case at the limit and the caller that displays the refusal. if it changed an API response, check the consumer that handles the old shape.
this is where an independent reviewer helps. the builder already has a model of why the change is right. another reader is more likely to notice the assumption that model left out.
03read tests as claims
a test proves the case it exercises. read its setup and assertion, then ask whether it fails on the old behaviour. a test added beside a fix can still pass without reaching the defect.
also read what did not run. a skipped browser check, an unavailable integration or a flaky end-to-end suite is not a reason to reject a pull request automatically. it is a reason to keep the uncertainty visible and decide whether you can replace it with a manual check.
04open the feature
use the path a person would use. submit the form, retry after an error, download the file, move through the mobile layout or sign in with the affected role.
the browser finds classes of failure a unit test cannot see: a hidden error, a disabled button that never recovers, a dialog behind another layer or a success state that uses the wrong account.
keep the check small and specific. you are not re-testing the whole product. you are proving the changed promise in a running environment.
05decide what to merge
merge when the behaviour matches the goal, the risky seams hold, the evidence is appropriate and any remaining gap is understood. request changes when you can name the missed claim, not just the feeling that the diff is large.
Wayari separates the builder from the reviewer and records the checks at the commit under review. that gives you a second set of eyes before the final one that matters: yours.
Use the full review checklist and browser checks together. The Wayari documentation covers the gate.
