AI Code Review: Check Your Code Before You Push

Tools:

• A chat assistant such as ChatGPT, Claude or Gemini, or a coding agent in your terminal or editor

• Git (to produce a clean diff)

• Your project's test runner and linter

• Optional: the free Nexframe commit message generator

You have finished a feature, your tests are green, and you are about to type git push. This is the moment most bugs slip through. Nobody else has looked at the code, you are tired, and you are reading what you meant to write rather than what you actually wrote.

An AI code review gives you a second pair of eyes at exactly that moment. It will not replace a human reviewer, and it will sometimes be confidently wrong, but with a clear process it catches leaked secrets, missing input checks, untested edge cases and slow queries before they reach your main branch.

This workflow works with any chat assistant (ChatGPT, Claude, Gemini) or a coding agent that can read your repository. By the end of this workflow, you will have a repeatable pre-push routine: a focused diff, a security pass, a test-gap list, a performance and readability pass, and a short list of verified fixes you have applied and re-tested.

Before You Start Your AI Code Review

Never paste live secrets. If your diff contains API keys, database passwords or private keys, remove them first. Check your employer's policy on sharing code with AI tools too; some companies only allow approved business accounts.

Review small changes. AI reviewers, like humans, get worse as the diff grows. A review of 150 changed lines is far more useful than one of 3,000. If your branch is large, review it commit by commit.

If you have not yet planned the change itself, our workflow on how to plan before you code with AI is the natural step before this one.

Step 1: Prepare a Clean, Focused Diff

Start from the exact changes you are about to push. Run git diff main...HEAD (or git diff --staged) and save the output. Strip out generated files, lock files and minified assets; they waste the model's attention and rarely contain the bug.

Then add two or three sentences of context: what the change should do, your framework and language version, and anything unusual. Context is the difference between a generic review and a useful one.

I am about to push the change below. First, restate in 2-3 sentences
what you think it does, so I can confirm you understand it. Do not
review yet.

Project: [what the app does]
Stack: [language, framework, versions]
Purpose of this change: [one or two sentences]
Constraints: [e.g. serverless, must stay backwards compatible]

Diff:
[paste git diff here]

Checkpoint: Your diff is under roughly 300 lines, the AI has summarised it correctly, and you have corrected any misunderstanding.

Step 2: Run a Correctness Pass

Now ask for the first real review, limited to correctness. "Review this code" tends to produce a long list of style opinions and little substance; narrow prompts work better.

Ask the AI to quote the exact line behind each comment. Quoting anchors it to real code, which makes invented problems easier to spot.

Review this diff for correctness only. Ignore style.

Look for: logic errors, unhandled errors and empty inputs, null or
undefined values, off-by-one errors, wrong units or types, async
mistakes (missing await, unhandled promises), and behaviour that does
not match the stated purpose.

For each issue: quote the line, explain it in one or two sentences,
rate it High / Medium / Low, and suggest a minimal fix. If you are not
sure something is a bug, say so.

Checkpoint: You have a ranked list of possible correctness issues, each tied to a quoted line. You have not changed any code yet.

Step 3: Run a Security Pass

Security deserves its own pass. Ask specifically about hard-coded secrets, injection (SQL, NoSQL, command and template), missing authentication or authorisation, and sensitive data written to logs. If your app calls an AI model itself, add prompt injection; our guide on how to secure AI features in your app explains that risk.

Review the same diff for security only. Check for:
- hard-coded secrets, tokens or keys (including tests and config)
- SQL/NoSQL/command/template injection from user input
- missing authentication or authorisation on new routes
- unvalidated input from requests, webhooks, files or env variables
- passwords, tokens or personal data written to logs
- missing signature checks on incoming webhooks

For each finding: quote the line, explain how an attacker could exploit
it in one sentence, rate severity, and give the standard fix for
[language/framework]. If unsure a library function exists, say so.

Checkpoint: You know whether any secret, injection risk or missing access check exists. Any real secret has been revoked and replaced, not just deleted from the file.

Step 4: Find the Missing Tests

Most bugs that reach production were never tested at all. Give the AI the diff plus your existing tests for that area and ask what is not covered, then ask for draft tests in your framework and style.

This is also where a vague worry becomes a concrete test. Our guide to debugging like a detective with AI covers turning bugs into reproducible test cases.

My existing tests for this area:
[paste test file]

List the behaviours in the diff that are NOT covered. Prioritise error
paths, invalid input, boundary values, duplicate requests and
security checks. Then write up to [5] tests in [Jest/Vitest/pytest],
matching my style. Each test should fail if the bug it targets exists.

Checkpoint: You have a list of untested behaviours and draft tests, and you have run them locally.

Step 5: Check Performance and Readability

Once the code is correct and safe, look at how it behaves under load and how easy it is for the next person to understand.

Give the AI a realistic sense of scale. A query that loops over 20 records in testing may loop over 20,000 in production, and a payment callback that runs once a minute today may run hundreds of times during a weekend sale. Without that number, the model cannot judge whether a pattern is harmless or a future outage. For readability, limit the request to a few high-value changes; asking for "all improvements" invites a rewrite you did not need and will have to review all over again.

Review the diff for performance and readability.

Performance: flag queries inside loops, missing pagination or limits,
repeated API calls that could be batched or cached, and anything that
grows badly at [expected scale, e.g. 10,000 orders a day].

Readability: suggest at most 3 changes that would most help a new
developer (naming, splitting a long function, a comment explaining
why). Skip anything a formatter would handle.

Checkpoint: You have a short list of realistic performance risks and no more than three readability changes worth making.

Step 6: Verify Every Suggestion Before You Apply It

