Review AI-generated code without losing the thread

A large generated change creates two pressures at once. The machine can produce more code while you are still reading the previous diff, and the apparent completeness of the output encourages a broad “looks fine” pass. Neither pressure changes who is responsible for accepting the change. The reviewer still needs evidence.

Do not define success as “review the PR” when the PR contains several independent behaviors. Define the next review question: does the new authorization path reject an expired guest invite; can the database change be rolled back; does the error mapping preserve the public API. A narrow question makes the missing evidence visible instead of hiding it inside a large percentage-complete feeling.

Organizing attention can help you read deliberately, but it cannot establish that the implementation is safe. Correctness comes from the engineering process: requirements, tests, static analysis, threat modelling, domain expertise, runtime observation, and human judgement appropriate to the risk. A timer is not part of the evidence unless timing itself is the behavior under test.

Keep this separation explicit. The focus layer answers: what will I review in this pass, and what will I leave behind? The engineering layer answers: what evidence would make this behavior acceptable? Confusing the two creates dangerous language such as “the review is done because the session ended”. The correct close-out may be “the input validation path is checked; authorization and rollback remain unchecked”.

The distinction also sets an honest boundary for NEDIO. It can hold a review goal, duration, self-reported outcome, and next action. It does not access the repository, run the suite, inspect dependencies, or certify a change. Use it beside the code-review tools, not instead of them.

Start with risk, not file count. A ten-line permission change can deserve more attention than a generated formatting diff across a hundred files. Ask what failure would matter and what observation would change your decision. The question should be small enough to finish or explicitly hand off in one pass.

Weak goals describe an activity: “read the auth code”, “look through the migration”, “review agent output”. Stronger goals name a behavior and evidence: “confirm an expired guest invite cannot acquire an access token, using one failing and one passing test”. The stronger goal does not guarantee a good test, but it exposes what the pass is meant to learn.

Write the finish line before reading deeply. Examples include “the rollback SQL has been executed against a disposable database and the result is recorded”, “the public error response is covered by a regression test”, or “the unchecked paths are listed in the PR”. If the required evidence will not fit the available time, reduce the scope rather than lowering the standard silently.

For a database-heavy change, the package may include the schema diff, generated SQL, rollback operation, representative query, and performance evidence. For an API change, it may include the contract, compatibility cases, authorization paths, and observable error behavior. For a UI change, it may include keyboard behavior, loading and error states, responsive checks, and a screenshot at the supported breakpoints.

Do not accept a model's summary as evidence of what the diff contains. A summary is an index that helps you navigate. Compare it with the actual change, test results, and system behavior. If the summary omits a file or risk, record that discrepancy; it is useful information for the next pass.

Keep the package close to the durable work surface. Review comments belong in the pull request. A discovered requirement belongs in the issue or specification. A regression belongs in a test. The NEDIO record only needs enough context to resume the review without pretending to be the engineering archive.

The pass produces a bounded conclusion: one behavior has evidence, while four areas remain open. It does not label the whole pull request safe. Another reviewer can challenge the test design or choose a different risk. The checklist makes that disagreement inspectable.

If the test unexpectedly passes before the proposed fix, stop and investigate the premise. Asking the agent for a larger patch would add output before the team understands the observation. A review session is allowed to end with “the claimed failure did not reproduce”. That is valuable evidence and a reason to change course.

At the end of the pass, resist a single vague status such as “mostly reviewed”. Write three lines. Checked: the behavior and evidence you actually observed. Unchecked: named risks or paths you did not inspect. Next: the first action for the following pass, including where it belongs.

A review can end as yes, partly, or no relative to its own finish line. “Partly” is not failure when the note explains the boundary. “Yes” applies only to the bounded question; it should not be copied into a claim that the entire generated change is correct. The pull-request decision remains in the team's review system.

If new generated code arrives during review, decide whether it invalidates the evidence already gathered. Do not silently fold a changing diff into the same conclusion. Pin the revision, rerun relevant checks, or open a new pass. Stable evidence requires a stable object of review.

Choose Review mode, set a duration that matches the question, write the goal, and define “done when” as an evidence state. The example button uses 25 minutes because it is a low-friction starting point, not because every code review should take 25 minutes. Edit it before starting.

At close-out, record what the pass established and park the next check. NEDIO tracks the session you chose to run. It does not infer coverage from the repository, score the pull request, or decide whether another reviewer is required. Its role is to keep the human boundary visible while the technical evidence stays in the tools designed for it.

NEDIO's product feature named AI Review is separate. It looks at summary data from recorded focus sessions to phrase an observation or a supported comparison. It does not receive raw source code. Keep the distinction explicit whenever you describe the workflow to a teammate.

Security-sensitive authentication, payments, privacy controls, migrations, and production infrastructure may require specialist review, threat modelling, staged rollout, and operational checks. A neat checklist and a completed timer do not reduce that obligation. Escalate based on impact, uncertainty, and organizational policy.

If generated volume consistently exceeds review capacity, change the input boundary: smaller pull requests, fewer concurrent agents, clearer acceptance criteria, or a policy that generated work is not merged without named evidence. NEDIO can help execute one bounded human pass. It cannot remove the queue or make an unsafe generation process sustainable.

The useful outcome is not “reviewed more code per hour”. It is a review record whose claims match the evidence and whose gaps remain visible. Sometimes that means accepting less output, rejecting a change, or returning to a human-written implementation. Those are engineering decisions, not failures of focus.