Supply the four things that matter
The failing code, minimised to the smallest piece that still fails. Reducing the case often reveals the bug before you ask anything.
The exact error message and full stack trace, unedited. Paraphrased errors lead to answers about a different problem.
What you expected to happen and what happened instead. These are different claims and both are needed.
The environment: language and version, framework and version, operating system, and any relevant configuration.
Treat the first answer as a hypothesis
A plausible fix that changes behaviour is not proof of diagnosis. Confirm the mechanism: why would that change produce this symptom?
If the explanation does not account for the specific error message, it is probably wrong even if the code now runs.
Ask for two or three candidate causes rather than one fix. Ranking hypotheses is more useful than a single confident answer.
Guard against invented APIs
Assistants sometimes suggest functions, flags and configuration keys that do not exist. Check anything unfamiliar against the official documentation before adopting it.
Be sceptical of suggestions that involve adding a dependency to solve a small problem.
Where it genuinely saves time
Reading unfamiliar code, explaining a dense regular expression, translating an error message from a library you have never used, and generating test cases around a suspected bug.
Concurrency, memory and timing bugs remain hard. There the assistant is a source of ideas, not answers.