This is the step people skip, and it matters most. AI reviewers invent function names, misremember library behaviour, report bugs that do not exist and occasionally suggest "fixes" that add a new vulnerability. Our explainer on what AI hallucination is explains why this happens even with the newest models.

Treat each suggestion as a claim to test. Check the official documentation for any function it mentions, and reproduce the bug with a test before fixing it.

For each issue you raised, tell me:
1. Your confidence (High / Medium / Low) and why
2. How I can verify it myself (a test, a log line, a docs section)
3. Whether your fix could break anything else

Flag any suggestion relying on a function or option you are not
certain exists in [library + version].

Checkpoint: Every fix you plan to apply is confirmed by a failing test, a reproduction or the official docs. Unverified suggestions are noted, not applied.

Step 7: Apply Fixes and Re-Review the New Diff

Apply the verified fixes yourself, or let your coding agent apply them one at a time. Run the full test suite and linter, then review just the fix commits, because fixes are new code too.

If you use a coding agent, give it standing review rules in an instructions file. Our guide on how to write an AGENTS.md for coding agents shows what to include.

Here is a new diff containing only my fixes:
[paste diff]

Confirm each fix addresses the original issue without introducing a
new correctness, security or performance problem. Reply "OK" or give
a specific concern with the quoted line.

Checkpoint: All tests pass, the linter is clean, and the final mini-review raises no new High or Medium issues.

Step 8: Write a Clear Commit Message and Push

Finish by recording what changed and why. You can paste a summary into the free commit message generator or ask your assistant.

Write a conventional commit message for this change: a summary line
under 72 characters, then a short body explaining what changed and
why, noting any security fix or new tests.

Change summary: [your notes or the final diff]

Checkpoint: Your commit message accurately describes the change, and you are ready to push and open a pull request for human review.

Worked Example: A Lagos Developer's Paystack Webhook

Tolu is a backend developer at a small Lagos start-up selling phone accessories online. She has written a Node.js and Express route that receives Paystack webhooks and marks orders as paid. The diff is about 80 lines. Before pushing, she runs this workflow with Claude, having first replaced the test secret key in her .env.example with a placeholder.

Correctness. Claude flags that she compares the Paystack amount directly to the order total, but Paystack sends amounts in kobo while her database stores naira. A ₦25,000 order arrives as 2500000, so every comparison fails. It also notes the handler waits for an email to send before responding, so a slow email provider could make Paystack time out and retry.

Security. The big one: the route never verifies the x-paystack-signature header. Anyone who found the URL could post a fake charge.success event and mark an unpaid order as paid. Claude suggests computing an HMAC SHA512 of the raw request body with her secret key and comparing it to the header. It also spots that she logs the full request body, including customer email addresses.

Tests. Claude lists missing cases: invalid signature, duplicate webhook, amount mismatch and unknown reference. Tolu writes four Jest tests. The duplicate test fails, showing the "order paid" email would be sent twice.

Verify. Tolu checks Paystack's documentation for the signature method and confirms the kobo detail. One helper function Claude named does not exist as described; she uses Node's built-in crypto.timingSafeEqual instead, after checking the Node docs.

Fix. She verifies the signature on the raw body, converts kobo to naira, skips references already marked paid, returns 200 immediately and moves the email to a background job. All tests pass.

The review took about 35 minutes. Without it, the missing signature check alone could have let someone collect goods worth hundreds of thousands of naira without paying.

Common Mistakes

Pasting the whole repository. More code means vaguer feedback. Review the diff plus only the files needed for context.

Asking "is this code good?" Open-ended prompts produce style nitpicks. Run separate passes for correctness, security, tests and performance.

Applying every suggestion. An AI code review produces claims, not facts. Verify each one before changing code.

Deleting a leaked key instead of replacing it. If a secret was ever committed, assume it is compromised. Revoke it and issue a new one.

Skipping human review. AI review is a pre-check, not a replacement for a teammate, especially for payments, authentication and data deletion. Our guide on whether agentic coding is safe for production code explains where human sign-off matters most.

Next Steps

Save these prompts in a snippet tool or your coding agent's instructions file so the routine takes minutes, not effort. Plan each feature first, review before every push, and keep your commit history clean.

If you are building towards an AI-focused role, careful review habits are exactly what employers look for. Our roadmap on how to become an AI engineer shows where this fits among the other skills you will need.

Frequently Asked Questions

Can AI code review replace a human reviewer?

No. It catches common mistakes quickly, but it lacks full knowledge of your system and business rules, and it can be confidently wrong. Use it before human review so teammates can focus on design and logic.

Is it safe to paste my company's code into ChatGPT, Claude or Gemini?

It depends on your employer's policy and your plan. Many companies allow only business or enterprise accounts. Never paste live secrets or customer data, whatever the plan.

Which AI is best for code review?

ChatGPT, Claude and Gemini all handle code review well in 2026, and newer models such as Claude Opus 5.5 and GPT-6 reason well about code. The process matters more than the model. A coding agent can also read related files and run your tests.

How long should the diff be?

Aim for under roughly 300 changed lines per review. For larger branches, review commit by commit so the model can focus.

What if the AI says there is a bug and I disagree?

Ask how to reproduce it, then write a test. If the test passes on your current code, the suggestion was wrong. Tests settle disagreements better than arguments.

Should I let a coding agent fix issues automatically?

You can, but have it apply one fix at a time, show the diff and run the tests after each change. Keep pushing and merging as actions that need your approval.

Does this work for languages other than JavaScript?

Yes. The same prompts work for Python, PHP, Java, Go, Dart and others. State your language, framework and version so suggestions match your stack.