Amit Shrivastava
Back to Blog
Career & Engineering

Reviewing AI-Generated Code: A Practical Framework for Senior Engineers

What I look for first in a Claude- or Copilot-generated PR — the failure modes that hide in plausible-looking code, and how my review checklist has changed.

Amit ShrivastavaJune 22, 20267 min read

A code snippet from this post was tested

Node.js v22.22.3 · Verified June 22, 2026

Logic from this post, adapted into a runnable form and executed by the publishing pipeline.

node verify.mjs

Snippet

function processUserData(data) {
  if (!data) {
    console.log("Error: Input data is null or undefined.");
    return null;
  }

  // Simulate strict type definitions and basic validation
  if (typeof data.id !== 'string') {
    console.log("Error: 'id' must be a string.");
    return null;
  }
  if (typeof data.name !== 'string') {
    console.log("Error: 'name' must be a string.");
    return null;
  }
  if (typeof data.email !== 'string' || !data.email.includes('@')) {
    console.log("Error: 'email' must be a valid email string.");
    return null;
  }
  if (data.age !== undefined && typeof data.age !== 'number') {
    console.log("Error: 'age' must be a number if provided.");
    return null;
  }
  if (data.age !== undefined && (data.age < 0 || data.age > 150)) {
    console.log("Error: 'age' must be between 0 and 150.");
    return null;
  }


  // Simulate processing
  const processedId = data.id.trim();
  const processedName = data.name.toUpperCase();
  const processedEmail = data.email.toLowerCase();

  return {
    id: processedId,
    name: processedName,
    email: processedEmail,
    age: data.age || null, // Handle optional age
    processedAt: "2024-01-01T12:00:00Z" // Deterministic timestamp
  };
}

console.log("--- Valid Input ---");
console.log(processUserData({ id: "user123", name: "Alice", email: "alice@example.com", age: 30 }));

console.log("\n--- Valid Input without Age ---");
console.log(processUserData({ id: "user456", name: "Bob", email: "bob@example.com" }));

console.log("\n--- Input with leading/trailing spaces ---");
console.log(processUserData({ id: "  user789  ", name: "Charlie  ", email: " Charlie@EXAMPLE.COM " }));

console.log("\n--- Invalid ID Type ---");
console.log(processUserData({ id: 123, name: "David", email: "david@example.com" }));

console.log("\n--- Invalid Email Format ---");
console.log(processUserData({ id: "user101", name: "Eve", email: "eveexample.com" }));

console.log("\n--- Invalid Age Type ---");
console.log(processUserData({ id: "user102", name: "Frank", email: "frank@example.com", age: "twenty" }));

console.log("\n--- Age out of bounds ---");
console.log(processUserData({ id: "user103", name: "Grace", email: "grace@example.com", age: 200 }));

console.log("\n--- Null Input ---");
console.log(processUserData(null));

console.log("\n--- Undefined Input ---");
console.log(processUserData(undefined));

console.log("\n--- Missing Required Field (name) ---");
console.log(processUserData({ id: "user104", email: "heidi@example.com" }));

Captured output

--- Valid Input ---
{
  id: 'user123',
  name: 'ALICE',
  email: 'alice@example.com',
  age: 30,
  processedAt: '2024-01-01T12:00:00Z'
}

--- Valid Input without Age ---
{
  id: 'user456',
  name: 'BOB',
  email: 'bob@example.com',
  age: null,
  processedAt: '2024-01-01T12:00:00Z'
}

--- Input with leading/trailing spaces ---
{
  id: 'user789',
  name: 'CHARLIE  ',
  email: ' charlie@example.com ',
  age: null,
  processedAt: '2024-01-01T12:00:00Z'
}

--- Invalid ID Type ---
Error: 'id' must be a string.
null

--- Invalid Email Format ---
Error: 'email' must be a valid email string.
null

--- Invalid Age Type ---
Error: 'age' must be a number if provided.
null

--- Age out of bounds ---
Error: 'age' must be between 0 and 150.
null

--- Null Input ---
Error: Input data is null or undefined.
null

--- Undefined Input ---
Error: Input data is null or undefined.
null

--- Missing Required Field (name) ---
Error: 'name' must be a string.
null

Reviewing AI-Generated Code: My Evolving Framework for Senior Engineers

The rise of AI code generation tools like GitHub Copilot and Claude has been nothing short of transformational. As a senior engineer with over a decade of experience across various domains – from intricate frontend architectures to the wild west of Web3 and now deep into AI applications – I've seen technologies come and go. But AI-generated code... that's a different beast. It's not just a new tool; it's a paradigm shift in how we write and review software.

Initially, I approached AI-generated PRs with a healthy dose of skepticism, largely reviewing them as I would any human-written code. But I quickly realized that AI has its own unique failure modes, often hiding in plain sight within surprisingly plausible-looking code. My review checklist has had to adapt significantly. This post outlines my practical framework for reviewing AI-generated code, focusing on what I look for first to catch those subtle-yet-critical issues.

The Allure and the Trap: Why AI Code Needs a Different Eye

AI excels at boilerplate, pattern recognition, and quickly churning out functional code. It can save immense amounts of time and mental energy. However, this efficiency can lead to a false sense of security. AI doesn't understand context, long-term implications, or the nuanced "why" behind design decisions in the same way a human does. It's a highly capable assistant, not a replacement for engineering judgment.

The biggest trap? Code that looks perfectly fine. It compiles, passes basic tests, and even adheres to conventions. But beneath the surface lie issues that can range from performance bottlenecks to security vulnerabilities, subtle logical errors, or even just overly complex solutions that make future maintenance a nightmare.

My AI Code Review Checklist: What I Prioritize

