Catalypt LogoCatalypt.ai

Industry Focus

Developer Options

Resources

Back to Blog

The 3am Debugging Session That Changed How I Use AI

2025-07-10T00:00:00.000Z Catalypt AI Team ai-first

3:17 AM. Production is down. The error makes no sense: TypeError: Cannot read property 'map' of undefined. I know what you're thinking - check if the array exists. I did. It exists. Sometimes.

Exhausted, I paste the error into Claude. "Add optional chaining," it says confidently. I add it. Now I have a different error. And another. And another. Welcome to the AI debugging death spiral.

When AI Makes Everything Worse

Here's what actually happened: Our API was returning inconsistent data shapes. Sometimes an array, sometimes an object with an array property, sometimes null. Classic backend shenanigans.

But the AI didn't know this. It saw a TypeError and pattern-matched to the most common solution. When that didn't work, it suggested increasingly complex "fixes" that were really just bandaids on bandaids.

By 4 AM, I had:

  • Optional chaining operators everywhere (?. all the things!)
  • Three different try-catch blocks
  • A type guard that was checking for the wrong type
  • Console.logs that were somehow making things worse

The Exhaustion Factor

Here's what nobody talks about: AI is terrible at debugging when you're tired. Why? Because debugging requires context, and when you're exhausted, you give terrible context.

My prompts at 3 AM: "It's broken. TypeError. Help.'

My prompts at 9 AM: "React component expects array from API endpoint /users, but sometimes receives {{data: [...]}} and sometimes null. Need to handle all cases gracefully."

Guess which one got useful suggestions?

The Real Fix (Spoiler: It Wasn't Optional Chaining)

After sleeping for 3 hours and approaching it fresh, here's what actually fixed it:

// API response normalizer - handles all the weird shapes
function normalizeUserData(response) {
  // Handle null/undefined
  if (!response) return [];
  
  // Handle array directly
  if (Array.isArray(response)) return response;
  
  // Handle nested data property
  if (response.data && Array.isArray(response.data)) return response.data;
  
  // Handle single object wrapped in data
  if (response.data && !Array.isArray(response.data)) return [response.data];
  
  // Unknown shape - log it and return empty array
  console.error('Unknown API response shape:', response);
  return [];
}

// Usage - no more TypeErrors!
const users = normalizeUserData(apiResponse);
return users.map(user => <UserCard key={user.id} {...user} />);

One function that explicitly handles all the cases. Clear, debuggable, and when the API returns some new weird shape, we'll know exactly where to fix it.

After 2 AM, AI suggestions get exponentially worse because your prompts get exponentially worse. Set a cutoff time.

Before asking AI for help, write a paragraph explaining the problem to yourself. If you can"t explain it clearly, you're too tired to debug.

Can you reproduce it locally? No? Then you don't understand it well enough to prompt AI effectively. Get the error happening consistently first.

If the AI's suggestion seems really complex for a simple problem, you're probably too tired. Sleep on it. The 15-line fix at 3 AM often becomes 3 lines at 9 AM.

After that nightmare session, I've learned when to actually use AI for debugging:

"I'm seeing this error pattern across multiple components" - AI is great at spotting what's common.

"Is this TypeScript generic syntax correct?" - Perfect AI use case.

"What are 3 different ways to handle API response normalization?" - Gets you unstuck from tunnel vision.

"What causes 'Cannot read property of undefined' when the variable is clearly defined?" - AI knows all the edge cases.

Now when I hit a late-night debugging wall, I have a protocol:

  1. Document the symptoms - Screenshots, error messages, what I've tried
  2. Write a clear problem statement - If I can't, I'm too tired
  3. Set a timer - 30 more minutes max, then sleep
  4. Leave breadcrumbs - Comments about what I was thinking
  5. Sleep on it - Literally. The fix is usually obvious in the morning

Want to know the real kicker? A week later, I discovered the backend developer had deployed a breaking API change at 2:58 AM without telling anyone. All that debugging, all those "fixes," and the real problem was a communication issue.

The AI couldn't have known that. But if I'd been less tired, I might have checked the deployment logs first instead of trying to code my way out of someone else's breaking change.

Get Started