Debugging with AI: What to Send to Get the Right Answer

Debugging is one of the places where AI really saves your time. An error that would take half an hour of searching is sometimes solved in a single message.

But there is one condition: the model must see what an experienced colleague would have needed in order to help.

What to send#

1. The full error text#

Not a summary, not a translation, not "it gives a 500 error." The whole message, with the stack trace.

SQLSTATE[42000]: Syntax error or access violation: 1071
Specified key was too long; max key length is 1000 bytes
(Connection: mysql, SQL: alter table `users` add unique
`users_email_unique`(`email`))

These four lines tell the model where the problem is, in which table and on which column. The description "the migration fails" tells it none of that.

2. The code the error comes from#

Not the whole project; the function or file the stack trace points to, plus anything it calls directly.

3. Versions and environment#

PHP 8.4 - Laravel 13 - MySQL 5.7
Shared cPanel hosting, no root access

These two lines alone prevent half of the irrelevant answers. The model stops suggesting server settings changes when you don't have access to them.

4. Expected versus actual#

"I expected this to happen, but that happened instead." For bugs with no error message (wrong output, strange behavior), this sentence is the model's only clue.

5. What you already tried#

If you don't say, you get the same first three solutions you tried an hour ago.

Before sending: clean it up#

Code and logs often contain things that shouldn't leave your machine:

The model doesn't need the real values to find the bug. More detail in what you should never give to AI.

Shrink the problem#

If the error is in an 800-line file, try to shrink it before sending:

1. Remove the parts unrelated to the error.
2. Run it again. Is the error still there?
3. Repeat until you reach the smallest code that still gives the same error.

Two good things happen: often you find the cause yourself midway, and if you don't, the model answers far more accurately with 30 lines than with 800.

Signs the model is guessing#

• "Try this" over and over. If it gives three different suggestions without explaining the cause, it doesn't know the cause.
• An unfamiliar function or option. Search for it in the official documentation before using it. If it isn't there, the model made it up.
• Changing unrelated things. If it rewrites half the file to fix one error, stop.
• Agreeing with whatever you say. If it confirms your guess with no reason, ask why.

When you see these signs, change your request:

Before suggesting a fix, tell me what the cause of the error is and which part
of the error message told you that. If you need more information to diagnose it, ask.

Ask it to explain the cause#

A fix you don't understand is technical debt. The next time the same error shows up somewhere else, you'll be stuck again.

That fix worked. Now explain why the error happened
and how I can prevent it from recurring in the rest of the project.

Test before you trust#

1. Read the code. If you don't understand a line, ask.
2. Run it in a test environment, not on the live site.
3. Try the edge cases: empty input, non-English text, a very large number.
4. If it touches the database, take a backup first.

The model hasn't run the code. When it says "this works," it means "I think it should work."

When the conversation hits a dead end#

If it still isn't solved after four or five messages, don't continue. Every failed attempt stays in the conversation and confuses the model more.

Open a new chat and this time write what didn't work. We explain why long conversations get worse in tokens, context windows and hallucinations.

Continue on this path#

If this article helped, these pieces go deeper on the same topic with more practical detail:

Summary#

• The full error text, relevant code, versions, expectation and what you've tried.
• Before sending, remove keys, passwords and customer data.
• Shrink the problem to the smallest example that gives the error.
• Ask for the cause, not just the fix.
• Read the code and test it in a test environment.