The Most Common Categories of AI-Generated Code Bugs

AI-generated code most frequently contains bugs in six categories: authentication and authorization, payment and billing logic, error handling, data integrity, infrastructure security, and concurrency. These aren't random failures—they follow predictable patterns that stem from how large language models learn and generate code.

Understanding these categories isn't academic. When AI writes your code, knowing where it systematically fails lets you focus review time where it matters. This taxonomy is grounded in patterns observed across thousands of AI-generated code reviews, categorized by failure mode and business impact.

Why AI Code Fails in Predictable Ways

LLMs generate code by predicting the most likely next token based on training data. This creates three structural blind spots:

Happy path optimization. Training data contains far more examples of code that handles success than code that handles failure. The model learns to write the common case well and the edge cases poorly—or not at all.

Missing system context. A function that looks correct in isolation may be dangerously wrong in context. The model can't see your authentication middleware, your webhook retry policy, or your database isolation level.

Security as afterthought. Security code is often added after the fact in real codebases, appearing less frequently in training data. The model reproduces this pattern, generating functional code that lacks security controls.

These blind spots manifest as specific, categorizable bugs. Here's the taxonomy.

Category 1: Authentication and Authorization Gaps

Authorization bugs are among the most dangerous because they're invisible in testing. The code works—it just works for everyone, including attackers.

The AI Tendency

AI-generated code frequently implements authentication (who you are) but skips authorization (what you're allowed to do). You'll see login flows that work correctly, then API endpoints that serve data to any authenticated user without checking ownership.

Why It Happens

Training data contains countless examples of fetching records by ID:

// AI-generated: looks correct, dangerously wrong
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await db.documents.findById(req.params.id);
  res.json(doc);
});

The model has seen this pattern thousands of times. It's syntactically correct and will pass most tests. But any authenticated user can access any document by guessing IDs.

The Fix

Authorization requires checking ownership or permissions on every request:

// Correct: verify the user owns this document
app.get('/api/documents/:id', authenticate, async (req, res) => {
  const doc = await db.documents.findOne({
    _id: req.params.id,
    userId: req.user.id  // ownership check
  });
  if (!doc) return res.status(404).json({ error: 'Not found' });
  res.json(doc);
});

Category 2: Payment and Billing Logic Errors

Payment bugs have direct financial impact. AI-generated payment code exhibits three critical failure patterns with alarming consistency.

Pattern A: Premature Fulfillment

The AI tendency: Granting access when a PaymentIntent is created rather than when payment succeeds.

// AI-generated: grants access before payment clears
const paymentIntent = await stripe.paymentIntents.create({
  amount: 2000,
  currency: 'usd',
});
await grantPremiumAccess(userId);  // Wrong: payment hasn't succeeded yet

The PaymentIntent creation is just the start of the flow. The card might decline, the user might abandon checkout, 3D Secure might fail. Fulfillment must wait for payment_intent.succeeded.

Pattern B: Missing Webhook Signature Verification

The AI tendency: Processing webhook payloads without verifying they came from Stripe.

// AI-generated: accepts any POST as a valid webhook
app.post('/webhook', async (req, res) => {
  const event = req.body;  // Wrong: no signature verification
  if (event.type === 'payment_intent.succeeded') {
    await grantPremiumAccess(event.data.object.metadata.userId);
  }
  res.sendStatus(200);
});

Without stripe.webhooks.constructEvent() verifying the signature, anyone can POST a forged event and grant themselves access. The fix requires using the raw request body (not parsed JSON) with the webhook secret:

const event = stripe.webhooks.constructEvent(
  req.rawBody,  // Must be raw, not parsed
  req.headers['stripe-signature'],
  process.env.STRIPE_WEBHOOK_SECRET
);

Pattern C: Missing Idempotency

The AI tendency: Processing webhooks without checking if they've already been handled.

Stripe retries webhooks on timeout or 5xx responses. Without idempotency checks, the same event processes multiple times—double charges, duplicate fulfillment, incorrect inventory counts.

// AI-generated: will process the same event multiple times
app.post('/webhook', async (req, res) => {
  const event = verifyWebhook(req);
  if (event.type === 'checkout.session.completed') {
    await fulfillOrder(event.data.object);  // Runs on every retry
  }
  res.sendStatus(200);
});

The fix requires storing and checking processed event IDs:

if (await redis.get(`webhook:${event.id}`)) {
  return res.sendStatus(200);  // Already processed
}
await redis.set(`webhook:${event.id}`, 1, 'EX', 86400);
await fulfillOrder(event.data.object);

For production payment code, expert verification catches these patterns before they cost money.

Category 3: Silent Error Handling Failures

This category is pervasive. AI-generated code swallows errors at a rate that makes debugging nearly impossible.

The AI Tendency

Empty catch blocks, silent retry exhaustion, and errors that vanish into the void:

// AI-generated: errors disappear completely
async function withRetry(fn, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (e) {
      // Empty: error information discarded
    }
  }
  // Returns undefined after all failures, no indication of what happened
}

After three failures, this function returns undefined with no logging, no error propagation, nothing. The caller has no idea anything went wrong.

Why It Happens

