ChatGPT code review: what it catches and what it misses

ChatGPT code review works on the lines you paste in. Give ChatGPT or Claude a diff and a clear prompt, and it will often catch real bugs in those lines: an off-by-one, an unhandled error, a total that can go negative. What a pasted review can't do is see the rest of your repository, learn from your team's past reviews, give the same answer every time, or test its suggestions against your project. And nothing runs it on every pull request.

Our verdict: use a chat model as a second opinion on your own diff before you push, with the prompt below. Don't make it your team's code review. That needs a reviewer that runs on every pull request and sees the code around the change.

This blog belongs to cubic (cubic.dev), an AI code review tool, so weigh our view accordingly. The facts below come from OpenAI's, Anthropic's and Google's own pages, two research papers, GitHub and Martian's Code Review Bench, read on October 10, 2026.

Can ChatGPT review your code?

Yes, and developers have used it in public code reviews since 2023. A study presented at EASE 2024 (Watanabe et al.) read 229 GitHub review comments that linked to a ChatGPT conversation, across 205 pull requests in 179 projects, from May 2023 to February 2024. Reviewers mostly used ChatGPT to look things up or to have it write and fix code; only 12 of 219 classified comments asked it to review code directly.

Most pull request authors liked what ChatGPT contributed: of 114 responses the researchers could classify, 73 were positive (64.0%) and 35 negative (30.7%). The negative ones show where it goes wrong:

• The most common complaint was that the answer added nothing the author didn't already have.

• Next came answers that had a bug or didn't work, and suggestions that clashed with the author's design.

• Then came cases where the author already had a better fix.

• A few were right in general but wrong for that project.

Of the 35 negative reactions, 23 came when the reviewer asked ChatGPT to do the work, such as writing code or fixing a bug, rather than to explain something. The authors conclude that reviewers need to check its answers carefully. The study is small and covers 2023-era models, but those failure modes haven't gone away.

