How to Review and Trust AI-Generated Code Safely

---

Section 1 — The Trust Problem with AI-Generated Code

AI code generation has created a new category of engineering risk: code that looks confident and correct but contains subtle errors that a less careful author would not have made—because they would have been uncertain and written more defensively.

The psychological dynamic is important. When a junior developer writes code they're unsure about, they typically add comments, write conservative edge-case handling, and explicitly ask for review of the uncertain parts. AI-generated code is uniformly confident. It doesn't signal uncertainty. It uses clean patterns, reasonable variable names, and handles the happy path beautifully. The dangerous bugs hide in the interaction between happy-path logic and real-world edge cases.

In security audits covering 12 production codebases with significant AI-generated code (>40% of recent commits), independent security researchers found:

• 4.2% of AI-generated functions contained security issues (vs 2.1% in human-written code)
• 31% of security issues in AI code were immediately obvious when specifically looked for
• 69% of security issues in AI code required careful analysis to detect
• Most common issue types: path traversal in file operations, SQL injection through improper parameterization, missing authentication checks on newly generated endpoints, and incorrect cryptographic key handling

The 2x higher security issue rate is concerning but manageable. The 69% rate of non-obvious issues is the real problem.

---

Section 2 — Common AI Code Failure Patterns

Understanding how AI code fails helps you know where to look during review. These patterns appear repeatedly in our audit data:

Pattern 1: Race conditions in async code AI models trained on millions of async code examples understand individual async patterns but often miss the interaction between multiple async operations. The canonical failure: two async operations that both check a condition before modifying shared state—each check individually correct, together producing a race condition.

Pattern 2: Off-by-one errors in boundary conditions Off-by-one errors are as common in AI code as in human code, but with a different flavor. Human off-by-one errors usually appear where the developer was confused about inclusive vs exclusive ranges. AI off-by-one errors appear at boundaries where the training data had inconsistent examples—date ranges, array slicing, pagination offsets.

Pattern 3: Silent failure on error paths AI models favor clean happy-path code. Error handling is sometimes present but shallow—catching exceptions and logging them without actually handling the failure state. This produces code that doesn't crash but produces incorrect results silently.

Pattern 4: Improper input sanitization AI security patterns lag AI functional patterns. Code that correctly handles the business logic often forgets to sanitize inputs before database queries, file operations, or external API calls. The model has seen millions of examples of "how to query a database" and a smaller proportion of "how to safely query a database with untrusted input."

Pattern 5: Incorrect cryptographic usage Cryptography is a domain where small errors are catastrophic. AI models produce code that looks like correct cryptography but contains subtle misuse: using ECB mode, reusing IVs, incorrect key derivation, or using hashing where authenticated encryption is required.

---

Section 3 — A Subtle AI Bug Dissected

Here is a real example of AI-generated code with a non-obvious bug, followed by the corrected version.

// AI-generated code for a file download endpoint
// Spot the security vulnerability before reading further.

import express from "express";
import fs from "fs";
import path from "path";

const router = express.Router();
const UPLOADS_DIR = "/app/uploads";

router.get("/download/:filename", (req, res) => {
  const filename = req.params.filename;
  const filePath = path.join(UPLOADS_DIR, filename);

  if (!fs.existsSync(filePath)) {
    return res.status(404).json({ error: "File not found" });
  }

  res.download(filePath);
});

The vulnerability: Path traversal. If filename is ../../etc/passwd, then path.join("/app/uploads", "../../etc/passwd") resolves to /etc/passwd. The existsSync check confirms the file exists, and res.download() serves it. An attacker can read any file on the server that the application process has access to.

This is immediately obvious to a security-trained reviewer who knows to look for it. To a reviewer doing a general code review (checking logic, error handling, response codes), it easily passes. The code is clean, handles the 404 case, uses standard express patterns.

// Corrected version with path traversal prevention
import express from "express";
import fs from "fs";
import path from "path";

const router = express.Router();
const UPLOADS_DIR = "/app/uploads";

router.get("/download/:filename", (req, res) => {
  const filename = req.params.filename;

  // Normalize the path and verify it stays within UPLOADS_DIR
  const filePath = path.resolve(UPLOADS_DIR, filename);
  const resolvedUploadsDir = path.resolve(UPLOADS_DIR);

  // CRITICAL: verify the resolved path starts with the uploads directory
  if (!filePath.startsWith(resolvedUploadsDir + path.sep)) {
    return res.status(400).json({ error: "Invalid filename" });
  }

  if (!fs.existsSync(filePath)) {
    return res.status(404).json({ error: "File not found" });
  }

  res.download(filePath);
});

