In this article
Question: What should you ask AI before letting it fix a bug?
Before letting AI fix a bug, ask it to inspect the relevant files, explain the likely cause, list the smallest safe fix, name the files it plans to change, and give you testing steps before it writes code.
Why the question matters
The important part is "before." A lot of AI-assisted debugging goes wrong because the assistant starts editing too soon. It sees an error, guesses the fix, changes a file, and maybe the visible bug disappears. Then another part of the app breaks because the fix was aimed at the symptom, not the shape of the feature.
This is especially common in vibe coded apps where you do not fully understand every file yet. You need the AI to act less like a code cannon and more like a patient assistant that can inspect, explain, patch, and test in small steps.
The prompt I would start with
Here is the prompt I would use before letting an AI assistant touch a bug:
Inspect the current code before changing anything.
Find the cause of this bug: [describe the bug]
Rules:
- Do not rewrite unrelated code.
- Do not change styling unless needed.
- Do not change database schema unless required.
- Explain the likely cause first.
- List the files you plan to edit.
- Make the smallest safe fix.
- Include testing steps.
That prompt is not fancy. That is why it works. It gives the AI a job, a boundary, and a review point before the patch.
Why inspection comes first
If the AI has not looked at the relevant files, it is guessing. Sometimes the guess is good. Sometimes it is a generic answer from a pattern that does not match your app.
Inspection matters because real bugs usually sit in context. A login problem might involve a form, a route, a session helper, a database table, and a redirect. A broken admin page might involve permissions, query filters, pagination, and a template. A failed save action might be a missing column, a renamed field, or a CSRF check that no longer matches the form.
The AI needs to see those pieces before changing them. This is the same reason How to Prompt LLMs Without Turning Your Project Into a Mess matters. The prompt is not just a request. It is a guardrail.
Ask for the likely cause
"Explain the likely cause first" is the line that saves you from a lot of bad patches. It forces the assistant to describe the failure in plain English before touching code.
If the explanation does not make sense, stop there. Ask follow-up questions. Ask it to cite the file and function it is relying on. Ask what other paths might be affected. You do not need to become an expert in the whole stack immediately, but you do need enough understanding to decide whether the patch is sane.
This is where AI can be very useful. It can translate a stack trace, route error, or SQL failure into something you can reason about. But you have to ask for that translation before asking for the fix.
Make it name the files
The file list is a simple control point:
Before editing, list the files you plan to change and why each one is needed.
If the AI lists one file, you can review that scope. If it lists nine files for a small form bug, that is a sign to slow down. Maybe the feature really is tangled. Maybe the AI is about to refactor half the app. Either way, you want to know before the patch lands.
For small apps, I like changes that are easy to describe: "update the save handler," "fix the route name," "add the missing validation," "adjust this query." If the change cannot be explained without waving hands, it may be too broad.
Ask for the smallest safe fix
"Smallest" does not mean hacky. It means the fix should match the bug. If the issue is a missing environment variable, do not rewrite authentication. If the issue is a column name mismatch, do not redesign the database layer. If the issue is an admin permission check, do not rebuild the entire dashboard.
This connects directly to Make the Bug Smaller Before You Ask AI to Fix It. A small bug report gives you a small patch. A vague bug report gives you a vague patch.
Ask for testing steps
Do not accept a fix without a test path. Even if the app has no automated tests, the AI should tell you how to check the change manually.
Good testing steps are specific:
- log in as an admin
- open "/admin/tasks/"
- edit one task
- save it
- refresh the list
- check that the value persisted
- test one non-admin user path if permissions were touched
Bad testing steps are vague:
- test the app
- make sure it works
- check everything
The more specific the test, the more useful the patch.
The takeaway
Before letting AI fix a bug, make it slow down. Ask it to inspect, explain, scope, patch small, and test. That does not remove the need for judgment, but it turns AI-assisted debugging into a reviewable workflow instead of a guessing game with better autocomplete.