One public example from the study: on a llama.cpp pull request adding Metal GPU kernels (#1807, June 2023), a commenter shared GPT-4's suggestions for the code. The author replied that one had a bug, one made the code much slower, and the other two were generic, "at the level of CS-101."

A chat model reads the lines in front of it closely, but it can't run them, and it knows only what you tell it about your project.

A ChatGPT code review prompt that works

The usual code review prompt asks for everything: bugs, performance, security, style, best practices. You get a long list, and the one real bug sits among naming suggestions. This prompt does the opposite. It gives the model the context it can't see and limits it to problems it can point to.

1. Get the diff with whole functions around each change: git diff -W main...HEAD. For an open pull request, gh pr diff 123 prints its diff.

2. Collect the code the change depends on: callers, types or schemas, config. Only what's relevant.

3. Fill in the template and send it in a new chat.

4. Run it twice. A finding that shows up in only one run is a lead to check, not a verdict.

5. Check each finding against the code. For anything marked high, ask: "Show me the exact input that triggers this, step by step."

Review this pull request diff. Find real problems in the changed lines. Don't rewrite the code.

What the change is for:
[One or two sentences: the goal, and anything a reviewer must know, e.g. "Pages are numbered from 1 in our API."]

Team rules (flag any changed line that breaks one):
[3 to 10 short rules, e.g. "Money is stored as integer cents" or "Every query on customer data filters by orgId."]

Code the diff depends on but doesn't show:
[Callers, types, schemas or config the change touches. Write "None included" if you have none.]

How to review:
1. Report only issues you can tie to a specific changed line. Quote that line.
2. Look for bugs, security holes, data loss, unhandled errors and broken edge cases. Skip style, formatting and naming; our linter covers those.
3. For each issue, write:
   [high/medium/low] file:line, the quoted line
   What breaks: the input or state that triggers it, and what happens.
   Fix: the smallest change that fixes it.
4. If an issue depends on code you can't see, don't guess. Put it under "Couldn't check" and name the file or function you'd need.
5. If nothing is worth fixing, reply "No issues found." Don't pad the list.
6. Put high severity first, and stop at 10 issues.

Diff:
[Paste the output of git diff here

Review this pull request diff. Find real problems in the changed lines. Don't rewrite the code.

What the change is for:
[One or two sentences: the goal, and anything a reviewer must know, e.g. "Pages are numbered from 1 in our API."]

Team rules (flag any changed line that breaks one):
[3 to 10 short rules, e.g. "Money is stored as integer cents" or "Every query on customer data filters by orgId."]

Code the diff depends on but doesn't show:
[Callers, types, schemas or config the change touches. Write "None included" if you have none.]

How to review:
1. Report only issues you can tie to a specific changed line. Quote that line.
2. Look for bugs, security holes, data loss, unhandled errors and broken edge cases. Skip style, formatting and naming; our linter covers those.
3. For each issue, write:
   [high/medium/low] file:line, the quoted line
   What breaks: the input or state that triggers it, and what happens.
   Fix: the smallest change that fixes it.
4. If an issue depends on code you can't see, don't guess. Put it under "Couldn't check" and name the file or function you'd need.
5. If nothing is worth fixing, reply "No issues found." Don't pad the list.
6. Put high severity first, and stop at 10 issues.

Diff:
[Paste the output of git diff here

Review this pull request diff. Find real problems in the changed lines. Don't rewrite the code.

What the change is for:
[One or two sentences: the goal, and anything a reviewer must know, e.g. "Pages are numbered from 1 in our API."]

Team rules (flag any changed line that breaks one):
[3 to 10 short rules, e.g. "Money is stored as integer cents" or "Every query on customer data filters by orgId."]

Code the diff depends on but doesn't show:
[Callers, types, schemas or config the change touches. Write "None included" if you have none.]

How to review:
1. Report only issues you can tie to a specific changed line. Quote that line.
2. Look for bugs, security holes, data loss, unhandled errors and broken edge cases. Skip style, formatting and naming; our linter covers those.
3. For each issue, write:
   [high/medium/low] file:line, the quoted line
   What breaks: the input or state that triggers it, and what happens.
   Fix: the smallest change that fixes it.
4. If an issue depends on code you can't see, don't guess. Put it under "Couldn't check" and name the file or function you'd need.
5. If nothing is worth fixing, reply "No issues found." Don't pad the list.
6. Put high severity first, and stop at 10 issues.

Diff:
[Paste the output of git diff here

Why it's shaped this way:

• One changed line per issue keeps out generic advice.

• No style leaves naming and formatting to your linter, so a real bug doesn't get buried.

• "What breaks" follows OpenAI's own code review docs, which suggest asking, for each finding, for the triggering input, the expected behavior and the actual behavior.

• "Couldn't check" turns missing context into a to-do list instead of a guess.

• "No issues found" makes an empty answer acceptable, so the model has no reason to pad.

Nothing in the template is specific to ChatGPT, so you can use it in Claude, Gemini or a GitHub Action.

Where ChatGPT code review falls short

It only sees what you paste. Say your diff renames a field in an API response. The change can be correct and still break callers in files you didn't paste, and the model can't know they exist. "Couldn't check" only covers dependencies the model thinks to ask about.

A pasted review sees only the diff. Whether the change is safe often depends on the code around it.

It doesn't learn from your team. You can keep rules in a ChatGPT project or in custom instructions, but nothing feeds your past pull requests back into it: which comments your team acted on, and which it dismissed.

It can answer differently each time. In a 2025 preprint (Klishevich et al.), GPT-4o, GPT-4o mini, Claude 3.5 Sonnet and Llama 3.2 rated the same 70 Java commits five times each on effort, the author's experience, difficulty and maintainability, at temperature zero, and their ratings still varied between runs. Anthropic's API docs say that even at a temperature of 0, results won't be fully deterministic, and its models released after Claude Opus 4.6 no longer accept the setting at all. A clean run doesn't prove clean code.

Nothing checks its claims. A diff pasted into a chat can't be built or tested, so suggested fixes reach you untested, like the llama.cpp suggestion with the bug. OpenAI tells you to check even its own automatic reviews against the diff.

It doesn't run on every pull request. It reviews what someone remembered to paste.

Is it safe to paste your code into ChatGPT?

It depends on your plan and settings. Personal accounts can feed model training; OpenAI's and Anthropic's business plans don't by default.

One catch on ChatGPT and Claude: a thumbs-up or thumbs-down can send the whole conversation for training, even after you opt out on ChatGPT and even on Claude's business plans, unless a Team or Enterprise owner turns off the Rate chats setting. Check your company's policy before you paste private code into a personal account.

LLM code review beyond the chat window

There are four common ways to go beyond a pasted diff, from a command you run to a reviewer on every pull request:

Codex code review. OpenAI's own code review page covers four things: uploading code to a ChatGPT Work chat, a Code Review plugin in the ChatGPT desktop app and on the web, /review for local changes in the Codex CLI, IDE extension and app, and the GitHub reviewer in the table, which posts through the ChatGPT Codex connector. Turn it on for a repository or comment @codex review, and Codex posts only its most serious findings, marked P0 and P1. More in our Codex code review guide.

Claude Code. /code-review (alias /review) runs in your Claude Code session, which reads your codebase, and it follows your CLAUDE.md. Pass a pull request number and --comment to post its findings on the pull request; /security-review checks your branch for security problems. Anthropic also sells a managed Code Review, a research preview for Team and Enterprise plans, and most teams shouldn't pay for it: Anthropic puts the average at $15-25 per review, billed as usage on top of your plan. Use the local commands. Details in our Claude Code review guide.

A GitHub Action that calls an LLM API. anc95/ChatGPT-CodeReview (4,466 stars on October 10, 2026) reviews each pull request with your API key, model and prompt. It sends each changed file's patch to the model separately, so the model never sees how the files fit together. The vendors' own versions are OpenAI's codex-action and Anthropic's claude-code-action. You pay per token: sending 30,000 tokens and getting 2,000 back costs about $0.08 on OpenAI's gpt-6.1-sol at October 2026 list prices ($2 per million input tokens, $10 per million output; our arithmetic), plus reasoning tokens, which bill as output. You also own the prompt and its upkeep.

A dedicated AI code reviewer. These are built for the gaps above: they run on every pull request, pull in context from the rest of the repository, apply your team's rules and learn from how you respond. How AI code review works explains the general approach, and our ranking of AI code review tools compares them.

How do ChatGPT and Claude score as code reviewers?

Martian's Code Review Bench scores review bots on real open-source pull requests, so it can't measure copy-paste reviews, but the model makers' own GitHub reviewers are on it. Martian, which describes itself as a research lab that doesn't sell coding tools, ranks them by F1, which balances how many real issues a reviewer catches against how many of its comments are wrong. In the last-month view (September 10 to October 10, 2026, checked October 10):

Dedicated reviewers hold #1 to #4. Anthropic's reviewer is the best of the model makers' at #5; OpenAI's Codex connector is #13 and Google's Gemini Code Assist #14 of 15.

The model alone doesn't explain the gap. Greptile and cubic, for example, both run on OpenAI and Anthropic models. What differs is the work around the model: the context it gets, the rules it follows and how it filters its own comments. The board moves daily and the top four sit within 2.2 points, so test the leaders that fit your Git host on your own pull requests. (cubic reviews GitHub only.)

When to use ChatGPT for code review

Use ChatGPT or Claude in a chat when:

• You work alone, or on code no company policy covers.

• You want a second opinion on a tricky function before you push.

• You want unfamiliar code explained, or a list of edge cases to test.

Use a reviewer that runs on every pull request when:

• A team merges code other people depend on.

• Your rules have to hold on every change, not only when someone pastes them.

• Your code can't go into a personal chat account.

Questions and answers

Can ChatGPT do a code review? Yes, on code you paste in. It's good at bugs inside the lines it can see and weak at anything that depends on the rest of your repository. For GitHub pull requests, OpenAI offers Codex code review on ChatGPT Plus, Pro, Business, Enterprise and Edu.

What should an AI code review prompt include? The diff with whole functions around each change, what the change is for, your team's rules and the code it depends on, plus output rules: one changed line per issue, a severity, the triggering input, a fix, no style comments, and permission to find nothing.

Is ChatGPT or Claude better at code review? As GitHub reviewers, Anthropic's ranks above OpenAI's on Martian's tracker: #5 against #13 in the last-month view, checked October 10, 2026. In a chat window, both depend on what you paste.

Can ChatGPT replace human code reviewers? No, and OpenAI doesn't claim it can. It calls Codex code review an additional reviewer and leaves enforcement to tests, branch protections and required approvals.

Paste a diff when you want a second opinion; put a reviewer on the pull request when you need one every time.

If your team is on GitHub, try cubic's AI code review on your next pull requests. There's a free plan with 20 PR reviews a month across your GitHub organization, and the 7-day trial needs no card.