Gemini for Code Review: Find and Verify Real Problems

Use Gemini for code review by supplying a focused change, the behavior it must preserve, and enough surrounding code to test its reasoning. Treat each finding as a hypothesis until you can trace a real failure and verify it. Tools like fenbs keep the review rules, confirmed problems, and lessons available when the next change arrives.

The goal is a short set of useful findings. A long list of possible concerns can distract from the one bug that breaks a customer workflow. Set the scope before the review starts, and ask for evidence that another developer could follow without reading the entire chat.

How do you run a focused first review?

1. State the change and expected behavior. Include the base revision and the version being reviewed so the scope is unambiguous.
2. Supply the diff, relevant callers, existing tests, and repository instructions. Leave out credentials, customer records, and unrelated files.
3. Ask Gemini to identify defects introduced by the change, with a file location, triggering input, and explanation of the consequence.
4. Trace each proposed problem through the surrounding code. Reproduce it with a focused check when possible.
5. Record confirmed findings, rejected concerns, and checks that remain. Have a person review the final change before merging.

For example, a patch changes how a subscription cancellation is handled. Explain whether access ends immediately or at the end of the paid period. Without that product rule, an assistant may correctly read the code yet recommend the wrong behavior. Include an example of the intended outcome and an example that must be refused.

Which Gemini review option fits the change?

For a pull request on GitHub, Google offers Gemini Code Assist review that works in pull-request comments and uses repository context. Follow its GitHub review documentation↗ (opens in a new tab) for current setup and availability. Check the documented exclusions before deciding what its review has covered.

For a local change, Gemini CLI↗ (opens in a new tab) works in a terminal with project context. Review its proposed tool actions and give it clear instructions about whether it may edit files or run commands. A review request should say which behavior you want examined and what actions you authorize.

You can also supply a small diff and relevant files in Gemini Apps; Google documents file and code uploads↗ (opens in a new tab). That is a bounded review of what you supplied, so do not interpret it as inspection of an unseen repository. The separate Gemini CLI versus Code Assist guide explains the product choice.

If you are doing the same job in another assistant, use the separate Copilot code review workflow for its controls and review process.

What context does Gemini need beyond the diff?

A diff shows changed lines. It may not show the contract those lines must follow. Provide the function callers, error handling, data ownership rules, and existing behavior that make a finding testable. Explain unfamiliar project terms in plain language so the review does not attach the wrong meaning to a field name.

• Behavior: what the user can do before and after the change.
• Boundaries: who may read or change the affected data, and where that restriction is enforced.
• Inputs: empty values, repeated requests, stale data, and other relevant edge cases.
• Environment: the actual framework and dependency versions, plus the supported deployment conditions.
• Checks: the tests already run, their results, and the important paths they do not cover.

Ask the reviewer to separate established defects from questions requiring a product decision. “This request bypasses the ownership check” is different from “Should users be allowed to do this?” The first needs evidence and a fix; the second needs a person to choose the rule. Your code review checklist can provide the repeatable starting point.

Keep that human choice in Decisions and rules in fenbs, so a later assistant can review against the same agreed behavior.

How do you separate a real defect from a false positive?

Require a chain of evidence: the input or event, the path through the code, the incorrect result, and the reason the patch caused it. Then inspect every link. A finding about a missing null check may disappear when the caller always supplies a value; a missing permission check may be real even when the normal interface hides the action.

Review this change for introduced defects. Do not edit files.
For each finding provide:
1. File and relevant changed lines.
2. Concrete input or event that triggers the issue.
3. Execution path and incorrect observable result.
4. Why existing checks do not prevent it.
5. A minimal verification step.
Separate questions and style preferences from confirmed defects.
If you lack required context, name the missing file or rule.

Run the smallest meaningful verification first. A failing regression test, a request with a specific response, or a trace through a deterministic function can support the finding. If you cannot reproduce it, record what you checked and what remains uncertain. Do not turn “looks plausible” into “confirmed” to make the review feel complete.

After a fix, verify the triggering case and nearby behavior the change could affect. A green test suite is useful evidence, but it answers only what those tests exercise. The broader code review best practices guide covers the human review around these checks.

How to do this with fenbs

1. Create a free account and add the software project with links to its repository and review instructions.
2. Record agreed review rules in Decisions and rules, including who approves changes and what must be verified.
3. Add confirmed defects as Bug tasks. Put the reproduction, repair plan, and test results with the task; keep uncertain questions clearly labeled.
4. Connect Gemini CLI or another supported assistant through Integrations. Ask it to read project context before work and save the remaining checks before stopping.

Manually record findings from a Gemini Apps chat or a GitHub review when that is where you worked. fenbs does not automatically import those reviews, run your tests, or approve a merge. If you need only a single pull-request comment, the code host may be enough; fenbs helps when review lessons and decisions need to continue across tools.

What should the final review handoff say?

List the confirmed problems, the changes made, and the exact checks that passed or failed. Name any path you did not inspect. If no defects were confirmed, say that without presenting the review as a guarantee that the change is safe.

A teammate should be able to continue without asking which revision you tested. Save that revision and the next action while the details are fresh. For other reviewed assistant workflows, explore the AI at work hub.