Training data contains enormous amounts of try/catch code written for brevity or during prototyping. The model learns that catch blocks often do nothing—because in examples, they often don't.

The Fix

Capture the last error and throw it after retry exhaustion. Log intermediate failures:

async function withRetry(fn, attempts = 3) {
  let lastError;
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (e) {
      lastError = e;
      console.error(`Attempt ${i + 1} failed:`, e.message);
      await sleep(Math.pow(2, i) * 100);  // Exponential backoff
    }
  }
  throw lastError;  // Propagate the failure
}

For webhook handlers specifically, return proper HTTP status codes: 500 for retriable failures (so the sender retries), 200 only on genuine success.

Category 4: Data Integrity Violations

AI-generated code frequently violates data integrity constraints that aren't enforced at the database level.

The AI Tendency

Writing code that assumes operations succeed, without transactions or consistency checks:

// AI-generated: partial failure leaves inconsistent state
async function transferFunds(fromId, toId, amount) {
  await db.accounts.decrement(fromId, { balance: amount });
  await db.accounts.increment(toId, { balance: amount });  // What if this fails?
}

If the second operation fails, money disappears from one account without appearing in the other.

Why It Happens

Transaction handling is often separated from business logic in training examples. The model sees the happy path far more often than the rollback path.

The Fix

Use database transactions with proper rollback:

async function transferFunds(fromId, toId, amount) {
  await db.transaction(async (trx) => {
    await trx.accounts.decrement(fromId, { balance: amount });
    await trx.accounts.increment(toId, { balance: amount });
  });  // Automatically rolls back if either fails
}

Category 5: Infrastructure and SSRF Vulnerabilities

Server-Side Request Forgery (SSRF) appears frequently in AI-generated code that fetches user-provided URLs.

The AI Tendency

Fetching URLs without validating the target:

// AI-generated: SSRF vulnerability
app.post('/fetch-preview', async (req, res) => {
  const response = await fetch(req.body.url);  // User controls the URL
  const html = await response.text();
  res.json({ preview: extractPreview(html) });
});

An attacker can provide http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint) or internal service URLs, potentially accessing credentials or internal APIs.

Why It Happens

Training data contains countless examples of fetch(url) without security context. The model doesn't understand network topology or the difference between internal and external resources.

The Fix

Validate URLs against an allowlist of protocols and domains, or use a proxy service that enforces boundaries:

function isUrlAllowed(url) {
  const parsed = new URL(url);
  if (!['http:', 'https:'].includes(parsed.protocol)) return false;
  if (isPrivateIP(parsed.hostname)) return false;
  return true;
}

Category 6: Concurrency and Race Conditions

AI-generated code assumes sequential execution even in concurrent environments.

The AI Tendency

Check-then-act patterns without atomicity:

// AI-generated: race condition
async function claimReward(userId, rewardId) {
  const reward = await db.rewards.findById(rewardId);
  if (reward.claimed) {
    return { error: 'Already claimed' };
  }
  await db.rewards.update(rewardId, { claimed: true, claimedBy: userId });
  await grantReward(userId, reward);
}

Two simultaneous requests both see claimed: false, both proceed, both grant the reward. Double-spending in a few lines of innocent-looking code.

Why It Happens

Sequential reasoning is what LLMs do. They generate one token after another. Concurrent execution with multiple actors violates the model's fundamental paradigm.

The Fix

Use atomic operations or pessimistic locking:

async function claimReward(userId, rewardId) {
  const result = await db.rewards.updateOne(
    { _id: rewardId, claimed: false },  // Atomic check-and-update
    { $set: { claimed: true, claimedBy: userId } }
  );
  if (result.modifiedCount === 0) {
    return { error: 'Already claimed or not found' };
  }
  await grantReward(userId, reward);
}

Building Defenses Against AI Code Bugs

Knowing the taxonomy is the first step. Building systematic defenses requires:

Pattern-based automated review. Tools like Fairy Scout flag known dangerous patterns before they reach production. Automated checks catch the obvious cases.

Domain expert verification. The most dangerous bugs require human judgment. Someone who understands payment flows, auth boundaries, and distributed system invariants catches what static analysis misses. This is what Fairy for Code provides—expert sign-off before AI-generated code ships.

Structured review focus. Don't review AI code the same way you review human code. Focus review time on the six categories where AI systematically fails. Happy path code is usually fine; edge cases and security boundaries are where bugs hide.

Test for the failure modes. Write tests that specifically target AI blind spots: concurrent access, retry exhaustion, webhook replay, unauthorized access. If your test suite only covers the happy path, it matches the model's training data blind spots.

What This Means for AI-Assisted Development

AI code generation is valuable. The productivity gains are real. But treating AI output as finished code is the mistake. The taxonomy of failures is predictable, which means defenses can be systematic.

The bugs aren't random—they're structural. Authentication works but authorization doesn't. Payments initiate but webhooks fail silently. Errors get caught but never surfaced. Understanding these patterns transforms AI from a liability into a tool you can actually trust in production.

For organizations deploying AI-generated code at scale, the question isn't whether to use AI—it's how to verify what AI produces. That's the operating layer that makes AI-assisted development reliable.