ChatGPT Code Review: Find Issues and Verify Fixes

A useful ChatGPT code review starts with a focused diff, the intended behavior, and the surrounding code needed to check it. Ask for evidence-backed findings, reproduce accepted issues, and verify the fixes before approving the change. fenbs can keep the accepted bugs and lessons available for the next review instead of leaving them in a private conversation.

A diff is the added and removed code between two versions. It shows what changed, but it may omit the caller, configuration, or permission rule that determines whether a suspicious line is actually wrong. Your workflow needs to handle those missing pieces explicitly.

What should you send before asking for a review?

1. Identify the exact revision and the comparison point. Include the file paths and a diff with surrounding lines.
2. Describe the expected user behavior and what must remain unchanged.
3. Supply relevant callers, interfaces, tests, configuration, and project rules. Exclude secrets and unauthorized private data.
4. Ask for findings first, with no edits until you have assessed them.
5. Require the assistant to name missing evidence rather than guess how unseen code works.

OpenAI’s code-review guide↗ (opens in a new tab) describes reviewing supplied code and checking findings against the current change and tests. Upload relevant files or use an approved source connection when available. Do not assume that mentioning a repository or past chat gives the assistant access to it.

For a large change, divide the review by behavior: sign-in, account permissions, file processing, or the updated screen. Keep related files together so the assistant can follow a complete path. The code review checklist helps you decide which areas need attention before splitting the work.

How do you ask for actionable findings?

State what counts as a finding. A useful one identifies a condition that can occur, the code path it triggers, the incorrect result, and why the current change causes it. Ask ChatGPT to separate confirmed issues from questions and optional style suggestions.

Review this diff for behavior bugs introduced by the change.
Expected behavior: [describe it].
Prioritize data loss, access mistakes, and broken user flows.
For each finding give: current file and lines, triggering input,
expected result, actual result, and supporting code or test evidence.
If context is missing, ask for it. Do not invent callers.
Keep style suggestions separate. Do not modify files yet.

Say a change adds a Retry button after a support-request timeout. Give the rule that retrying the same submission must not create a second ticket, while a deliberately new request gets its own identifier. Those details let the review examine real outcomes instead of proposing a different product.

Google’s review guidance↗ (opens in a new tab) includes design, behavior, complexity, and useful tests. Use those as categories for questions, not a demand to manufacture an issue in every category. A review can correctly find nothing actionable within the supplied scope.

How do you check whether a reported bug is real?

Start with the cited lines in the exact revision under review. Follow the input through its callers and checks. Look for a guard elsewhere that prevents the proposed failure, and confirm the assistant has not described code from an earlier version. OpenAI warns that ChatGPT can give incorrect answers confidently↗ (opens in a new tab), so confidence is not a severity score.

For a permission concern, test the server request as an actor who should be refused. Hiding a button alone does not establish protection. OWASP’s access-control guidance↗ (opens in a new tab) explains why enforcement belongs in trusted server code. Sensitive changes still need a reviewer qualified to judge that area.

Once you accept an issue, save its evidence and next action in a task. In fenbs, the task and its history can preserve that distinction between an assistant’s suggestion and a confirmed bug, so the next session does not reopen every discarded concern.

What makes a fix ready for another review?

Ask for the smallest change that corrects the accepted behavior. Separate unrelated cleanup so the follow-up diff remains understandable. Require a short explanation of why the failing case now succeeds and what neighboring behavior the fix could affect.

For the support-request example, a useful test submits the same request identifier twice and checks that only one ticket exists. Also check that two genuinely separate requests remain separate. When practical, show that the bug-demonstrating check fails before the fix and passes afterward. A check that never reached the faulty path does not verify the repair.

• Inspect the revised diff for changes outside the accepted issue.
• Run the focused check, then the repository checks appropriate to the affected area.
• Exercise visible behavior in the app when a code-only check cannot establish the result.
• Report exactly what ran, which revision it covered, and anything still untested.

Ask ChatGPT for a follow-up review of the new diff and the original finding. Keep human approval separate from that answer. Our code review best practices covers the broader team process; this loop is about turning a particular AI finding into verified evidence.

Which lessons should survive the conversation?

Save a lesson when the review exposed a repeatable trap. For example: the Retry button generated a fresh request identifier even though the original submission had already reached the server. Record what happened, why the existing check missed it, and the retry condition future changes should include.

Keep lessons concrete and scoped. “Always test everything” gives the next reviewer no direction. “Check that a retry preserves the original submission identifier when the response is lost” identifies a useful action. A rejected finding can teach a lesson too if the assistant repeatedly misunderstands where a shared check lives.

Tool-specific setup belongs in the OpenAI review workflow, and choosing products belongs in AI code review tools. The durable record should focus on your codebase’s behavior and evidence rather than copying a tool’s entire output.

How to do this with fenbs

1. Create a free account and add the development project with its current review goal.
2. Create tasks for accepted findings, including the affected file, revision, triggering case, and intended behavior. Keep uncertain concerns explicitly unconfirmed.
3. Record the fix plan and actual test results in each task. Leave a task open when the needed behavior has not been checked.
4. Add a lesson for a repeatable mistake and record any review rule a person approved in Decisions and rules.
5. Connect a supported assistant from Integrations. Ask it to read the context before reviewing and save progress with the next check before stopping.

fenbs does not execute your test suite or approve a pull request. A one-off small review may need only your existing repository tools; fenbs helps when accepted work and lessons need to survive several sessions or assistants. Explore related practices in the AI at work hub.