When I encounter a PR that heavily leverages AI (and let's be honest, most of them do now), my review process typically follows these steps, prioritizing specific checks that address common AI pitfalls.

1. The "Does it Make Sense?" Gut Check & Prompt Reconstruction

Before diving into lines of code, I try to understand the intention. What problem is this PR solving? Then, I try to reverse-engineer the likely prompt that would have generated this code.

  • Is the solution overly generic or specific? AI often provides the 'most common' solution, which might be overkill for a simple problem or insufficient for a complex, edge-case-heavy scenario.
  • Could this have been done more simply? AI loves patterns. Sometimes, it applies a pattern where a simpler, direct approach would be better.
  • Initial glance for "why." If the diff looks extensive for a seemingly simple feature, that's a red flag. What's the AI over-engineering?

2. Input Validation and Type Safety: The First Line of Defense

This is almost always my very first technical deep dive. AI is notoriously bad at anticipating all possible inputs, especially edge cases or malicious ones.

  • Strict Type Definitions (TypeScript): Are all function parameters and return types explicitly defined and as strict as possible? AI might infer broader types than necessary, leading to potential runtime issues.

// AI might generate this:
function processUserData(data: any): any { /* ... */ }

// What I'd want to see:
interface UserData {
  id: string;
  name: string;
  email: string;
  age?: number; // Optional fields are crucial
}
function processUserData(data: UserData): ProcessedResult { /* ... */ }
  • Runtime Input Validation: Even with TypeScript, untrusted inputs (e.g., from an API, user form) need runtime validation. AI often omits this unless explicitly prompted. I look for:
  • Null/undefined checks.
  • Type coercion issues (e.g., expecting a number but getting a string).
  • Boundary checks (e.g., array lengths, number ranges).
  • Input sanitization (especially if interacting with external systems or databases).

3. Security Implications: The Silent Killers

AI code, while syntactically correct, might inadvertently introduce security vulnerabilities because it lacks a security context.

  • Authentication/Authorization Bypasses: Is the code interacting with sensitive data or functionality? Are required auth checks in place? AI can easily forget to add a requireAdmin middleware, for instance.
  • SQL Injection / XSS: If the code builds queries or renders user-supplied content, are proper escaping and parameterized queries used? AI might generate string concatenation for queries.
  • Data Leaks/Over-fetching: Is the API endpoint returning more data than necessary? AI might default to selecting * or returning full objects when only a subset is needed.

4. Edge Cases and Error Handling: The Unseen Paths

AI tends to optimize for the "happy path." What happens when things go wrong?

  • Error Handling: Are try...catch blocks present where network calls, file operations, or other prone-to-failure actions occur? Are error messages informative but not overly verbose (avoiding internal details)?
  • Empty States/Null Results: What if a query returns no data? Does the UI crash, or does it gracefully handle an empty array? What if an optional field is missing?
  • Asynchronous Operations: Are promises handled correctly? Are awaits used appropriately, and are there potential race conditions in complex asynchronous flows?

5. Performance and Resource Management: The Hidden Costs

AI doesn't always optimize for efficiency or resource use, especially without explicit prompts.

  • N+1 Queries: A classic AI oversight in database interactions. If looping through a collection and making a database call for each item, that's a red flag. Look for ways to batch or eager-load.
  • Memory Leaks: Especially in frontend code, are listeners cleaned up? Are large objects explicitly de-referenced if no longer needed? (Less common for AI to introduce these directly, but it might not avoid them.)
  • Unnecessary Computations: Is the AI performing redundant calculations within a loop or re-computing values that could be cached?

6. Readability, Maintainability, and DX: The Long Game

While AI is getting better at adhering to style guides, it can still generate overly complex or verbose code.

  • Clarity over Cleverness: Is the code easy for another human (or future AI) to understand? AI sometimes finds "clever" one-liner solutions that are hard to parse.
  • Appropriate Abstractions: Has the AI created too many or too few abstractions? Is a simple utility function wrapped in three layers of classes?
  • Comments (or lack thereof): AI can generate great comments, but sometimes they're generic or even misleading. I prefer clear code over excessive, redundant comments. If a complex piece of logic needs a comment, it should explain the why, not just the what.

A Visual Guide to My Review Flow

Here's a simplified flowchart illustrating my initial mental process when reviewing AI-generated code.

graph TD
    A[Start: Review PR] --> B{AI Generated Code?};
    B -- Yes --> C[Understand Intention & Prompt];
    B -- No --> J[Standard Human Code Review];
    C --> D[Check Input Validation & Types];
    D -- Issues Found --> E[Request Changes];
    D -- Looks Good --> F[Check Security & Error Handling];
    F -- Issues Found --> E;
    F -- Looks Good --> G[Check Edge Cases & Performance];
    G -- Issues Found --> E;
    G -- Looks Good --> H[Review Readability & Maintainability];
    H -- Issues Found --> E;
    H -- Looks Good --> I[Approve PR];
    E --> A;

The Evolving Landscape: A Senior Engineer's Perspective

This framework isn't static. As AI models improve, some of these "failure modes" will become less common. But the fundamental principle remains: AI is a tool, not a colleague. It doesn't bear the ultimate responsibility for the software's quality or impact. That responsibility still rests squarely with us, the engineers.

Embracing AI means adapting our skills, and for senior engineers, that means evolving our review processes to leverage AI's strengths while diligently guarding against its unique weaknesses. It's about coaching the AI, much like we coach junior engineers: provide clear instructions, set boundaries, and rigorously review the output with an eye for the subtle pitfalls.

I hope this framework provides a useful starting point for your own AI code review practices.

Feel free to connect with me on LinkedIn: https://www.linkedin.com/in/amit-shrivastava or X: https://x.com/amit5214. I'm always keen to discuss best practices in software engineering, AI, and the future of development!

Code Review
AI Coding
Engineering Practice
Quality