When You Hit a Bug — Finding the Root Cause with AI

Once you deploy a service, you’re bound to run into bugs. Something that worked fine locally breaks after deployment, or a user emails you asking “why isn’t this working?” Let’s look at how to approach bugs when they show up in a service you built with vibe coding.

Where production bugs come from

Bugs are generally found through one of two paths.

Finding it yourself While using the service yourself, you notice that something isn’t behaving the way it should.

User reports After you launch the service, a user tells you about a bug.

Either way, the process for figuring out a bug is the same.

Can you reproduce it (under what conditions does it happen)
Where does it happen (which code, which feature)
Why does it happen (root cause)
How do you fix it (resolution)

The hard part in vibe coding is step 3. Since you didn’t write all the code yourself, it’s not immediately obvious where the problem lies. This is where AI comes in.

How to ask AI to debug

When asking AI to fix a bug, it’s important to give it as much information as possible.

A good bug report format

[Bug description]
When I delete a bookmark it disappears from the list, but reappears when I refresh the page.

[Steps to reproduce]
1. Add 3 bookmarks
2. Click the delete button on the middle bookmark
3. It disappears from the list (expected)
4. Refresh with F5
5. The deleted bookmark reappears (unexpected)

[Expected behavior]
A deleted bookmark should stay gone even after a refresh.

[Browser console errors]
(none / or paste the full error message)

[Files that seem related]
BookmarkList.jsx, storage.js

Giving this level of detail lets the AI immediately understand what it needs to look at.

When there’s an error message

When a browser error occurs, a message shows up in red in the console (F12 → Console tab). Just copy the whole thing and paste it into Claude Code.

I'm getting the error below. Can you tell me what's causing it and how to fix it?

Uncaught TypeError: Cannot read properties of undefined (reading 'filter')
    at BookmarkList.jsx:23
    at Array.map (<anonymous>)
    at BookmarkList (BookmarkList.jsx:18)

Error messages tell you which file and which line number the problem occurred on. The AI uses this information to find the relevant code and figure out the cause.

Prompt patterns that come in handy while debugging

Ask for a root-cause analysis first

Analyze the root cause of this bug. Don't fix it yet — just explain why this is happening.

[Bug description]

Understand the root cause and figure out a fix direction before actually making changes. If you jump straight to “just fix it,” you sometimes end up patching the surface symptom while the underlying cause remains.

Ask for step-by-step debugging

Check through this step by step to find the cause of the bug.
Add console.log statements showing what values go in and out at each step.
I'll run it myself and report back the results.

When the AI can’t run the code itself, this is a way to narrow down the cause by having the developer run it and report the results back.

Ask for verification after the fix

Check whether the fix is heading in the right direction.
Also look at whether there's anything that could affect other features.

”Where else does this touch?” — Mapping the impact

Once you’ve found the root cause, you need to figure out how far the bug’s impact reaches. A single bug can affect multiple features at once.

For example, if there’s a problem with how data is saved to localStorage, it could affect not just bookmark storage but every feature that uses localStorage — tag storage, settings storage, and so on.

Here too, you can just ask the AI. It’s more accurate when the structure is laid out in CLAUDE.md.

Check which components are connected to storage.js.
If there's a bug in the localStorage save logic, figure out which features would be affected.

Claude Code reads the code and structure notes and works out the scope of impact. The better the structure is recorded, the more accurate the analysis will be.

Things to check after fixing a bug

After fixing a bug, there are two things to check.

1. Is the bug actually fixed

Walk through the reproduction steps again to confirm the bug is gone. Check locally first, then deploy and confirm in the real environment too.

2. Did anything else break

A bug fix can affect other features. Use the features within the impact scope you identified earlier and confirm nothing is off.

Habits that prevent bugs

It’s more efficient to prevent bugs from happening in the first place than to fix them after the fact.

Habit	Method
Test it yourself after adding a feature	Whenever you add a new feature, use the related features yourself to check
Prompts with explicit scope	When asking AI for something, explicitly state that it shouldn’t affect existing features
Deploy in small increments	Deploy little by little instead of shipping many features at once
Keep a change log	Record what changed and when (GitHub commit messages)

You can’t prevent bugs perfectly in vibe coding. But it’s important to have a setup where you can quickly find the cause and fix it once one shows up.

Next time

In the final installment, we’ll cover how to keep a service you built with vibe coding running for the long term — the routines and mindset that keep it manageable as it grows, without losing the speed you had at the start.