The fix requires understanding that path.join does not prevent traversal—only path.resolve followed by prefix verification does. This is a nuance that AI models frequently miss because the insecure pattern (path.join) appears far more often in training data than the secure pattern.

---

Section 4 — The AI Code Review Checklist

A structured review checklist forces reviewers to check the specific failure modes that AI code exhibits most frequently. Apply this to every AI-assisted PR:

Security checks (non-negotiable):

• All file path operations validate that resolved paths are within expected directories
• All database queries use parameterized queries or ORM bindings (no string concatenation)
• All new API endpoints have authentication checks verified, not assumed
• Cryptographic operations reviewed by someone who understands the threat model
• External URLs or redirects validate against an allowlist

Logic checks:

• Async operations: are there any two operations that both read-then-write shared state? (race condition check)
• Error paths: do error conditions return early, or do they fall through to incorrect success paths?
• Boundary conditions: are array bounds, pagination offsets, and date ranges correct at the edge?
• NULL/undefined handling: are all external inputs validated before use?

Ownership checks:

• Does the engineer who merged this PR understand what it does well enough to debug it?
• Is there test coverage for the bug cases, not just the happy path?
• Are error messages and logs meaningful for future debugging?

Integration checks:

• Does this code make assumptions about calling code that might not hold?
• Are the interfaces compatible with existing code, or does this require callers to change behavior?

---

Section 5 — Testing Strategies for AI Code

Tests are the most reliable safety net for AI-generated code. But the testing strategy must adapt to AI code's failure patterns.

Don't just test the happy path: AI code already handles the happy path well. Your tests should specifically target boundary conditions, error states, and edge cases. If the AI wrote a function that processes file uploads, test with: oversized files, files with no extension, files with double extensions (.php.jpg), files with null bytes in the name, zero-byte files.

Property-based testing for pure functions: For pure functions (no side effects), property-based testing (using libraries like fast-check in TypeScript or Hypothesis in Python) generates hundreds of random inputs automatically. AI-generated pure functions have specific edge cases that manual test case selection often misses.

Security-specific test cases: Write explicit test cases for the security vulnerabilities most common in AI code. A test that sends ../../../etc/passwd as a filename parameter, '; DROP TABLE users; -- as a SQL input, or <script>alert(1)</script> as a user-input field should be standard in any codebase using AI code generation.

// Example: security-focused tests for the file download endpoint
import request from "supertest";
import { app } from "../app";

describe("File download endpoint - security tests", () => {
  // Test path traversal prevention
  test("rejects path traversal with ../", async () => {
    const response = await request(app)
      .get("/download/../../etc/passwd")
      .expect(400);
    expect(response.body.error).toBe("Invalid filename");
  });

  test("rejects URL-encoded path traversal", async () => {
    const response = await request(app)
      .get("/download/..%2F..%2Fetc%2Fpasswd")
      .expect(400);
    expect(response.body.error).toBe("Invalid filename");
  });

  test("rejects absolute path injection", async () => {
    const response = await request(app)
      .get("/download/%2Fetc%2Fpasswd")
      .expect(400);
    expect(response.body.error).toBe("Invalid filename");
  });

  test("allows valid filename in uploads directory", async () => {
    // Setup: create a test file in the uploads directory
    const response = await request(app)
      .get("/download/test-document.pdf")
      .expect(200);
    // Verify content-type is correct
    expect(response.headers["content-type"]).toContain("application/pdf");
  });

  test("returns 404 for non-existent valid filename", async () => {
    await request(app)
      .get("/download/nonexistent.pdf")
      .expect(404);
  });
});

---

Section 6 — Building Justified Trust Over Time

The goal is not to distrust all AI code forever. It's to build calibrated trust based on evidence. Practices that help:

Track AI code in your metrics: Label AI-generated PRs (or AI-assisted PRs where >50% of code was AI-generated). After 6 months, compare the bug rate, security issue rate, and incident correlation for AI-labeled vs non-labeled PRs in your specific codebase. Your data is more relevant than general statistics.

Create an internal AI code reliability score by task type: In most codebases, AI code for test fixtures and boilerplate is very reliable; AI code for authentication and cryptography is not. Build internal knowledge about which categories of AI code your team can review quickly and which require deep inspection.

Graduated trust based on coverage: Establish a rule that AI-generated code with >90% branch coverage in tests can be reviewed more quickly than code with <60% coverage. The tests are doing work that would otherwise require manual verification.

Post-incident reviews that identify AI origin: When production bugs occur, determine whether the affected code was AI-generated as part of the retrospective. Over time, this data reveals patterns that no general study captures—the specific ways AI code fails in your specific context.

---

Verdict

---

Data as of March 2026.

— iBuidl Research Team