Last reviewed
Correct answer: C. Share the actual error message or test failure
Explanation
An error message is evidence. It carries the exception type, the file and line, the call stack, and often the offending value, and that set of facts rules out most of what could be wrong before anyone reasons about anything. A failing test does the same job from the other end: this is what was expected, this is what came back. Hand over "it doesn't work" instead and the model is not diagnosing, it is guessing which of a dozen plausible failures you hit. The usual result is a confident rewrite of code that was already fine.
That is why the remaining options burn turns. An unrelated question leaves the failure exactly where it was. Deleting the code and starting a fresh conversation throws away the one asset the session had accumulated, and tends to reproduce the same bug, since nothing was learned about it. Iterating is normal and often necessary, but it only converges when each round adds information. Paste the traceback, name the command you ran, and state what you expected.
Sources
“Combined with access to your local files, it can fetch CI failure details, correlate them to your code, and propose fixes from your terminal.”
“You can include instructions and information in a prompt that the model needs to solve a problem, instead of assuming that the model has all of the required information.”
“Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.”
Practise 3 questions on this topic
Take Prompt Engineering for Code — Timed Test (3 questions) — scored instantly, explanation for every question, no login.