I was looking at a customer’s error report last week. A TypeError buried three callbacks deep in a checkout flow that made no sense. The code around it was clean, well-structured, and completely wrong about how the Stripe API actually works.
Turns out it was vibe-coded. Someone prompted their way through the integration, it passed code review because it looked reasonable, and it worked fine right up until a customer’s card got declined for the first time.
That’s the new normal. Maybe the code came from a coworker who left six months ago. Maybe a contractor. Maybe GitHub Copilot, Claude, or whatever autocomplete casino your team is using this week.
Doesn’t matter. The bug report still lands on your desk like you wrote the thing yourself.
And the instinct is to reverse-engineer the author’s assumptions and crimes against the event loop. But that approach is slow, expensive, and usually wrong.
Don’t Start With the Code
This is the first trap.
You open the file. You start reading. Fifteen minutes later you’re six functions deep, learning the personal philosophy of a stranger who thought nested ternaries were a personality trait.
Meanwhile, you still don’t know what actually broke.
Instead, start with the runtime failure:
- What was the actual error?
- Which browser did it happen in?
- What was the user doing right before it happened?
- Is this happening once, or to a lot of people?
- Did it start after a deploy?
That gets you out of “read everything and hope” mode and into “find the failing path” mode.
Look for Assumptions, Not Just Mistakes
The bug is usually not “someone typed the wrong syntax.”
The bug is that the original author assumed something would always be true:
- the API would always return data
- the DOM would already be there
- the state object would exist
- the route would only change one way
- the browser would behave like Chrome on their laptop
- the user would click things in the “correct” order
That’s why unfamiliar code is so annoying. You’re not just finding a broken line. You’re finding the hidden agreement the code made with reality, and reality stopped cooperating.
Once you know the failed assumption, the fix usually gets a lot simpler.
Reconstruct the Scene
Most JavaScript bugs are not mysterious. They’re just missing context.
Cannot read properties of undefined is not helpful by itself. Neither is “Script error.” Neither is a screenshot from support that says “it stopped working.”
What you actually need is the story around the failure.
Did the user click checkout twice? Did a third-party script mutate the page? Did Safari decide today was the day it would be special?
Telemetry matters. Console logs matter. Network activity matters. User actions matter. Without that trail, you’re not debugging. You’re writing fan fiction about someone else’s code.
Get the Evidence From Production
Yes, this is the part where I talk about TrackJS. I know. Bear with me.
When you’re debugging code you didn’t write, you need more than the raw error message. You need the stack trace, the browser, the user actions, the console logs, and the network trail. You need enough context to understand what the code was trying to do before reality intervened.
That’s what TrackJS gives you. Not omniscience — just enough evidence that you can stop guessing and start fixing.
And if the error report still looks like browser nonsense, the AI Debugger can translate it back into normal human frustration. Which, honestly, is the most appropriate use of AI I’ve seen yet.
The Real Skill
Debugging code you didn’t write is not about becoming an archaeologist of every file in the repo. It’s about resisting the urge to read everything, starting from what actually failed, and working backward to the bad assumption.
That’s the skill. And it’s going to matter more every year, because your team is going to keep shipping code nobody fully understands. Some from coworkers. Some from contractors. A growing pile of it from AI that looked great in the diff and broke on the first edge case.
It all becomes your bug eventually.
The vibes won’t survive production. The evidence will.
