█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Web Development/AI Application: Web Development/AI-Assisted Code Review
40 minBeginner

AI-Assisted Code Review

After this lesson, you will be able to: Use Claude (or Claude Code, or Cursor's chat) to review your own diff for bugs and security issues BEFORE you push to GitHub, and know which findings to act on, which to discuss, and which to ignore.

Every senior engineer reviews their own diff before posting a PR. AI gives juniors the same superpower. This lesson takes you from never having asked an AI to review your code to a repeatable workflow that catches the bugs a human reviewer would catch on the first read, and saves you the embarrassment of pushing them.

Prerequisites:Prompt Engineering for Developers

Why self-review beats no-review

Code you wrote 20 minutes ago looks fine because your brain is still in the context that produced it. Read it tomorrow and the bugs are obvious. AI gives you the 'read it tomorrow' perspective right now. Self-review with AI catches: typos that compile, missing null checks, off-by-one errors, missing edge cases, inconsistent naming, missing test cases, missing error handling, and obvious security issues (SQL string concat, missing input validation, leaked tokens). It does NOT catch: subtle architectural problems, performance issues that only appear at scale, requirements bugs (you built the wrong thing). Use it for what it's good at.

The basic self-review prompt

Paste your diff (from `git diff` or your editor's source-control panel) and ask for review. Below is the prompt you can copy verbatim.

tsx
# Use the actual `git diff` output, or the file content if your changes are larger.
Review this diff for:
- Bugs (logic errors, missing edge cases, off-by-one)
- Security issues (auth, input validation, secrets in client code)
- Missing error handling
- Code that violates the project's existing conventions
Do NOT comment on style or formatting, my linter handles that.
For each issue, give:
- File and line
- What's wrong
- Why it matters
- Suggested fix (one line if possible)
If you don't see any issues in a category, say "no issues found", don't invent.
```diff
<paste git diff here>
```

The Claude Code shortcut

If you use Claude Code in the terminal, you don't need to copy/paste the diff at all. Run `git diff` in the same project and ask Claude to review your uncommitted changes, Claude Code reads the diff directly. Same idea with Cursor's chat: open the file, click 'Add to chat,' and ask 'review my changes for bugs.' The editor sends the relevant context for you.

Sample bad code that AI review catches

Below is the kind of code juniors push to PR all the time. Run it through the self-review prompt and AI will flag at least three issues. Try it in your own AI tool of choice, see what shows up.

python
// src/app/api/posts/route.ts
import { prisma } from "@/lib/prisma";
export async function POST(request: Request) {
const body = await request.json();
const post = await prisma.post.create({
data: {
title: body.title,
body: body.body,
userId: body.userId, // ← trusting client input for ownership
},
});
return Response.json(post);
}
// Things AI review will (correctly) flag:
// 1. No input validation, body could be anything, breaks at runtime
// or stores garbage in the DB. Suggested fix: Zod schema.
// 2. userId comes from the request body, anyone can create posts AS
// other users by changing the JSON. Use the authenticated session
// user instead, not body.userId.
// 3. No error handling, if the DB call throws, the request 500s with
// no useful response. Wrap in try/catch and return a clean error.
// 4. Returns 200 by default for a POST that created a resource;
// should be 201.

Which findings to act on, which to skip

AI review can be noisy. Apply this filter to every finding: **Always act on:** security issues (auth, validation, leaks), real bugs (missing null check, wrong condition), missing error handling on operations that can fail. **Discuss before acting on:** convention violations (maybe it's intentional), 'consider also' suggestions (extra features that weren't asked for), performance optimizations without measurement. **Skip:** style/formatting comments (your linter handles those, don't waste prompt budget asking), advice to add tests you've already written elsewhere, suggestions that contradict your codebase's existing pattern.

💡 Security focus — the questions AI reliably answers well

AI is genuinely good at spotting these categories, make a habit of asking explicitly: (1) Where does user input enter this code? Is it validated before use? (2) Does any string interpolation hit a database query, shell command, or HTML output? (SQL injection / command injection / XSS.) (3) Could any API key or secret end up in client-side code? (4) Are there auth checks on every endpoint that modifies state? (5) Does this endpoint trust a value from the request body that should come from the authenticated session?

Self-review prompt template

Draft a reusable self-review prompt that you can paste before any diff. Required patterns check for: explicit review categories (security and bugs at minimum), an instruction to NOT comment on formatting/style, and a request for file+line+fix output format.

Loading exercise…

💡 Common mistakes only experienced devs catch

Five self-review traps. (1) **Acting on every AI suggestion**, produces noisy PRs full of unnecessary refactors. Apply the filter; skip noise. (2) **Skipping the review when you're confident**, that's exactly when you ship the typo. Run review on EVERY meaningful diff. (3) **Asking 'review this' with no scope**, produces a wishlist. Always specify categories (bugs, security, error handling) so the model focuses. (4) **Trusting AI's 'no issues found' as proof of correctness**, it caught what it saw; humans still find things. AI review is a filter on top of, not a replacement for, your own read-through. (5) **Treating AI review as the final review**, for any code that matters, get a human on the PR too. AI catches the easy stuff; humans catch the architectural and 'wait, does this even solve the right problem?' bugs.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Prompt Engineering for Developers
Back to AI Application: Web Development
What AI Cannot Replace→