TODO Stubs and Incomplete Code: When AI Gives You Placeholder Functions

The TODO Problem Is Worse Than You Think

Every software project has TODO comments. What makes AI-generated codebases different is the density and placement of those TODOs. A human developer adds a TODO because they made a deliberate trade-off - ship fast, clean up later. An AI model adds TODOs because it ran out of context, hit a complexity boundary, or received a prompt that implied the feature without specifying it. The AI does not know it is leaving a production gap; it is generating a scaffold.

The result is TODOs in critical paths: payment processing functions that return hardcoded values, email sending stubs that log "email sent" without sending anything, authorization checks replaced with // TODO: verify user has permission.

Incomplete implementations are a common source of production bugs in inherited projects. AI-generated projects are especially prone to this: the codebase looks complete because it compiles and runs, but entire feature branches are hollow.

Three Types of AI-Generated Placeholders

Understanding the taxonomy of placeholder code helps you search for and prioritize fixes:

Type 1: The annotated stub - a function that exists but does nothing, with a TODO explaining what it should do.

Type 2: The hardcoded return - a function that returns a static value or empty array to make TypeScript happy, with no indication that real logic is missing.

Type 3: The skipped validation - an authorization or validation step replaced with a comment because the AI did not have enough context to implement the real logic.

// ❌ BAD - All three placeholder types in one file

// Type 1: Annotated stub
async function processRefund(orderId, amount) {
  // TODO: implement refund via Stripe
  // TODO: update order status to 'refunded'
  // TODO: send confirmation email
  console.log('processRefund called', orderId, amount);
}

// Type 2: Hardcoded return
async function getUserPermissions(userId) {
  // TODO: fetch from database
  return ['read', 'write']; // Returns hardcoded permissions for everyone
}

// Type 3: Skipped validation
async function deleteAccount(req, res) {
  const { userId } = req.params;
  // TODO: verify requesting user has admin role
  await db.users.delete({ where: { id: userId } });
  res.json({ success: true });
}

The third example is the most dangerous. The authorization check is missing, and any authenticated user can delete any account. The TODO makes it look like someone is aware of the issue, but it is already deployed and already exploitable.

What Complete Implementations Look Like

// ✅ GOOD - Every code path is implemented

async function processRefund(orderId, amount) {
  const order = await db.orders.findUnique({ where: { id: orderId } });
  if (!order) throw new Error(`Order ${orderId} not found`);
  if (order.status === 'refunded') throw new Error(`Order ${orderId} already refunded`);

  const refund = await stripe.refunds.create({
    payment_intent: order.stripePaymentIntentId,
    amount: Math.round(amount * 100),
  });

  await db.orders.update({
    where: { id: orderId },
    data: { status: 'refunded', stripeRefundId: refund.id },
  });

  await sendRefundConfirmationEmail(order.userEmail, orderId, amount);
  return { refundId: refund.id };
}

async function getUserPermissions(userId) {
  const userRole = await db.userRoles.findUnique({ where: { userId } });
  if (!userRole) return [];
  return ROLE_PERMISSIONS[userRole.role] ?? [];
}

async function deleteAccount(req, res) {
  const requestingUser = req.user; // Set by auth middleware
  const { userId } = req.params;

  if (requestingUser.role !== 'admin' && requestingUser.id !== userId) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  await db.users.delete({ where: { id: userId } });
  return res.json({ success: true });
}

How AI Models Generate Placeholder Code

Understanding why AI tools leave stubs helps you prompt more effectively to avoid them. There are four common mechanisms:

Finding Every TODO in Your Codebase

A manual code review will not catch all placeholder code. Hardcoded returns and skipped validations look like working code to a human reviewer moving quickly. Three approaches that work at scale:

Search patterns to run immediately:

• // TODO, // FIXME, // HACK, // XXX - the four standard incomplete-code markers
• throw new Error("not implemented") - a common AI stub pattern
• return [] or return null immediately after a function declaration - likely a hardcoded stub
• console.log("TODO") or console.warn("not implemented")
• Functions whose entire body is a single return statement returning a primitive - investigate each one

Add a CI check: A pre-commit hook or CI step that fails the build on any TODO: in critical directories (src/api/, src/services/, src/lib/) forces resolution before merging. This is a forcing function that turns TODOs into action items with a deadline.

Automated scanning: VibeDoctor's Vibe Check flags throw new Error("not implemented") stubs, // TODO: implement and // FIXME: implement comments, and return null; // TODO placeholders (QUA-012), with the file path and line number. Hardcoded returns and skipped checks without those markers still need the searches above. Free to sign up.

The Right Way to Use TODO Comments

TODOs are not inherently bad. They are bad when they are the only signal that a feature is missing. A better practice is to replace TODOs in production code with two things: a tracking issue and a pending test.

A test named should process refund via Stripe marked with test.todo shows up in the summary of every Jest or Vitest run, so it will be found by any audit. A TODO comment in a source file is easily skipped in code review, and only tools you set up for it (such as the ESLint rule below) will notice it.

For placeholders that must ship temporarily (an integration pending a third-party API key), wrap them in an explicit feature flag that returns an early error in production, not a silent no-op.

FAQ