Code Review with AI: Catch Bugs Before They Ship

1. 1

   Submit Your Code for Initial Review

   Give the AI your code with context about what it does, what language/framework you're using, and what specifically you're concerned about. Context makes AI reviews 10x more useful than blind paste-and-pray.

   Claude ChatGPT

   Review this code. I'll give you the code and context.
   
   **Context:**
   - Language/Framework: [e.g., Python 3.11 / TypeScript + React / Go / Rust]
   - What this code does: [1-2 sentence description, e.g., 'Handles user authentication and session management for our API']
   - This is a: [new feature / bug fix / refactor / performance optimization]
   - Related to (if applicable): [what part of the system, what PR/issue it addresses]
   - My main concerns: [e.g., 'I'm not sure the error handling is right' / 'Worried about SQL injection' / 'Performance might be an issue with large datasets' / 'Just want a general review']
   - Code standards we follow: [e.g., 'PEP 8 for Python' / 'Airbnb style guide for JS' / 'Our team prefers explicit error handling over try-catch blocks']
   
   **Code:**
   ```[language]
   [Paste your code here]
   ```
   
   **Review this code for:**
   
   1. **Bugs and Logic Errors**: Any code paths that would produce incorrect results, unhandled edge cases, off-by-one errors, race conditions, null/undefined access.
   
   2. **Security Vulnerabilities**: SQL injection, XSS, CSRF, insecure authentication, hardcoded secrets, path traversal, insecure deserialization, IDOR, or other OWASP Top 10 issues.
   
   3. **Performance Issues**: N+1 queries, unnecessary allocations, blocking operations in async contexts, missing indexes (if DB queries visible), unbounded loops or recursion, memory leaks.
   
   4. **Error Handling**: Missing error handlers, swallowed exceptions, unclear error messages, missing input validation, improper use of try-catch.
   
   5. **Code Quality**: Readability, naming, single responsibility principle, DRY violations, overly complex logic, dead code, unclear control flow.
   
   For each finding:
   - Severity: CRITICAL / WARNING / SUGGESTION
   - Line number(s)
   - What the problem is
   - Why it matters (impact if unfixed)
   - Suggested fix (with code)
   
   Start with CRITICAL issues, then WARNINGS, then SUGGESTIONS.

   Copy

   Tip: Always include what the code is supposed to do. AI can check syntax and patterns without context, but it can only find logic errors if it knows the intended behavior. 'This function should return the user's total spend in the last 30 days, excluding refunded orders' lets AI verify the logic. Without that, it just checks if the code runs.

2. 2

   Deep Dive on Security and Edge Cases

   After the general review, run a focused security audit and edge case analysis. This is where AI adds the most value -- it systematically checks for attack vectors and boundary conditions that humans skip when they're familiar with the code.

   Claude ChatGPT

   Now do a deep security and edge case analysis on the same code.
   
   **Security Audit:**
   
   1. **Input Validation**: For every function parameter and user input:
      - What happens if the input is null/undefined/empty string?
      - What happens if the input is extremely large (100MB string, integer overflow, 1M array elements)?
      - What happens if the input contains special characters, SQL, HTML, or shell commands?
      - What happens if the input type is wrong (string where number expected)?
      - Are there any inputs that could cause the function to hang or crash?
   
   2. **Authentication/Authorization**: If applicable:
      - Can this endpoint be accessed without authentication?
      - Can user A access user B's data through this code?
      - Are there any privilege escalation paths?
      - Are session tokens/API keys handled securely (not logged, not in URLs)?
   
   3. **Data Exposure**:
      - Does this code ever log, return, or display sensitive data (passwords, tokens, PII)?
      - Are error messages revealing internal details (stack traces, file paths, database schemas)?
   
   4. **Dependency Risks**:
      - Are there any known vulnerabilities in the libraries/packages used?
      - Are dependencies pinned to specific versions?
   
   **Edge Case Analysis:**
   
   5. **Boundary Conditions**:
      - What happens at exactly 0, 1, MAX_INT?
      - What happens with an empty collection (empty array, empty object, no rows returned)?
      - What happens with a single-element collection?
      - What happens at exactly the boundary of any if/else condition?
   
   6. **Concurrency Issues** (if applicable):
      - Can two requests hit this code simultaneously and corrupt state?
      - Are database operations atomic where they need to be?
      - Are there any time-of-check-time-of-use (TOCTOU) vulnerabilities?
   
   7. **Failure Modes**:
      - What happens if the database is down?
      - What happens if an external API call times out?
      - What happens if disk space or memory is exhausted?
      - Is there a graceful degradation path or does it crash hard?
   
   For each finding, provide a test case I can run to reproduce the issue.

   Copy

   Tip: The most dangerous bugs are the ones that work 99% of the time. Focus on the 1% cases: empty inputs, concurrent access, network timeouts, clock skew, timezone boundaries, leap years, unicode characters, and extremely long strings. These are the bugs that make it through QA and blow up in production at 2 AM.

3. 3

   Get Refactoring Suggestions

   Once bugs and security issues are fixed, ask for structural improvements. This is about making the code easier to read, test, and maintain -- not just correct.

   Claude Cursor

   Now suggest refactoring improvements for this code. I've addressed the bugs and security issues you found. Here's the updated version:
   
   ```[language]
   [Paste updated code or say 'same code as before, assume previous issues are fixed']
   ```
   
   Focus on:
   
   1. **Readability**:
      - Any function longer than 30 lines that should be split?
      - Variable/function names that could be clearer?
      - Complex conditionals that could be simplified?
      - Magic numbers or strings that should be constants?
      - Comments that are missing (for WHY, not WHAT) or comments that are redundant?
   
   2. **Testability**:
      - Are there tightly coupled dependencies that make unit testing hard?
      - Should any part of this code be extracted into a pure function (no side effects) for easier testing?
      - Are there hidden dependencies (global state, environment variables, time-dependent behavior)?
   
   3. **Design Patterns**:
      - Would any standard pattern improve this code? (strategy, factory, observer, etc. — only if it genuinely simplifies things, not for pattern-for-pattern's-sake)
      - Is there repeated logic that could be extracted into a shared utility?
      - Should any of this be made more generic vs. more specific?
   
   4. **Modern Language Features**:
      - Am I using outdated patterns where my language version has a better alternative? (e.g., using callbacks instead of async/await, manual null checks instead of optional chaining)
   
   5. **Architecture Considerations**:
      - Is this code in the right layer of the application? (business logic in a controller, data access in a service, etc.)
      - Are the function interfaces (parameters, return types) clean and predictable?
      - Would this scale if the codebase grows 10x?
   
   For each suggestion:
   - Show the current code
   - Show the refactored version
   - Explain the benefit (not just 'cleaner' — be specific: 'easier to unit test because X is now injectable' or 'reduces cognitive load from 4 nested conditionals to 1 guard clause')
   
   Prioritize suggestions by impact. I don't want 30 nitpicks — give me the 5-8 changes that would make the biggest difference.

   Copy

   Tip: Don't refactor and fix bugs in the same commit. Fix bugs first, ship that, then refactor separately. Mixing functional changes with structural changes makes code review harder and makes rollbacks dangerous if something breaks.

4. 4

   Generate Tests for Your Code

   Ask AI to generate test cases based on the code and the edge cases it identified. AI is surprisingly good at writing tests because the logic of 'given X input, expect Y output' is straightforward to generate.

   Claude ChatGPT Cursor

   Write comprehensive tests for this code:
   
   ```[language]
   [Paste your final, reviewed code]
   ```
   
   Testing framework: [e.g., pytest / Jest / Go testing / RSpec / JUnit]
   Test style preference: [e.g., Arrange-Act-Assert / Given-When-Then / our team prefers descriptive test names]
   
   Generate tests covering:
   
   1. **Happy Path Tests** (3-5 tests):
      - The most common, expected use cases
      - Each test should verify one specific behavior
      - Use realistic but simple test data
   
   2. **Edge Case Tests** (5-8 tests):
      - Empty/null inputs
      - Boundary values (0, 1, max, min)
      - Single-element collections
      - Exactly at conditional boundaries
      - Duplicate inputs
      - Maximum length/size inputs
   
   3. **Error Case Tests** (3-5 tests):
      - Invalid inputs (wrong type, malformed data)
      - Missing required fields
      - External dependency failures (mock these)
      - Permission/authorization failures
   
   4. **Security Tests** (2-3 tests):
      - SQL injection attempt in input fields
      - XSS payloads in string inputs
      - Authorization bypass attempts
   
   5. **Performance Sanity Tests** (1-2 tests, if applicable):
      - Execution time with large dataset (should complete under X ms)
      - Memory usage stays within bounds
   
   For each test:
   - Descriptive name that explains what it tests and what the expected outcome is
   - Setup (arrange), execution (act), and assertion (assert) clearly separated
   - Comments explaining WHY this test exists (what bug it prevents)
   
   Also generate:
   - A test data factory/fixture if multiple tests share similar setup
   - Mock definitions for external dependencies
   - Instructions for running the tests
   
   Do NOT mock the code under test itself — only mock external dependencies.

   Copy

   Tip: Write the test names first, before the test code. If you can't describe what a test checks in its name, the test is probably testing the wrong thing. Good test name: 'test_returns_empty_list_when_user_has_no_orders.' Bad test name: 'test_get_orders_2.' The name IS the documentation.

5. 5

   Create a Review Summary and Action Items

   Package the entire review into a structured summary you can share with your team or attach to the PR. This is especially useful if your team doesn't have a formal code review process yet.

   Claude ChatGPT

   Create a code review summary I can post as a PR comment or share with my team.
   
   Based on everything we've discussed in this review, produce:
   
   **Review Summary**
   
   PR/Change: [title of the change]
   Reviewer: AI-assisted review
   Date: [today's date]
   
   **Overall Assessment**: [Ship it / Ship with minor fixes / Needs changes before shipping / Major rework needed]
   
   **Critical Issues** (must fix before merge):
   - [ ] Issue 1: [one line summary] — Line [X]
   - [ ] Issue 2: [one line summary] — Line [X]
   
   **Warnings** (should fix, can be follow-up):
   - [ ] Warning 1: [one line summary] — Line [X]
   - [ ] Warning 2: [one line summary] — Line [X]
   
   **Suggestions** (nice to have):
   - [ ] Suggestion 1: [one line summary]
   - [ ] Suggestion 2: [one line summary]
   
   **Security Findings**:
   - [List any security issues with severity rating]
   
   **Test Coverage**:
   - Current estimated coverage for this change: [%]
   - Tests that should be added: [list]
   
   **Architecture Notes**:
   - [Any observations about how this change fits into the broader codebase]
   
   **Positive Notes** (what's done well — good code review includes praise):
   - [List 2-3 things the author did well]
   
   Format this as markdown so it can be pasted directly into a GitHub/GitLab PR comment.

   Copy

   Tip: Use AI code review as the FIRST review pass, not the only one. Post the AI review summary, fix the mechanical issues it found, then ask a human teammate to review for architecture decisions, business logic correctness, and whether the approach makes sense in the context of your team's roadmap. AI catches what humans skip; humans catch what AI can't understand.

Recommended Tools for This Scenario

Claude

Freemium

Anthropic's AI assistant built for thoughtful analysis and safe, nuanced conversations

• 200K token context window for massive document processing
• Artifacts — interactive side-panel for code, docs, and visualizations
• Projects with persistent context and custom instructions

Get Started →

ChatGPT

Freemium

The AI assistant that started the generative AI revolution

• GPT-4o multimodal model with text, vision, and audio
• DALL-E 3 image generation
• Code Interpreter for data analysis and visualization

Get Started →

CodeRabbit

Freemium

AI-powered code review for GitHub and GitLab PRs with line-by-line analysis

• Automated line-by-line PR code review
• Security vulnerability and bug detection
• PR description and changelog generation

Get Started →

Cursor

Freemium

AI-native code editor with deep multi-model integration and agentic coding

• AI-native Cmd+K inline editing and generation
• Composer Agent for autonomous multi-file changes
• Full codebase indexing and context awareness

Get Started →